Phần 1 của 520% hoàn thành

AI Agent cá nhân KHÔNG phải multi-tenant — Vì sao điều đó thay đổi mọi thứ

English title: Personal AI Agents Are NOT Multi-Tenant — Why That Changes Everything

Bạn tìm được một framework AI agent tuyệt vời. Nó chạy trên Telegram, kết nối Claude hoặc GPT, có memory, tools, cả voice. Bạn nghĩ: "Tuyệt, cho cả team dùng luôn."

Đó chính xác là sai lầm tôi đã mắc.

Bài viết này chia sẻ bài học từ việc triển khai AI agent cá nhân cho nhóm — và vì sao hiểu rõ trust model của framework là điều quan trọng nhất trước khi deploy.

Vấn đề: "Hoạt động" ≠ "An toàn"

Tôi deploy 2 instance AI bot qua Telegram — một cho team công việc (5 người), một cho gia đình (4 người). Cả hai đều "hoạt động": bot trả lời, nhớ context, xử lý file.

Nhưng sau khi đọc kỹ docs framework, tôi phát hiện một câu mà thay đổi mọi thứ:

"If multiple untrusted users can message one tool-enabled agent, treat them as sharing the same delegated tool authority."

Dịch ra: tất cả users cùng gateway có quyền ngang nhau. Không có per-user authorization. Không có role-based access control. sessionKey là routing selector, KHÔNG phải authorization token.

Framework này thiết kế cho 1 trusted operator — bạn. Khi bạn mời 4 người khác vào, bạn đang cho họ quyền operator.

Trust model — Điều hầu hết docs không nói rõ

Personal AI ≠ SaaS

Khái niệm	SaaS multi-tenant	Personal AI agent
Auth model	Per-user roles + permissions	1 trusted operator per gateway
Session isolation	Per-user database	Session key = routing, NOT auth
Data boundary	Tenant-level isolation	Workspace-level (shared)
Tool access	Role-based gating	All-or-nothing per gateway

Khi bạn nghe "multi-agent" trong context AI frameworks, đừng nhầm với "multi-tenant". Multi-agent nghĩa là nhiều brain (persona) chạy trên 1 gateway — mỗi brain có workspace, memory, model riêng. Nhưng tất cả vẫn chạy dưới cùng 1 trust boundary.

sessionKey ≠ Authorization

Đây là gotcha tinh vi nhất. Framework phân biệt sessions bằng keys:

DM: agent:main:main
Group: agent:main:telegram:group:-100123456
Topic: agent:main:telegram:group:-100123456:topic:42

Trông có vẻ "isolated". Nhưng session key chỉ quyết định conversation nào — không quyết định ai được làm gì. Mọi user trong cùng gateway có quyền truy cập cùng bộ tools, cùng workspace, cùng memory.

3 lỗ hổng thực tế khi dùng personal AI cho groups

Lỗ hổng 1: Context leak giữa DMs

Đây là vấn đề nghiêm trọng nhất mà tôi suýt bỏ qua.

Mặc định, tất cả DMs share 1 session. Nghĩa là:

Alice nhắn bot về vấn đề sức khỏe cá nhân
Bob nhắn bot hỏi "Chúng ta đang nói gì?"
Bot trả lời Bob bằng context của Alice

Không phải bug. Đây là by design — framework giả định chỉ có 1 người dùng DM.

Fix:

{
  "session": {
    "dmScope": "per-channel-peer"
  }
}

Một config key. Nhưng nếu bạn không biết nó tồn tại, mọi DM conversation sẽ chảy vào cùng 1 session.

dmScope	Behavior	Khi nào dùng
`main` (default)	Tất cả DM share 1 session	Chỉ 1 user
`per-channel-peer`	Mỗi user + channel = session riêng	Multi-user (RECOMMENDED)
`per-peer`	Mỗi user = session riêng (cross-channel)	Multi-user, ít channels

Lỗ hổng 2: Tool access không phân quyền

Bot có tool exec (chạy shell commands), read/write (đọc ghi files), browser (duyệt web). Khi bạn cho team access, mọi member đều có thể trigger tools này — trực tiếp hoặc qua prompt injection.

