安全設計 - Kerwin AI Information

📌 本文重點

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，串接既有監控／風控系統

標籤: 安全設計

你的 Agent 不是防火牆：實務安全設計指南