Agentic AI 讓自主變成資安題

我把 Forbes 的 agentic AI 觀點拆成開發者能用的治理模板，重點是權限、漂移與可追責。

我追 agentic AI 一陣子了，越看越不對勁。demo 很漂亮，流程也很順，像是終於把模型接進世界了；但一碰到真工具、真權限、真資料，事情就開始歪。我做過那種看起來很聰明的 agent，會查資料、會開 ticket、會呼叫 API，結果它最像的不是員工，是一個很有禮貌、但拿到 shell 權限的實習生。它不一定亂講，但它會很自然地把「我可以做」誤認成「我應該做」。

這也是我會去看 Forbes 的 Agentic AI topic page 的原因。它不是什麼漂亮的總結頁，反而有點雜，像一疊不同作者在同一件事上反覆敲桌子：agent 的問題，已經不是「回答得好不好」，而是「它被授權能做什麼」。裡面我特別在意 Güney Yıldız、Dara-Abasi Ita、Lance Eliot 這幾位的脈絡，因為他們講的不是炫技，是權限、漂移、治理這些真正會出事的地方。來源頁沒有提供這個 topic 的總瀏覽數，我就不亂掰。

別再把 agentic AI 當成聊天機器人加按鈕

The primary AI security threat has shifted from data leakage to agent authority.

翻譯一下就是：以前大家怕模型偷看資料，現在更該怕模型拿著資料去做事。這是兩種完全不同的風險。聊天機器人漏一段敏感資訊，很糟；但 agent 如果能直接幫你送款、開機器、跑程式、改設定，那它已經不是「回覆工具」，而是「行動入口」。

Forbes 在 topic page 裡一直繞回這個點：企業真正要管的，不是模型會不會講漂亮話，而是它在企業裡能不能被授權執行動作。這句話我很買單，因為它逼你把問題從「回答品質」換成「行為邊界」。

我自己踩過這坑。以前做一個支援 agent，讓它可以查帳號資料、建 ticket、補欄位。測試環境超順，到了真實使用者那邊就開始出現那種很討人厭的自信：使用者只是問「這筆怎麼看」，它就順手幫你做了某個動作。它不是故意害人，但它把模糊意圖翻成了具體執行，這就是問題。

實操寫法很簡單：把 inference 跟 execution 切開。模型可以提案，系統可以驗證，真正的副作用只能交給獨立控制層。你不要讓 agent 直接握著最後一把刀。

• 預設只給 read-only 權限。
• 不可逆動作一定要人類確認。
• 每次 tool call 都要記錄 user、agent、prompt、結果。
• UI 和 backend 都要把「建議」跟「執行」分開顯示。

如果你用 LangChain 或 OpenAI 的 agent 工具，規則也一樣。框架只是讓你更快把東西接起來，不會自動幫你把責任接走。

資料外洩只是老問題，現在更麻煩的是行為被操控

以前 AI 資安最直覺的故事，就是不要外洩資料。不要把整個資料庫塞進 prompt，不要讓模型記住 PII，不要把 secrets 丟到上下文。這些都還是真的，但 Forbes 這組內容提醒我一件更麻煩的事：agent 不必漏資料，也能造成傷害。

也就是說，攻擊者不一定要把資料偷出去才算贏。只要他能用自然語言把內部 agent 帶歪，agent 就可能幫他寫惡意程式、跑未授權指令、串起本來不該串的工作流。這種攻擊很陰，因為它看起來像正常互動，實際上是在借你的權限做壞事。

這會直接改變開發者的思考方式。我們以前習慣看 credentials、看 network boundary、看誰能讀什麼；但 agentic 系統把邊界弄糊了。模型本身不一定有登入身分，但應用層常常會把它繼承成某種「可代表使用者行動」的角色。這就夠危險了。

我看過團隊很天真地以為：只要 agent 看不到 secret，就不會出事。這想法很省事，也很錯。它不需要知道 secret，只要能觸發一條有權限的 workflow，就足夠把事做歪。

實操寫法是：你要 threat-model 的不是資料面，而是 action surface。先問這幾個問題：

• 如果 user prompt 是惡意的，agent 會做什麼？
• 如果 tool response 被污染，agent 會怎麼接著走？
• 如果它重試、循環、自我修正，會不會越修越錯？
• 哪些動作不管怎樣都要人類確認？

