📌 本文重點
- Agent 不能當安全邊界
- 安全控制應落在工具層與基礎設施層
- 透過分層權限、限額與 Guard 才能安全上線
- 不要把 production credential 直接塞給 Agent
很多團隊把「多代理、自動化工作流」直接接到真實帳號、真實金流、真實網路資源上，心裡想的是：
反正我在 prompt 裡有說「不要亂刪資料、不要轉太多錢」。
這篇的核心結論是：Agent 絕對不是安全邊界。你不能用「模型會乖乖聽話」來代替 RBAC、限額、rate limit、審計 log 等基本控管。本文用幾個真實事故做反推，給出可以直接套用的安全設計範式與程式碼範例。
重點說明
1. 四種常見災難模式
- 把 Agent 當人來信任
PocketOS 的案例：AI coding agent 在 9 秒內刪掉 production DB 和所有備份，原因不是模型「壞」，而是： - 找到 credential
- 直接呼叫具破壞性的
delete_database()API - 沒有任何外部限制與二次確認
💡 關鍵： 真實事故顯示，只要工具層沒有保護，Agent 能在數秒內造成不可逆的系統毀損。
- 授予過大、靜態權限
- API key 直接給到 Agent：讀寫同一組 credential，沒有 scope、沒有 TTL。
-
只想讓 Agent 「查詢」交易紀錄，卻順便給了「轉帳」權限。
-
缺乏金額與成本上限
- DN42 案例：Agent 為了掃描網路，瘋狂建立雲資源，最後把操作者帳單刷爆。
-
銀行 0.01 歐轉帳案例：小額轉帳流程缺乏額外風控，被用來做 prompt injection、流程繞過。
-
沒有動作級審計與防護
- 沒有 trace：你只看到「Agent 跑了一下」，卻不知道它 call 了什麼 API、帶了什麼參數、花了多少錢。
- 無 Guard：任何 prompt 被投餵進來，Agent 都會原樣帶著敏感資料丟到模型或外部 API。
關鍵結論：不要用 prompt 當防火牆，安全邊界必須落在『工具層 / 基礎設施層』。
2. 安全設計的技術骨架：分層權限、沙箱、限額、Guard
可以把 Agent 系統拆成四層來設計安全性：
- 工具層（Tool Layer）
- 只提供「安全封裝」過的 API 給 Agent。
- 明確區分 讀工具 與 寫/破壞性工具。
-
在破壞性工具外再包一層 Guard + Policy Engine。
-
執行層（Execution / Sandbox Layer）
-
Agent 的程式碼 & 工具呼叫，在 容器 / sandbox 中跑，掛上：
- network egress policy
- resource quota（CPU / RAM / disk）
- IAM role with least privilege
-
費用與風險控制層
- 金額上限：單次指令 / 單日 / 單用戶的金額 cap。
- 速率限制：API Gateway 上對 每個工具 設定 QPS / burst。
-
執行次數 / token 上限：避免長鏈式工具呼叫刷爆成本。
-
觀測與審計層（Observability & Audit）
- 每一次工具呼叫都寫入 結構化審計 log。
- 對異常模式（相同 IP 大量轉帳、長時間掃描某網段）做 alert。
- 在銀行/企業內部，審計 log 應能回溯：誰的 Agent、基於哪個工作流、何時、對哪個客戶做了什麼操作。
3. 對你的專案的實際好處
這些額外的安全設計，對開發者的好處非常直接：
- 讓你敢開放真實權限給 Agent，而不是永遠卡在 demo 階段。
- 降低「一次失誤全毀」的 blast radius：即使 Agent 爆走，最多刪一個 tenant 的測試資料，而不是全區 production。
- 讓合規與內部風控願意放行：有審計、有限額、可追蹤，才有機會上銀行、金融、企業內部關鍵流程。
💡 關鍵： 安全骨架讓你可以在控制可承受風險的前提下，真正把 Agent 用在 production，而不是停留在展示環境。
實作範例
1. 安全的 Tool Schema 設計：讀寫分離 + 強制二次確認
以銀行轉帳為例，先把工具拆成：
get_account_balance（純讀）create_transfer_draft（建立草稿，不真正扣款）confirm_transfer（只接受人類確認 Token）
// TypeScript: 安全版 tool schema
export const tools = {
get_account_balance: {
description: "查詢指定帳戶餘額（唯讀）",
input_schema: {
type: "object",
properties: {
account_id: { type: "string" }
},
required: ["account_id"],
additionalProperties: false
},
// 後端實作會強制用呼叫者的 user_id 做授權檢查
},
create_transfer_draft: {
description: "建立轉帳草稿，不會真的送出，會回傳 draft_id 與風險評分",
input_schema: {
type: "object",
properties: {
from_account: { type: "string" },
to_account: { type: "string" },
amount: { type: "number", minimum: 0.01 },
currency: { type: "string", enum: ["EUR", "USD", "TWD"] },
note: { type: "string" }
},
required: ["from_account", "to_account", "amount", "currency"],
additionalProperties: false
}
},
confirm_transfer: {
description: "確認既有轉帳草稿，只接受人類確認 token",
input_schema: {
type: "object",
properties: {
draft_id: { type: "string" },
user_confirmation_token: { type: "string" } // 只從前端 UI 注入，Agent 拿不到
},
required: ["draft_id", "user_confirmation_token"],
additionalProperties: false
}
}
} as const
重點：
- Agent 只能從模型側呼叫
get_account_balance/create_transfer_draft。 confirm_transfer的user_confirmation_token必須來自人類 UI（例如 SMS OTP / 硬體 token），不透過模型。- 小額轉帳（例如 0.01 歐）仍要經過風險評分，避免被用來當作 prompt injection 的側信道。
2. 在 API Gateway / RBAC 層包住 Agent 工具調用
以下是假想的 API Gateway（以 Kong / Envoy 風格）設定，針對 Agent 工具做 角色 + 限額 控制：
# gateway-routes.yaml
routes:
- name: agent-read-tools
paths: ["/agent-tools/read"]
methods: ["POST"]
plugins:
- name: jwt
config:
claims_to_verify: ["exp"]
key_claim_name: "sub" # 綁 agent instance id
- name: acl
config:
whitelist: ["agent_read"]
- name: rate-limiting
config:
minute: 120 # 每分鐘最多 120 次工具呼叫
- name: agent-write-tools
paths: ["/agent-tools/write"]
methods: ["POST"]
plugins:
- name: jwt
- name: acl
config:
whitelist: ["agent_write"]
- name: rate-limiting
config:
minute: 10 # 寫操作極度限流
- name: request-size-limiting
config:
allowed_payload_size: 64 # 防止一次送進超大批次破壞性操作
配合後端 RBAC：
// Node.js pseudo code: 在工具 handler 中做細粒度 RBAC + 金額限制
function assertWritePermission(ctx: RequestContext, maxAmount: number) {
if (!ctx.roles.includes("agent_write")) {
throw new ForbiddenError("Agent has no write permission");
}
const amount = ctx.body.amount ?? 0;
if (amount > maxAmount) {
throw new ForbiddenError("Amount exceeds agent limit");
}
}
app.post("/agent-tools/write/transfer", (req, res) => {
const ctx = getContextFromRequest(req);
// 例如每個 Agent 最高 50 EUR，超過必須走人類流程
assertWritePermission(ctx, 50);
// ... call internal transfer service
});
實際好處：你可以很放心地說「Agent 可以幫你轉帳」，但確定它永遠不會幫你一次轉出 10 萬，只會在可承受的風險範圍內操作。
3. Guard 與敏感資料掃描：避免 Agent 自動外洩機密
參考 Cursor 等實作，你可以在「呼叫模型前」加上三道 Guard：
- Input Guard：掃描要送進模型的內容，找出 API key / 密碼，紅標或遮罩。
- Output Guard：掃描模型輸出，要是模型要求「貼上你的私鑰」，直接攔截。
- Tool Guard：在執行工具前檢查參數是否違反政策（例如掃描內網、批次刪資料）。
簡單的 Input Guard 例子：
# Python pseudo code: input guard
import re
SECRET_PATTERNS = [
re.compile(r"sk-[A-Za-z0-9]{32,}"), # API key 格式
re.compile(r"-----BEGIN PRIVATE KEY-----[\s\S]+?-----END PRIVATE KEY-----"),
]
def redact_secrets(text: str) -> str:
redacted = text
for p in SECRET_PATTERNS:
redacted = p.sub("[REDACTED_SECRET]", redacted)
return redacted
# 在送給 LLM 前
prompt = redact_secrets(user_input + context_snippets)
注意：不要只在前端掃，Agent 自己組裝的 context（例如程式碼、log、設定檔）也要過一遍 Guard，不然它會自己把 .env 塞進去。
4. 審計與異常偵測：之後一定會被問到的東西
在銀行或企業內部，合規與內審會問的問題通常是：
- 這筆錯誤的轉帳 / 刪除操作是 哪個 Agent 做的？
- 它當時看到什麼 context？是誰觸發的？
- 是否有類似行為持續發生？
你需要的是動作級審計 log：
{
"timestamp": "2026-06-13T09:01:23Z",
"agent_id": "agent-123",
"user_id": "user-456",
"workflow_id": "payroll-v2",
"tool_name": "create_transfer_draft",
"input": {
"from_account": "...masked...",
"to_account": "...masked...",
"amount": 42.5,
"currency": "EUR"
},
"risk_score": 0.78,
"policy_decision": "allowed",
"cost_estimate": {
"cloud_cost": 0.0004,
"fee": 0.1
}
}
這些 log 可以餵給 SIEM / 內部風控系統，針對：
- 某 Agent 在短時間內大量建立轉帳草稿。
- 某工作流突然開始頻繁掃描不應存取的網段（DN42 類似情境）。
直接做告警或自動降權（例如暫時停用該 Agent 的 write tool）。
💡 關鍵： 有結構化審計與異常偵測，才能在出事後追責與調整政策，而不是只能事後猜測。
建議與注意事項
1. 把「模型可以做什麼」當成風控產品，而不是單純開發功能
實務上可以這樣落地：
- 先設計 policy，再設計 tool：例如「Agent 單次轉帳上限 50 EUR、一日累計 200 EUR」，然後才決定工具 API。
- 把工具視為「風控之後的介面」，而非直接包內部 microservice。
2. 不要把 production credential 直接塞進 Agent
常見坑：
-
在
.env裡放DB_URL_PROD，Agent 的 code tool 一掃專案就看到了。 -
解法：
- Agent 跑在 專用 service account + IAM role 上。
- 只能打透過 Gateway / policy engine 包過的 API，不直接碰 DB / message queue。
3. 把「人類在 loop 裡」當成正式設計的一部分
- 高風險動作預設需要人類確認：
- 破壞性工具強制
user_confirmation_token。 - UI 上顯示 Agent 的建議，讓使用者點擊確認。
- 這不是「很土」；在銀行監管語境裡，這叫做 four-eyes principle（雙人覆核），是你讓 Agent 能真正上線的關鍵。
4. 上線前的簡版安全 checklist
你可以直接拿這份清單對照專案：
- 工具層：
- [ ] 讀寫工具有清楚分離？
-
[ ] 破壞性工具是否有二次確認 / 額外 policy？
-
權限與憑證：
- [ ] Agent 使用的 credential 是否有最小權限與有效期限？
-
[ ] Agent 是否只能透過 Gateway / policy engine 存取內部服務？
-
費用與風險上限：
- [ ] 有設定單次 / 單日金額上限？
-
[ ] 有 API rate limit / 執行次數 / token cap？
-
Guard：
- [ ] 呼叫模型前是否做敏感資料掃描與遮罩？
-
[ ] Tool 執行前是否跑過 policy check？
-
觀測與審計：
- [ ] 所有工具呼叫都有結構化 log？
- [ ] 有針對異常模式的 alert（大量轉帳、大量雲資源建立）？
只要你把安全邊界畫在這些「實際可控的層」上，而不是畫在 prompt 上，你的 Agent 就能在真實環境裡幫忙做事，而不是在 9 秒內幫你把公司刪掉。
🚀 你現在可以做的事
- 審查現有 Agent 工具清單，將讀寫操作拆分並為破壞性工具加上二次確認機制
- 在 API Gateway 為 Agent 加上角色、rate limit 與金額上限等策略，並實作細粒度 RBAC
- 為所有 Agent 呼叫流程加入敏感資料 Guard 與結構化審計 log，串接既有監控／風控系統
發佈留言