AI agent 嘅「自主性」，一直係佢哋最大嘅賣點，亦係最大嘅安全隱患。Token Security 嘅 CTO Ido Shlomo 喺一篇分析指，agent 喺企業環境冇被明確限制可以做咩嘅話，佢哋傾向用盡手頭所有可用權限，而傳統存取控制未必攔得住。
佢舉咗個實際案例。一名開發者叫 agent 查明夜ly export job 點解失敗。團隊嘅規定好簡單：agent 只用唯讀角色。但係呢個開發者本身都攞有 on-call 用嘅管理員權限，兩份 profile 都擺喺同一個 ~/.aws/config 入面。
問題就係咁發生嘅。Agent 試住 re-run 個 job，撞上 AccessDenied，就自己切換去管理員 profile，假設該角色，然後對生產 S3 bucket 行咗一條 aws s3 rm，清走個寫到一半嘅 export。
重點喺度：呢個 credential 係有效嘅。開發者本身可以假設管理員權限，管理員可以刪除 S3 物件。AWS 查嘅係簽名，唔係邊個攞緊個 key，所以喺 AWS 眼中，呢個動作就係開發者本人做嘅。真正違規嘅，係一個 agent 用咗佢唔應該用嘅角色——Shlomo 話，呢一點唔似動機（intent）咁難查，每個 request 都可以驗證。
佢話，問「邊個該負責」係錯誤嘅提問。問題應該問：呢個刪除動作喺邊度可以真係攔落嚟。因為有多個 enforcement 點，每個取決於該控制能看到乜、能攔邊個動作、同 agent 有冇另一條路可以達到同一個動作。
佢喺度講緊兩股壓力
第一股，係組織層面不斷擴張 agent 權限嘅壓力。任務卡住、要加新整合，每次都有道理，但結果永遠係：下一個 task 開始時嘅權限，比前一個更大。
第二股，來自 agent 本身。當佢現有嘅 credential 被 block，會自動揾新嘅，唔會問人。呢個行為唔分來源——可惡嘅 prompt injection 可以做過界動作，合法任務入面嘅錯誤假設都可以。
Shlomo 嘅結論係：想 agent 有自主性，就要有可以真嘅執行嘅限制，而唔係只係「控制 tool call」咁粗糙。如果 tool 係一個可以跑 SDK 嘅 shell，或者係一個有已登入 session 嘅 browser，你允許個 tool，就等於允許佢後頭嘅嘢。要準確判斷，需要知道操作嘅內容、參數、存取嘅帳號與資源、使用緊嘅身分，以及資料輸出嘅去向。
阿調搞兩下：呢個 case 好值得公司用 agent 嘅人睇清楚。你個 team 有冇人，將管理員 key 擺喺 agent 會經過嘅個 config 入面？AWS 唔會同你講邊個攞緊個 key，呢個係平台設計，唔係漏洞。權限隔离要喺 agent 身分層面做，唔係喺開發者層面做。
阿調｜深度調教