如果你想看更廣的攻擊面討論，可以順手看 Mindgard，Forbes 也有提到 Aaron Portnoy 這條線。重點不是某一家廠商最神，而是你要接受一件事：現在的攻擊面是行為，不只是資訊。

Agent drift 不是玄學，是很貴的慢性失控

To manage AI agent "drift" and risk, companies are developing new governance layers.

翻成白話就是：agent 不會只壞一次，它會慢慢歪掉。今天多一個 tool，明天改一下 system prompt，後天加 retry，再後天接 memory，最後你得到一個會替自己找理由的自動化怪獸。看起來每一步都合理，合起來就很容易失控。

Forbes 把這件事拉到治理層，我覺得合理，但我會說得更直白：漂移最早是工程問題，不是董事會問題。你先在開發階段就會看到它。demo 的 happy path 很漂亮，真的上線後，使用者講話沒那麼整齊、工具回應沒那麼乾淨、資料檢索沒那麼穩，agent 就開始往「完成任務」而不是「正確完成任務」的方向滑。

我自己遇過最煩的一次，就是只改了 system prompt 和一個 tool schema，agent 的行為就變了。沒有被駭，沒有外部攻擊，就是單純的 entropy。它開始更積極地補洞、猜意圖、自己收尾，然後把一些本來該停下來問人的地方直接做掉。事後回頭看，全部都很合理；當下看，超難察覺。

實操寫法：把 drift 定義成可量測的失敗，不要只靠感覺。你要追的是 agent 的行為有沒有持續符合政策，而不是它今天看起來聰不聰明。

• 按 task type 統計 tool-call 頻率。
• 看需要人工介入的比例有沒有上升。
• 追蹤每 1,000 次 action 的 policy violation。
• 比較 prompt 或 tool 變更前後的任務正確率。

如果你有在做 eval，不要只看答案品質。要看 action quality。模型嘴巴很會講，不代表它操作得對。這個坑我真的看太多人掉進去。

治理層不是官僚，是把你從事故裡撈出來的工程

Forbes 一直提 governance layers，我覺得不是在賣弄名詞，而是在講一個很現實的事：當 agent 能行動，你就不能讓它裸奔進 production。很多團隊一聽到治理就翻白眼，以為那是文件、審批、會議、流程地獄。其實在 agentic 系統裡，治理常常只是最基本的工程設計，目的是讓系統不要自己把自己玩壞。

我特別注意到裡面提到 supervisor agents 和 digital identities。這方向是對的。我要的不是一個巨大中央委員會去管每個 prompt，我要的是可以檢查、限制、歸因的模組化控制。Supervisor agent 比靜態規則引擎更有上下文，digital identity 則讓每個 agent 有可追蹤的身分，不會出事之後只剩一句「是系統做的」。

我做過多 agent 系統，最痛的不是讓它動，而是出事後你根本說不清楚是誰動的。多層委派、重試、fallback、handoff 一疊上去，沒有一開始設計好 attribution，trace 會直接變成沼澤。

實操寫法：每個 agent 都要有穩定身分，每個動作都要能回溯。不要讓「the agent」變成日誌裡一坨模糊的黑箱。

• Agent ID
• Parent request ID
• Tool name 與版本
• Policy decision 與原因
• Human approver，如果有的話

這不是過度設計，這是你不想花三天重建一條壞掉的 action chain 時，唯一比較像樣的保險。

ERP 和 fintech 正在被機器 actor 重寫

Forbes 裡另一個很實際的訊號，是 enterprise software 正在被重新架構給 agent 用。這件事我覺得很重要，因為它告訴你痛點會落在哪裡。ERP、fintech 這些系統原本是給人類排隊、簽核、點選用的；agentic workflows 逼它們改成能承受機器 actor 自己跑流程。

Dara-Abasi Ita 在 fintech 那篇講得很直接：如果 AI agent 會替企業移動金流，那種原本為人類審批設計的軟體架構就不太對了。我同意。舊流程是圍繞著「人按下一步」設計的，新流程得撐住自動化意圖、自動重試，還有自動犯錯。

很多團隊在這裡會偷懶，直接把 agent 接到 legacy system 上，然後說自己完成轉型。沒有，那只是做了一個脆弱的 adapter，外面包一層很會講話的殼。只要下游系統還假設每一步都會有真人確認，你的 agent 不是卡住，就是想辦法繞過去。

