怎麼做 AI 助理端到端安全

這篇教你替 AI 助理建立最小權限、資料隔離、加密、稽核與高風險審批，做出可落地的安全基線。

這篇給會把 AI 助理接到檔案、工具、內部系統的開發者、平台工程師與資安團隊看。照著做完，你會得到一套可直接上線的安全基線：獨立身分、受限資料路徑、加密傳輸與儲存、可追查的操作紀錄，以及高風險動作的人工把關。

本文也對應近期對 AI 助理資料層風險的討論，重點不是把模型當成失控主體，而是先把權限、資料與審計做好，避免它在正常操作下造成事故。參考文件可先看 OpenAI docs 與 OpenAI Agents SDK。

開始之前

• Node 20+ 或 Python 3.11+。
• AI 供應商帳號與 API key。
• Secrets Manager，例如 AWS Secrets Manager、HashiCorp Vault 或 GCP Secret Manager。
• 已啟用靜態加密的資料庫或物件儲存。
• 集中式日誌系統，例如 Datadog、Splunk、OpenTelemetry 或 CloudWatch。
• 可建立 service account、role 與 policy 的 IAM 或 RBAC 權限。

Step 1: 建立助理專用服務帳號

目的：把 AI 助理從人員帳號切開，讓它只用一個可控身分執行動作。

先建立專用 service account 或 role，再把可讀、可寫、可呼叫的資源逐一列出，只保留任務必需項目。若助理只需查知識庫，就不要順手給它刪除資料、匯出全量資料或改 IAM 的權限。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::support-kb/*"]
    },
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query"],
      "Resource": ["arn:aws:dynamodb:us-east-1:123456789012:table/faq-index"]
    }
  ]
}

驗收：你應該看到助理在日誌中以自己的身分登入，且未授權動作會回傳 authorization error。

Step 2: 分級並隔離敏感資料路徑

目的：讓助理只碰到完成任務所需的資料層級，不把所有內容都當成可檢索資料。

先把資料分成公開、內部、機密與受管制四級，再依級別切分儲存桶、索引或檢索條件。若你做 RAG，搜尋前就要先套政策，避免客戶秘密、token、私有原始碼被塞進 prompt。

實作時，把 row-level security、文件 ACL 與內容過濾放在模型前面，不要等模型看完文字才事後遮罩。若你使用 embeddings，向量索引要跟來源資料套用同一套存取規則。

驗收：你應該看到助理只回傳使用者有權限讀取的文件，且被遮罩或拒絕的內容不會出現在 prompt trace 或 response log。

Step 3: 加密秘密與資料傳輸

目的：降低流量被攔截或儲存體被竊取時的可用資訊量。

把 API key、資料庫憑證與簽章 secret 放進 secrets manager，不要寫在環境檔或原始碼。助理、協調器、模型端點、檢索服務與資料儲存之間全部啟用 TLS，且所有保存 prompts、outputs、embeddings、audit trail 的系統都要開啟靜態加密。

若你需要保存對話歷史，請用受管金鑰加密，並把保留期設成產品真正需要的最短時間。金鑰要定期輪替，發現疑似外洩後也要立即輪替。

驗收：你應該看到程式碼搜尋不到明文 secret，網路追蹤顯示 TLS 已啟用，雲端主控台或基礎架構設定也顯示儲存加密開啟。

Step 4: 紀錄每次工具呼叫與決策

目的：建立可追查的稽核鏈，能說明助理看了什麼、做了什麼、為何被允許或拒絕。

每次動作都記錄 prompt hash、使用者身分、session ID、tool 名稱、目標資源、policy decision 與 result code。把這些紀錄和一般應用日誌分開，讓資安人員能快速搜尋，也能在事件發生後保留證據。

{
  "event": "tool_call",
  "user_id": "u_1842",
  "session_id": "sess_7f2c",
  "prompt_hash": "sha256:8b1c...",
  "tool": "create_ticket",
  "resource": "zendesk",
  "decision": "deny",
  "reason": "missing approval scope"
}

驗收：你應該看到每次 tool invocation 都有完整 trail，且稽核人員能重建請求來源、套用的政策與執行結果。

Step 5: 為高風險動作加上審批閘門

目的：阻止助理自行執行不可逆或高衝擊操作。

把寄外部信件、刪除記錄、修改 IAM role、匯出客戶資料、開放網路存取等動作標成高風險，讓助理只先產生請求草稿，真正執行前必須經過人工核准或第二道政策檢查。

你可以用 queue、ticket system 或自建 approval service 來做，但重點是助理不能靠改寫請求內容或重試 tool call 來繞過閘門。

驗收：你應該看到高風險動作先進入 approval queue，只有核准後才會往下游系統送出。

Step 6: 驗證與封存安全基線

目的：把前面做好的控制變成可重複檢查的交付物，而不是一次性的設定。

建立一份安全驗收清單，逐項檢查 service account、資料分級、加密、日誌與審批流程是否都在位。再把這些檢查寫成 CI 或部署後驗證腳本，讓每次發版都能重跑。

最後把政策、角色、日誌保存期限與審批規則整理成一份安全基線文件，存進 repo 與內部知識庫，並指定每季重查一次。

驗收：你應該看到一份可版本化的安全基線文件，外加可重跑的驗證腳本與通過紀錄。

常見錯誤

• 把人員 admin token 直接給助理。修法：改成專用 role，並拆開憑證與最小權限。
• 把含 secret 的原始 prompt 原封不動寫進日誌。修法：在落盤前先遮罩 token、密碼與個資。
• 檢索層權限比來源資料更寬。修法：向量索引、文件庫與原始資料都要套用同一組 ACL 與 row-level 規則。

接下來可以看什麼

下一步可以做 prompt injection 防護、policy as code、紅隊測試與定期存取審查，讓這套基線能跟著產品規模一起維持可控。