AI Agent 的能力越強(qiáng)它能訪問的東西就越多能造成的破壞也就越大。過去半年里圍繞 AI Agent 的安全事件從“概念驗證”變成了“真實生產(chǎn)事故”API 密鑰被代理工具順手發(fā)出去、Agent 在自動化流程里調(diào)用了沒有權(quán)限的高危接口、日志里完全沒有留下一次工具調(diào)用的審計記錄。很多人開始問一個問題大模型不是越來越聰明嗎為什么安全問題反而越來越像 2012 年的“云上裸奔”Vaultak 就是在這個背景下出現(xiàn)的項目。它的標(biāo)題很直白Security for AI agents為 AI 代理提供安全保護(hù)而且是在一波安全事件暴露之前就開始了構(gòu)建。這意味著它并不是事后打補丁的思路而是把 Agent 當(dāng)成一種新的應(yīng)用形態(tài)從身份、權(quán)限、密鑰、審計這些基礎(chǔ)設(shè)施層面重新設(shè)計安全邊界。這篇文章不打算堆概念。我們會先拆解 AI Agent 真正讓人頭疼的安全問題然后講清楚 Vaultak 這類“Agent 安全訪問控制層”到底解決了什么問題最后給出一個可以落地的最小示例從定義權(quán)限策略、托管密鑰到在 Agent 調(diào)用工具時完成校驗和審計。即使你現(xiàn)在還沒用上 Vaultak這套思路也可以直接套到自己的 Agent 項目里。1. 這篇文章真正要解決的問題如果你寫過或者用過 AI Agent大概率經(jīng)歷過以下場景為了讓 Agent 調(diào)用內(nèi)部 API你直接把服務(wù)賬號的 AccessKey 寫進(jìn)了環(huán)境變量結(jié)果 Agent 在對話中把授權(quán)信息當(dāng)作上下文的一部分“分享”給了模型最后由 API 網(wǎng)關(guān)執(zhí)行時才發(fā)現(xiàn)來源不可信。Agent 的工具列表里掛著十幾個函數(shù)腳本為了圖省事給所有工具都配了同一個角色?？雌饋砟苡玫魏我粋€工具被提示詞注入利用攻擊者就可以拿到全部能力。Agent 跑完一個自動化任務(wù)后你根本不知道它到底調(diào)用了哪些工具、傳了哪些參數(shù)、消耗了哪些憑證。出了事只能翻模型日志和函數(shù)日志費時費力還不可靠。這些問題的本質(zhì)并不是“模型不夠聰明”而是Agent 的權(quán)限模型還停留在傳統(tǒng)應(yīng)用的思路里。傳統(tǒng)應(yīng)用有明確的用戶身份、服務(wù)身份、審計日志但 Agent 是多步推理、動態(tài)選擇工具、自動調(diào)用外部服務(wù)的執(zhí)行體它每一步的“意圖”都來自模型輸出而模型輸出可以被用戶輸入污染。換句話說Agent 的安全問題不僅是“密鑰管沒管好”還包括“執(zhí)行鏈路里的每一步是否可信”。本文要解決的核心問題有三個理解 Agent 安全與傳統(tǒng)應(yīng)用安全的差異。認(rèn)識 Vaultak 這類“Agent 安全基礎(chǔ)設(shè)施”的定位與能力。學(xué)會在真實項目里用最小權(quán)限、密鑰托管、調(diào)用審計的思路保護(hù)自己的 Agent。閱讀之前請先有一個判斷AI Agent 的出現(xiàn)把安全問題的重心從“人訪問系統(tǒng)”轉(zhuǎn)移到了“程序替人訪問系統(tǒng)”。前者靠 IAM 已經(jīng)做了幾十年后者目前仍然處于早期而 Vaultak 正是在這個概念還沒變成熱點時就提前布的局。2. AI Agent 安全的核心概念與威脅模型先解釋幾個容易混淆的概念。2.1 什么是 Agent 安全Agent 安全不是簡單的“給模型加個防火墻”而是對 Agent 執(zhí)行全鏈路進(jìn)行可信控制。它至少包括身份層Agent 以誰的身份行動是用戶身份、服務(wù)身份還是 Agent 自身身份權(quán)限層Agent 被允許調(diào)用什么工具、讀寫什么數(shù)據(jù)、操作什么系統(tǒng)密鑰層Agent 調(diào)用的外部服務(wù)憑證如何安全存儲和注入審計層Agent 每一步動作是否可追蹤、可回放、可告警傳統(tǒng)應(yīng)用開發(fā)中這些能力通常由 Spring Security、AWS IAM、內(nèi)部權(quán)限中心等平臺提供。但在 Agent 場景里工具調(diào)用是運行時動態(tài)生成的權(quán)限判斷就不能只發(fā)生在“登錄時”或“發(fā)布時”而必須發(fā)生在“每一次工具調(diào)用時”。2.2 AI Agent 最典型的四類安全風(fēng)險理解風(fēng)險才能理解 Vaultak 的設(shè)計出發(fā)點。四類風(fēng)險可以總結(jié)為風(fēng)險類型典型場景危害提示詞注入惡意文本誘導(dǎo) Agent 調(diào)用非預(yù)期工具信息泄露、越權(quán)操作權(quán)限過度Agent 工具綁定了過大角色敏感數(shù)據(jù)被誤讀取憑證泄露API Key、數(shù)據(jù)庫密碼暴露在環(huán)境變量或日志中外部攻擊者直接接管服務(wù)審計缺失Agent 調(diào)用鏈無法追蹤安全事件無法復(fù)現(xiàn)和定責(zé)這里面最容易被低估的是第一條提示詞注入。傳統(tǒng) API 只接收結(jié)構(gòu)化參數(shù)但 Agent 要把自然語言轉(zhuǎn)化為工具調(diào)用這一層轉(zhuǎn)換天然擴(kuò)大了攻擊面。攻擊者可能不需要直接破解你的服務(wù)器只需要構(gòu)造一段文本讓 Agent 在“理解意圖”時執(zhí)行了不該執(zhí)行的操作。因此任何 Agent 安全方案都必須做到無論模型說什么實際執(zhí)行前都要經(jīng)過獨立的策略判斷。2.3 為什么“密鑰管理 日志”不夠有人會說我只要把密鑰放進(jìn) KMS再加一個日志系統(tǒng)不就行了嗎從表面看是的但實際運營中會出現(xiàn)兩個問題。第一密鑰生命周期和 Agent 的工具調(diào)用頻率不匹配。傳統(tǒng)密鑰輪換按天或按月而 Agent 可能在一次任務(wù)里調(diào)用上百次工具每一次都可能用到不同的憑證。如果密鑰只依賴平臺側(cè)管理Agent 側(cè)的權(quán)限邊界無法細(xì)化到“單個工具”。第二日志只是記錄不是決策。日志系統(tǒng)能告訴你“某 Agent 調(diào)用了刪除接口”但沒法在調(diào)用發(fā)生前阻止它。Agent 安全需要的是一個實時策略引擎——在工具執(zhí)行前判斷“這一次調(diào)用是否被允許”而不是事后翻日志。Vaultak 的價值就是把密鑰管理和策略引擎放到了 Agent 與外部服務(wù)之間成為一道獨立的訪問控制層。這和 Spring Security 在 Java Web 應(yīng)用里的位置很像只不過它保護(hù)的主體不再是“用戶請求”而是“Agent 工具調(diào)用”。3. Vaultak 的定位與設(shè)計思路從項目標(biāo)題看Vaultak 最想強(qiáng)調(diào)的一點是它是在 AI Agent 安全事件大規(guī)模暴露之前就開始構(gòu)建的。這個定位很重要因為它意味著項目不是圍繞某個具體漏洞打的補丁而是從一開始就試圖建立一套適用于 Agent 的通用安全模型。3.1 Vaultak 解決的是哪一層問題你可以在下面這條鏈路上理解 Vaultak 的位置用戶輸入 / 外部數(shù)據(jù) ↓ 大模型推理并生成工具調(diào)用 ↓ [ Vaultak 安全層 ] ← 權(quán)限校驗、密鑰注入、審計記錄 ↓ 外部工具 / API / 數(shù)據(jù)庫安全層的作用可以拆成四個動作識別知道當(dāng)前 Agent 是誰、屬于哪個租戶、準(zhǔn)備調(diào)用哪個工具。校驗根據(jù)預(yù)定義策略判斷該 Agent 是否有權(quán)限執(zhí)行這次調(diào)用。注入為合法調(diào)用動態(tài)提供憑證避免密鑰出現(xiàn)在 Agent 的上下文或日志里。記錄將調(diào)用請求、策略決策、執(zhí)行結(jié)果寫入審計存儲。從公開信息看Vaultak 強(qiáng)調(diào)“built before the breaches started”傳遞的核心判斷是Agent 應(yīng)用的安全設(shè)計應(yīng)該是前置的而不是等安全事故發(fā)生后被迫補齊。對開發(fā)者來說這意味著選擇 Agent 安全方案時應(yīng)該關(guān)注它的訪問控制模型是否完整而不是關(guān)注它事后能補救多少漏洞。3.2 和傳統(tǒng)安全中間件的區(qū)別很容易把 Vaultak 和 Spring Security 這類框架放在一起對比但它們面向的對象完全不同。對比維度傳統(tǒng)安全框架如 Spring SecurityAgent 安全層如 Vaultak保護(hù)對象用戶請求 / Web 接口Agent 的工具調(diào)用驗證時機(jī)請求進(jìn)入時Agent 生成工具調(diào)用后、執(zhí)行外部調(diào)用前權(quán)限模型用戶角色、URL 權(quán)限Agent 身份、工具級權(quán)限、上下文策略風(fēng)險關(guān)注點越權(quán)訪問、認(rèn)證繞過提示詞注入、動態(tài)工具選擇、憑證泄露審計內(nèi)容請求日志模型輸出 工具調(diào)用 策略決策不是說傳統(tǒng)框架不重要而是 Agent 需要新的編排層。Vaultak 更像是“為 Agent 打造的 API Gateway 密鑰管理系統(tǒng)”的結(jié)合體只不過策略判定需要理解 Agent 的工具調(diào)用語義而不是簡單的 URL 匹配。3.3 設(shè)計中的三個關(guān)鍵原則從安全工程經(jīng)驗看這類工具的設(shè)計原則大致有三條默認(rèn)拒絕。未明確授權(quán)的工具調(diào)用直接拒絕。最小注入。憑證只在該次調(diào)用期間注入用完即失效不進(jìn)入模型上下文。全鏈路審計。從用戶輸入到模型輸出再到工具執(zhí)行所有中間步驟都保留可追蹤記錄。這三條原則也是你在自己項目中可以立刻用起來的。4. 環(huán)境準(zhǔn)備與前置條件現(xiàn)在進(jìn)入實操部分。由于 Vaultak 仍是一個早期項目具體接入方式可能會隨版本變化。這里我們不把 API 寫死而是用一組通用示例展示“Agent 安全訪問控制層”的接入思路。你可以在理解思路后根據(jù) Vaultak 官方文檔替換成對應(yīng)的真實接口。4.1 推薦環(huán)境本文示例以 Python 3.10 為例操作系統(tǒng)不限Windows/macOS/Linux 均可。需要準(zhǔn)備Python 3.10 或更高版本并能夠創(chuàng)建虛擬環(huán)境。一個可調(diào)用 OpenAI 接口的大模型客戶端庫用來模擬 Agent 工具調(diào)用。HTTP 請求庫比如httpx或requests。一個本地 JSON 文件或 SQLite 數(shù)據(jù)庫用來模擬審計日志存儲。如果你使用的是 Java 技術(shù)棧也可以把思路遷移到 Spring Boot 的攔截器或網(wǎng)關(guān)層。這并不沖突。4.2 創(chuàng)建項目結(jié)構(gòu)和虛擬環(huán)境我們建議用下面的目錄結(jié)構(gòu)管理示例代碼vaultak-demo/ ├── agent.py # Agent 主邏輯 ├── policy.json # 權(quán)限策略定義 ├── vault_client.py # 安全客戶端模擬 Vaultak 接入 ├── tools.py # 工具函數(shù)定義 └── audit.log # 審計日志輸出文件先創(chuàng)建虛擬環(huán)境并安裝依賴mkdir vaultak-demo cd vaultak-demo python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install openai httpx這里我們故意不安裝任何特定的 Vaultak SDK因為不同階段的 SDK 差異較大。重點是先跑通“安全層攔截 策略校驗 憑證注入 審計”的完整鏈路。5. 核心流程拆解5.1 定義工具與權(quán)限模型在 Agent 場景里每個工具需要有明確的 ID、名稱、權(quán)限邊界。我們先用一個簡單的工具函數(shù)模擬兩個外部服務(wù)# 文件路徑vaultak-demo/tools.py def read_user_profile(user_id: str) - dict: 讀取用戶個人資料。真實環(huán)境會調(diào)用內(nèi)部 API。 return {user_id: user_id, profile: example-profile} def delete_user_record(user_id: str) - dict: 刪除用戶記錄。高風(fēng)險操作默認(rèn)禁止。 return {deleted: user_id}這兩個工具看起來很簡單但權(quán)限差異巨大。前者是讀操作后者是寫操作。如果 Agent 在推理過程中被注入惡意指令試圖調(diào)用delete_user_record安全層必須有能力拒絕。5.2 定義權(quán)限策略權(quán)限策略用 JSON 描述。核心結(jié)構(gòu)是某種 Agent 身份能調(diào)用哪些工具以及調(diào)用時有哪些限制。{ agent_roles: { customer_service: { allowed_tools: [read_user_profile], denied_tools: [delete_user_record], allowed_parameters: { read_user_profile: [user_id] } } }, default_policy: deny }注意default_policy: deny是重點。沒有明確允許的工具調(diào)用一律拒絕。這比在工具層手動加 if 判斷要可靠得多。5.3 安全客戶端設(shè)計接下來編寫一個輕量級客戶端模擬 Vaultak 的三步動作校驗策略、注入臨時憑證、記錄審計日志。# 文件路徑vaultak-demo/vault_client.py import datetime import json import os class VaultClient: def __init__(self, policy_path: str, audit_path: str audit.log): with open(policy_path, r, encodingutf-8) as f: self.policy json.load(f) self.audit_path audit_path def _check_tool_permission(self, role: str, tool_name: str) - bool: role_policy self.policy.get(agent_roles, {}).get(role) if role_policy is None: return False if tool_name in role_policy.get(denied_tools, []): return False if tool_name not in role_policy.get(allowed_tools, []): return False return True def _get_secret(self, tool_name: str) - str: # 在這里對接真實的密鑰管理服務(wù)而不是硬編碼。 # 示例僅用于展示“臨時注入”的思想。 return os.environ.get(fTOOL_SECRET_{tool_name.upper()}, temp-secret) def _write_audit(self, role: str, tool_name: str, params: dict, decision: str): record { timestamp: datetime.datetime.utcnow().isoformat(), role: role, tool: tool_name, params: params, decision: decision, secret_used: decision allow, } with open(self.audit_path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def call_tool(self, role: str, tool_name: str, params: dict, tool_func): if not self._check_tool_permission(role, tool_name): self._write_audit(role, tool_name, params, deny) raise PermissionError(fAgent role {role} is not allowed to call {tool_name}) secret self._get_secret(tool_name) # 真實實現(xiàn)中secret 應(yīng)當(dāng)通過 headers 等安全方式傳給外部服務(wù)而不是打進(jìn)日志 result tool_func(**params) self._write_audit(role, tool_name, params, allow) return {result: result, secret_injected: bool(secret)}這個客戶端把安全邏輯從 Agent 主流程中抽離了出來。Agent 只需要調(diào)用vault.call_tool不需要關(guān)心策略細(xì)節(jié)。5.4 Agent 主流程集成在 Agent 主流程中我們模擬大模型生成了工具調(diào)用請求然后經(jīng)過安全層執(zhí)行。這里為了演示清晰用固定 JSON 代替模型輸出。# 文件路徑vaultak-demo/agent.py import json from tools import delete_user_record, read_user_profile from vault_client import VaultClient # 模擬大模型返回的工具調(diào)用 MOCK_MODEL_OUTPUT { role: customer_service, tool_calls: [ {name: read_user_profile, params: {user_id: u_123}}, {name: delete_user_record, params: {user_id: u_123}}, ], } def main(): vault VaultClient(policy.json) for tool_call in MOCK_MODEL_OUTPUT[tool_calls]: tool_name tool_call[name] params tool_call[params] if tool_name read_user_profile: tool_func read_user_profile elif tool_name delete_user_record: tool_func delete_user_record else: continue try: response vault.call_tool( roleMOCK_MODEL_OUTPUT[role], tool_nametool_name, paramsparams, tool_functool_func, ) print(f[ALLOW] {tool_name}: {response[result]}) except PermissionError as e: print(f[DENY] {tool_name}: {e}) if __name__ __main__: main()這段代碼里最關(guān)鍵的一步是模型輸出并不直接決定工具是否執(zhí)行安全層會再次檢查角色、工具名、參數(shù)是否合法。即使模型被提示詞注入指引去調(diào)用刪除接口只要角色策略不允許刪除操作就不會發(fā)生。6. 運行結(jié)果與效果驗證我們來運行這段示例并檢查審計日志。6.1 運行命令cd vaultak-demo python agent.py預(yù)期輸出如下[ALLOW] read_user_profile: {user_id: u_123, profile: example-profile} [DENY] delete_user_record: Agent role customer_service is not allowed to call delete_user_record第一個工具調(diào)用被允許第二個被拒絕。這樣的結(jié)果說明安全層確實起到了“獨立于模型”的攔截作用。6.2 檢查審計日志運行后打開audit.log你應(yīng)該能看到兩條 JSON 記錄{timestamp: 2025-01-01T12:00:00.000000, role: customer_service, tool: read_user_profile, params: {user_id: u_123}, decision: allow, secret_used: true} {timestamp: 2025-01-01T12:00:01.000000, role: customer_service, tool: delete_user_record, params: {user_id: u_123}, decision: deny, secret_used: false}審計日志是 Agent 安全事故排查的第一手資料。如果線上出現(xiàn)異常調(diào)用你可以根據(jù)timestamp和role快速定位可疑 Agent 和行為鏈。6.3 驗證失敗時的排查路徑如果運行后輸出不如預(yù)期建議按順序排查檢查policy.json是否被正確讀取路徑是否正確。檢查 JSON 格式注意不要在注釋或尾逗號上出錯。如果所有工具都被拒絕優(yōu)先確認(rèn)當(dāng)前角色是否被寫入agent_roles。如果日志沒有寫入確認(rèn)audit.log所在目錄的寫權(quán)限。7. 常見問題與排查思路在實際使用 Agent 安全層時你會遇到下面幾類高頻問題。這里用表格給出定位思路。問題現(xiàn)象可能原因排查方式解決方案Agent 調(diào)用工具時被全部拒絕策略中未定義當(dāng)前 agent 角色檢查 policy.json 中的角色名稱為當(dāng)前角色補充 allowed_tools 列表某個工具時而可用時而被拒參數(shù)校驗規(guī)則不匹配查看審計日志中的 params 字段調(diào)整 allowed_parameters 規(guī)則密鑰出現(xiàn)在 Agent 對話中密鑰被寫入模型上下文檢查 Agent 提示詞和記憶模塊改為通過安全層臨時注入不進(jìn)入上下文審計日志沒有記錄文件權(quán)限或?qū)懭肼窂藉e誤測試 audit.log 是否可寫調(diào)整寫權(quán)限或切換日志存儲策略修改后未生效安全客戶端沒有重新加載配置檢查客戶端初始化邏輯重啟服務(wù)或增加配置熱加載機(jī)制和傳統(tǒng)框架混淆嘗試用 Spring Security 攔截 Agent 工具調(diào)用明確工具的調(diào)用點是模型輸出不是 HTTP 請求在工具調(diào)用層單獨引入 Agent 安全網(wǎng)關(guān)這些問題的共性在于安全層必須盡量獨立于 Agent 的業(yè)務(wù)邏輯。如果安全判斷和 Agent 邏輯耦合在一起你很難判斷一次調(diào)用到底是模型的選擇還是策略生效后的結(jié)果。8. 最佳實踐與工程建議寫完最小示例后我們再看生產(chǎn)環(huán)境里應(yīng)該注意什么。Vaultak 的核心思路雖然是“給 Agent 加安全層”但工程實現(xiàn)永遠(yuǎn)比 Demo 復(fù)雜。8.1 最小權(quán)限原則要落在“工具級”而不是“角色級”很多團(tuán)隊會給 Agent 角色配置一大串權(quán)限圖省事。但 Agent 一次任務(wù)里真正用到的工具可能只有兩三個。建議把權(quán)限細(xì)化到工具級別甚至參數(shù)級別。比如“允許讀取用戶資料”和“允許讀取全部用戶資料”完全不同。這里的決策原則是每次只授權(quán)該任務(wù)所需的最小工具集合。8.2 密鑰不應(yīng)進(jìn)入模型上下文實際開發(fā)中一個常見錯誤是為了方便把外部 API Key 拼接在系統(tǒng)提示詞里或者讓 Agent 直接讀取.env文件。這等于把密鑰交給了一個可能被提示詞注入影響的模型。正確做法是讓 Agent 只傳遞工具調(diào)用意圖由安全層在調(diào)用外部服務(wù)前注入憑證并且憑證返回后立刻丟棄。這也是 Vaultak 這類工具最重要的設(shè)計目標(biāo)之一。8.3 審計日志比模型日志更重要模型日志能告訴你模型說了什么但安全審計能告訴你 Agent 做了什么。生產(chǎn)環(huán)境建議把審計日志輸出到獨立的存儲系統(tǒng)并設(shè)置不可篡改權(quán)限。一旦出現(xiàn)安全事件你可以快速回答三個問題哪個 Agent 調(diào)用了什么工具觸發(fā)這次調(diào)用的前置上下文是什么返回結(jié)果是否包含敏感信息沒有這套記錄Agent 應(yīng)用一旦出事排查成本會極其高。8.4 權(quán)限策略需要支持動態(tài)調(diào)整Agent 工具列表會頻繁變化策略配置不能寫死在代碼里。建議把策略文件放到配置中心支持熱更新。新工具接入時先設(shè)置為deny等測試通過后再放開到指定角色。不要一上來就默認(rèn)全放。8.5 安全層自身的權(quán)限要收斂越強(qiáng)大的安全系統(tǒng)越要謹(jǐn)慎處理權(quán)限。Vaultak 或類似安全服務(wù)本身應(yīng)該遵循最小權(quán)限、獨立賬號、只讀審計存儲、禁止人肉改策略等原則。所有對策略的修改應(yīng)該走變更流程并記錄審批人。9. 總結(jié)與后續(xù)學(xué)習(xí)方向回到開頭的問題AI Agent 的安全為什么不能靠傳統(tǒng) IAM 解決因為傳統(tǒng) IAM 面向的是“已經(jīng)明確的用戶和請求”而 Agent 面向的是“動態(tài)生成的意圖和工具調(diào)用”。Vaultak 這類項目選擇在 Agent 與外部服務(wù)之間插入一層獨立的安全訪問控制層用策略引擎攔截模型輸出用密鑰托管避免憑證進(jìn)入上下文用審計日志保證每次調(diào)用都有據(jù)可查。這個思路無論你最后是否使用 Vaultak都值得在 Agent 應(yīng)用里落地。如果你接下來要動手實踐建議按這個順序走先為現(xiàn)有 Agent 列出所有工具調(diào)用點畫一張“模型輸出到外部 API”的調(diào)用鏈。用最小權(quán)限原則為每個工具定義允許角色明確哪些調(diào)用默認(rèn)拒絕。把密鑰從代碼和配置文件中挪走改用安全存儲或密鑰服務(wù)。增加一次工具調(diào)用的審計日志確認(rèn)每次調(diào)用都有 trace 可以回溯。最后再評估 Vaultak 或同類工具是否能對齊你的需求避免自己重復(fù)造輪子。AI Agent 的安全還在早期但“不安全”的代價已經(jīng)越來越真實。與其等 breach 發(fā)生后再補安全不如在 Agent 上線第一天就把訪問控制層放進(jìn)去。希望這篇文章能給你一個可執(zhí)行的起點。