實操寫法：不要再假裝舊 approval chain 還適用。你要把 workflow 改成針對 machine actor 設計，包含 policy boundary、machine-readable approval、以及清楚分開 request / review / execution。

如果你在 fintech 或 ERP，我會直接把每個動作分成三類：

• 可完全自動化而且可逆
• 可自動化但必須經過 approval
• 只能由人類執行

這個分類聽起來很基本，但它會逼產品、資安、法遵一起停止打太極。順便也比較好對 audit 說明，雖然這件事很煩，但本來就是工作的一部分。

這份 coverage 最有用的地方，是它不裝樂觀

我喜歡 Forbes 這頁的原因，是它沒有把 agentic AI 包裝成只會帶來好處的故事。它一邊講 adoption，一邊一直提醒你權限、風險、治理、漂移、企業重構。這種拉扯才像真實世界。你如果只看 hype，最後會做出漂亮 demo；你如果只看恐懼，最後什麼都不敢上。

真正能活下來的系統，通常都在中間：承認 agent 的價值就是它能動手，但同時把它的行動限制在可觀測、可追責、可能回滾的範圍內。這不是保守，這是工程常識。

對我來說，這整份 topic page 最值得拿走的，不是某一篇單獨文章，而是它把問題講清楚了：現在要問的不是 autonomous agents 到底真不真，而是你的系統分不分得清 suggestion、decision、execution。分不清，你做的不是 agentic software，你做的是一個會動作的風險包。

實操寫法也很簡單：把每個 agent 都當成「能力很強，但不完全可信」的操作員。先過 policy，再過 verification，最後才進 logging。這聽起來很硬，但比事後補洞便宜多了。

我混這圈子夠久了，知道「先上線再說」在 agent 世界裡通常不是效率，是事故預告。

可抄的模板

# Agentic AI governance template for production teams

## 1) Agent identity
- Agent name:
- Agent purpose:
- Owner team:
- Parent system:
- Environment:
- Stable agent ID:

## 2) Allowed actions
- Read-only tools:
- Write tools:
- External systems:
- Data scopes:
- Time limits:
- Maximum retries:

## 3) Forbidden actions
- Never execute:
- Never access:
- Never infer:
- Never auto-approve:
- Never bypass human review:

## 4) Approval policy
- Actions requiring human approval:
- Actions requiring supervisor-agent review:
- Actions allowed autonomously:
- Escalation path:
- Approval timeout behavior:

## 5) Drift controls
- Eval suite name:
- Drift metrics:
- Re-test cadence:
- Change triggers:
- Rollback condition:
- Alert threshold:

## 6) Logging requirements
For every agent action, log:
- request_id
- agent_id
- parent_request_id
- user_id
- tool_name
- tool_version
- prompt_hash
- policy_decision
- policy_reason
- action_result
- approver_id
- timestamp
- trace_id

## 7) Incident response
If the agent behaves unexpectedly:
1. Disable write access
2. Freeze tool execution
3. Capture traces
4. Review policy decision logs
5. Re-run evals on the failing path
6. Restore only after approval

## 8) Review checklist
Before shipping a new agent:
- [ ] The agent has a stable identity
- [ ] Tool permissions are least-privilege
- [ ] High-risk actions require approval
- [ ] Logs are complete and searchable
- [ ] Drift metrics are defined
- [ ] Rollback is documented
- [ ] Human override exists
- [ ] Reversible actions are marked
- [ ] Irreversible actions are blocked by default

## 9) Copy-ready policy statement
This agent may suggest and prepare actions, but it may only execute actions that are explicitly permitted by policy, logged with full traceability, and approved when required by risk level.

## 10) Minimal operating rule
If the system cannot explain why the agent acted, the action is not production-safe.

這段我故意寫得很直白，因為我不想再看那種滿篇 AI governance、responsible autonomy、operational excellence 的空話。你可以直接把它貼進 design doc、runbook、kickoff ticket，先把底線畫出來再說。

來源致謝：原始脈絡來自 Forbes 的 Agentic AI topic page，以及它串起來的相關報導；我這篇的拆解跟模板是我自己整理的，核心觀點則是從這些文章衍生出來的。