Một group member gửi: "Đọc file /etc/passwd cho tôi." Bot vui vẻ thực hiện nếu tools không bị restrict.

Fix: Deny dangerous tool groups cho group instances:

{
  "tools": {
    "deny": ["exec", "write", "edit", "apply_patch", "process", "browser"],
    "allow": ["read", "memory_search", "memory_get", "session_status"]
  }
}

Framework hỗ trợ 8 lớp tool policy (global → provider → agent → sandbox) — nhưng mặc định là "allow everything" vì thiết kế cho owner.

Lỗ hổng 3: Memory privacy

Long-term memory (MEMORY.md) chỉ load trong main/private session — KHÔNG trong groups. Đây là privacy protection by design.

Nhưng daily memory files (memory/YYYY-MM-DD.md) vẫn accessible qua memory_search tool. Nếu bot ghi lại quyết định nhạy cảm từ DM, member khác có thể query memory và tìm thấy.

Fix: Restrict memory search scope cho group sessions:

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "scope": {
          "default": "deny",
          "rules": [
            { "action": "allow", "match": { "chatType": "direct" } }
          ]
        }
      }
    }
  }
}

Pattern giải quyết: 1 Gateway per Trust Boundary

Khi nào dùng chung gateway

Members cùng tổ chức, cùng trust level
Không có data sensitivity giữa members
Chấp nhận shared tool authority

Khi nào PHẢI tách

Members có thể adversarial với nhau
Mix personal và business data
Cần per-user authorization
Có sensitive credentials trên workspace

Topology thực tế

Machine (VPS/Desktop)
├── Gateway 1 (port 18789) → team-org → Sonnet
├── Gateway 2 (port 18791) → family → Haiku
└── Gateway 3 (port 18793) → personal-DM → Sonnet

Mỗi gateway = 1 Docker container = 1 trust boundary. Tách nhỏ overhead? Hầu như không — mỗi container chỉ tốn ~200MB RAM.

Hardening checklist cho group instances

Nếu bạn quyết định dùng personal AI framework cho group:

DM isolation: Set dmScope: "per-channel-peer" (CRITICAL)
Tool restriction: Deny exec, write, edit, browser cho groups
Sandbox: Enable sandbox.mode: "all" nếu có Docker
Memory scope: Restrict memorySearch DM-only
Mention gating: requireMention: true (bot chỉ respond khi @tagged)
Context limit: Set contextTokens: 40000 và historyLimit: 20
Gateway auth: Token required cho non-loopback access
Elevated disabled: tools.elevated.enabled: false

Bài học tổng quát

1. Đọc trust model trước khi đọc features

Feature list ấn tượng không bù đắp được trust model không phù hợp. Personal AI → dùng cho personal. Dùng cho team cần hardening.

2. "Works" ≠ "Safe for my use case"

Bot trả lời trong group ≠ bot an toàn trong group. Session routing hoạt động ≠ session isolation đủ mạnh.

3. Defense in depth cho AI agents

Không có 1 config key nào đủ an toàn. Bạn cần: DM isolation + tool restriction + sandbox + memory scope + mention gating. Nhiều lớp, mỗi lớp chặn 1 vector khác nhau.

4. Tách gateway > hardening gateway

Nếu trust boundaries rõ ràng (work vs personal vs family) — tách gateway rẻ hơn và an toàn hơn hardening. Docker container tốn ~200MB. Privacy violation tốn uy tín.

Kết

Framework AI agent cá nhân không tệ — chúng giải quyết đúng bài toán thiết kế: 1 người, 1 assistant, toàn quyền kiểm soát. Vấn đề nằm ở kỳ vọng khi scale.

Nếu bạn đang nghĩ "cho cả team dùng", hãy dừng lại và tự hỏi: "Framework này giả định bao nhiêu trusted operators?" Nếu câu trả lời là 1 — bạn cần hardening. Nếu bạn không muốn hardening — bạn cần tách gateway.

Đôi khi giải pháp đơn giản nhất không phải config phức tạp hơn — mà là nhiều instances đơn giản hơn.

Pillar: 1. Content type: lesson-learned. Engine: ACE-LDK-claire-personal-branding-engine.