一個工程頻道標註 @Claude，請它追週末 incident 的原因。它要讀 Slack thread、GitHub PR、監控截圖和資料倉庫；PM、客服與工程師都在同一個頻道裡補線索。模型可能總結錯，但更早影響安全的是權限歸屬：背後到底用了誰的憑證？沒有 repo 權限的成員能不能透過頻道裡的 Claude 看到 repo？Claude 把 incident 脈絡寫進記憶後，會不會被帶到不該出現的頻道？
Anthropic 2026 年 6 月 24 日公開 Claude Tag 的 agent identity access model，就是在處理這個場景。Claude Tag 讓 Claude 進入 Slack 這類多人協作空間；官方說，當 AI agent 服務整個頻道時，不能只沿用「代表某一位使用者操作」的模式。管理者要替 Claude 建立屬於 workspace 或 channel 的身分，並替這個身分設定工具、文件、repo、資料庫、記憶和稽核邊界。
如果團隊正在評估 Claude Tag、企業 agent、MCP 工具或內部自動化助理，可以把這套流程當作權限設計檢查表。已經把 AI 放進 Slack、GitHub、CRM 或資料倉庫的團隊，要優先處理共用 token、過大的 channel 權限和記憶外洩；還沒導入的團隊，可以先把頻道分類、工具授權和停用流程整理好，等產品成熟時少走一次危險試錯。
Anthropic 這次補上的 agent identity 是什麼？
在個人助理情境裡，AI 通常「代表使用者」工作：使用者連接自己的 Google Drive、GitHub 或 calendar，模型用同一組使用者授權讀取資料。這種模式在單人聊天裡比較直覺，因為請求者、資料權限和結果責任大致綁在同一個人身上。
Claude Tag 的場景不同。Anthropic 的官方文章把它稱為 multiplayer AI：Claude 坐在共享頻道裡，可能同時被三位工程師、一位 PM 和一位客服主管指揮。若每次都套用其中一個人的權限，結果會變得不可預期；若讓所有人共用同一組 token，事後又很難追到是哪個 agent、哪個頻道、哪個任務做了什麼。
Agent identity 的做法，是讓 Claude 在不同系統裡「以 Claude 自己的身分」工作。官方舉例說，它可以在 Slack 裡以 Claude app 發言，在 GitHub 裡以 Claude GitHub App 開 PR，在資料倉庫裡用管理者配置的 service account 查詢。這些帳號不屬於某位員工的私人憑證，因此共享頻道不會因為某位成員連了個人帳號，就變成通往私人文件的側門。
這個設計也帶來新的責任。Anthropic 說，管理者可先在 workspace 層級定義 baseline identity，讓頻道預設繼承；需要更細時，再用 channel profile 覆寫工具與資料範圍。工程頻道可以被授權讀特定 GitHub repo 與低敏感監控資料；法務或人資頻道則應該用另一個隔離身分，不共享記憶與工具。
權限判斷要從「使用者能做什麼」改成「這個 agent 在這個區隔能做什麼」
傳統 ACL 常問：這個人能不能讀某個 repo、文件或資料表。Agent identity 會把問題改成：這個頻道裡的 Claude 能不能讀，誰可以在這個頻道要求它讀，讀完之後記憶與稽核紀錄放在哪裡。
這個改變對企業很實際。官方明說，若 channel profile 授權 Claude 讀某個 repo，頻道成員即使沒有直接 repo 權限，也可能要求 Claude 讀取該 repo。這句話描述 Anthropic 對多人 agent 權限模型的設計選擇；它讓共享 agent 能替團隊工作，也要求管理者把 channel scope 設成足夠小，不能把它當成漏洞或例外狀態處理。
可以用三個邊界來落地。
頻道邊界要先於工具邊界。公開頻道適合低敏感、可重用的脈絡，例如產品 FAQ、公開文件、無個資的 issue 摘要。私有頻道才適合接團隊專用 repo、支援票或資料倉庫，而且每個私有頻道都應該有自己的 agent 身分。Anthropic 說 Claude Tag 會替私有頻道建立 distinct identity；公開頻道則共用 workspace-level identity。這句話應該直接變成管理規則：不確定能否共用的資料，不要放進公開頻道的 agent profile。
工具邊界要比人類角色更細。管理者除了決定「Claude 可以用 GitHub」，還要決定哪些 repo 可讀、哪些 repo 可寫、哪些 connector 用 read-only key、哪些技能或 plugin 可以被載入。若同一個資料倉庫同時服務客服、財務與產品分析，應該為不同頻道配置不同權限等級，避免同一組高權限 API key 到處流動。
記憶與稽核邊界決定事故發生時能不能收拾。官方說 Claude Tag 的記憶與 access 會尊重 private channel 邊界；管理者加入 connection 時，credential 會獨立儲存並映射到該 channel identity，在 request time 注入 network boundary；未被允許的 outbound host 會被阻擋。稽核方面，每個 routine、memory write 和 network call 都會被記錄，且因為 Claude 用自己的 service account 行動，連接系統裡也會留下對應 log。這些紀錄要在試點期就有人看，不要等到資料外洩或錯誤操作後才第一次打開。
三週試點：先證明一個頻道能安全產生價值
不要從「全公司 Slack 都能標註 Claude」開始。比較安全的試點，是選一個痛點明確、資料敏感度中低、成果容易驗收的頻道。例子可以是客服與工程交接頻道：客服常把重複錯誤丟給工程，工程師需要查最近部署、已知 issue、錯誤訊息樣本，再決定是否升級 incident。這個流程需要跨工具整理，但不一定需要讓 AI 寫 production 或碰金流資料。
試點前先完成以下分流，避免用抽象「信任 AI」取代具體權限設計。
| 場景 | 建議做法 | 暫時不要做 |
|---|---|---|
| 低敏感公開知識、產品 FAQ、已公開文件 | 放在 workspace baseline 或低風險公開頻道，維持 read-only | 把客戶資料、合約、內部策略一起接進公開 profile |
| 工程 incident、支援 escalation、資料分析 | 用私有頻道 agent identity，限制 repo、資料表、connector 與可寫動作 | 讓所有工程頻道共用一組高權限 token |
| 個人信箱、私人 calendar、個人授權 SaaS | 留在 DM 或個人帳號授權流程，讓結果歸屬明確 | 把個人工具掛到共享頻道，讓其他人間接使用 |
| 需要高風險寫入的任務 | 加上人工批准、變更紀錄、回滾方案與短效授權 | 讓 agent 長期持有 production write access |
第 1 週只做只讀任務。讓 Claude 整理 thread、列缺少的診斷資料、引用相關文件、把待辦分派給 owner；禁止它改 repo、寫資料庫、發外部訊息或存取完整客戶資料。每天抽查輸出是否能被客服與工程共同使用，並記下哪些請求其實是流程模板缺失。
第 2 週看記憶、費用和稽核。管理者要檢查 Claude 寫進了哪些記憶、哪些內容應刪除、哪些 tool call 最常發生、哪些請求消耗高但產出低。若頻道成員常要求 Claude 查超出範圍的資料，不要先加權限；先把頻道任務改小，或把高敏感任務移到另一個私有頻道。
第 3 週才決定是否擴大。通過條件應該能被驗證：輸出能減少跨團隊來回追問，read-only 範圍足以完成主要任務，audit trail 能追到 routine、memory write 與 network call，停用 Claude 或撤銷 channel identity 的流程有人實際演練過。任何一項不清楚，都維持單一頻道試點。
和 Zero Trust for AI Agents 怎麼接起來？
Anthropic 5 月底發布的 Zero Trust for AI Agents 框架，把 agent 風險分成工具存取、自主決策、context persistence、多 agent 協作、prompt injection、tool poisoning、identity and privilege abuse、memory poisoning 與供應鏈攻擊。6 月的 agent identity 文章則把其中一塊落到 Claude Tag 的權限模型：agent 必須有可識別、可撤銷、可稽核的非人類身分。
把兩篇官方文章合起來看，企業至少要做五件事。
建立 agent inventory。 除了使用者帳號，也要列出每個 agent、所在頻道、工具、connector、service account、記憶範圍和 owner。若公司已有自建 MCP server，可以搭配 MCP Gateway Deep Message Inspection 這類檢查思路，把工具輸入與輸出當成安全邊界。
縮小每次任務的權限。 Agent identity 不該變成 Claude 的全公司通行證。它應該讓管理者把 Slack 頻道、repo、資料表、plugin 和 standing instruction 切成可撤銷的 compartment。任務越高風險，越需要短效授權、人工確認和 rollback。
把記憶當成資料資產。 Agent 記憶可能保存錯誤結論、過期規格或敏感資訊。試點期要安排記憶審查與刪除流程，並指定誰能決定「這段記憶可以長期保留」。若文章、客服話術或 runbook 已更新，舊記憶也要同步清掉。
讓 audit log 能回到原系統。 只看 Slack 回覆不夠。GitHub、資料倉庫、CRM、MCP server 和 agent platform 都應該留下 service account 或 app-level log。當 Claude 開 PR、讀表、呼叫 API 或寫記憶時，安全團隊要能對上頻道、請求者、時間與輸出。
替高風險操作保留人類批准。 Anthropic 提到未來想強化 just-in-time credential grants 與 identity-aware overlay，讓敏感動作同時受 channel profile 與 requesting user 權限限制。這代表現階段不要假設產品已替所有公司解決細粒度授權；在採購、金流、法律、醫療、客戶刪除、production write 等任務上，先保留人工批准與回滾。
不該現在做的事
導入 agent identity 時，最危險的 shortcut 是把舊機器人治理方式搬過來。把 Claude 當成一般 Slack bot、讓它共用一組超大權限 API key、只在採購文件裡寫「有 audit log」，都不足以處理自主 agent 的風險。
也不要把「agent 有自己的身分」誤解成「agent 可以拿更大權限」。身分存在的目的，是讓權限、記憶與稽核能被切開；若同一個 Claude 身分同時能讀法務文件、客服 ticket、production log 和財務資料，事故半徑只會更大。
最後，不要讓低急迫性的團隊直接退出學習曲線。即使現在沒有 Claude Tag，仍然可以先整理三份文件：AI agent inventory、工具授權分級表、共享頻道資料分類表。等到 Claude Tag、Amazon Bedrock AgentCore Identity 或其他 agent 身分服務進入採購評估時，團隊會知道哪些需求能直接導入，哪些要先縮小範圍。
FAQ
Agent identity 會取代使用者權限嗎？
不會。比較準確的說法是，它讓共享 agent 在共享空間裡有自己的身分與權限。Claude Tag 的 DM 仍會使用個人 claude.ai 帳號、個人 connector 和個人名稱產生結果；共享頻道則應該用 channel 或 workspace identity。企業要同時管理兩條路徑，不能只看其中一邊。
沒有 repo 權限的人，能透過 Claude 看到 repo 嗎？
在 Anthropic 描述的模型裡，如果某個 channel profile 授權 Claude 讀 repo，頻道成員可能要求 Claude 讀該 repo，即使他們沒有直接 repo 權限。這正是 channel scope 和 RBAC 必須先設好的原因。敏感 repo 不應放進成員混雜的頻道，read/write 權限也要分開。
這和傳統 service account 有什麼不同？
Service account 是基礎，但 agent identity 還要處理頻道、記憶、工具鏈、standing instruction、多人請求、非同步 routine 和 audit trail。把所有 agent 都塞進一個 service account，仍然會失去追蹤與最小權限。比較好的做法，是把 service account 綁到明確的 agent compartment，並能按頻道或任務撤銷。
已經有 Zero Trust，還需要新流程嗎？
需要調整。原本的 Zero Trust 多半圍繞人類使用者、裝置、網路與 SaaS 權限；AI agent 會讀 context、選工具、寫記憶、連接 MCP server，還可能在使用者離線後繼續任務。既有架構可以沿用驗證、最小權限、假設失陷和監控精神，但要把 agent 身分、記憶、工具輸入與多步驟行動納入同一個稽核面。
和 MCP Gateway、misconfiguration 怎麼分工？
Zero Trust for AI Agents 是總原則，但落地時要拆成幾個可執行的控制點。不要把所有問題都丟給模型或 prompt policy，因為真正會出事的通常是工具權限、資料流與部署設定。
| 問題 | 比較像哪一層 | 延伸閱讀 |
|---|---|---|
| Agent 是否能代表誰做事 | identity、least privilege、approval | 本文的 agent 身分與權限段落 |
| Agent 連到哪些 MCP tools | gateway、allowlist、tool audit | MCP Gateway 與 Deep Message Inspection |
| 服務是否被公開暴露 | endpoint、Kubernetes、dashboard auth | AI App Misconfiguration 安全指南 |
| Prompt injection 是否會變成執行風險 | tool argument validation、sandbox | Semantic Kernel RCE 案例 |
如果你是第一次做 agent 治理，不必一口氣買完整平台。先建立 agent inventory、工具 allowlist、敏感 action approval、日誌留存與回收 token 流程，通常就能消掉最大風險。