AI Agent 安全危機：15% 智能體技能檔內含硬編碼憑證，企業部署的隱患有多大？

2026 年上半年，AI Agent 的部署量呈爆炸式增長。從客服自動化到程式碼生成，從數據分析到內部流程審批，智能體正在滲透企業的每一個環節。但隨之而來的安全問題，卻遠沒有跟上發展的腳步。

五月份，Capsule Security 發布了一份令人不安的調查報告：在流行的 AI Agent 技能註冊表中，有 15% 的技能文件（skills.md）直接硬編碼了憑證，而且其中相當一部分擁有數據庫寫入權限。這不是理論上的風險——這是正在發生的安全漏洞。

硬編碼憑證：一個不該存在的問題

對於有經驗的開發者來說，「不要把密碼寫死在程式碼裡」是最基本的常識。環境變數、密鑰管理器、雲端 HSM——這些方案已經成熟多年。但在 AI Agent 的世界裡，這個常識正在被大規模地忽略。

為什麼會這樣？

首先，Agent 技能文件的設計初衷是讓 AI 模型「理解」某個工具的使用方式。這些文件通常包含工具的描述、參數說明、使用示例。問題出在「使用示例」這一環節——為了讓 AI 能夠「運行」示例，很多開發者直接在示例中貼上了真實的 API Key、數據庫連接字串，甚至是 JWT Token。

其次，AI Agent 框架的設計傾向於「最小摩擦」部署。CrewAI、AutoGen、LangGraph 這些框架都鼓勵用戶快速搭建可運行的智能體。在這個過程中，安全配置往往被視為「以後再說」的事情。

更令人擔憂的是，很多技能文件不僅包含憑證，還包含數據庫寫入權限。這意味著一個被泄露的技能文件不僅能被用來讀取數據，還能直接修改或刪除數據。

AI 智能體的攻擊面在擴大

Capsule Security 的調查只是冰山一角。要理解 AI Agent 安全的全貌，我們需要從幾個維度來看待這個問題。

技能註冊表的信任模型崩塌

GitHub 和各種 Agent Registry 上充斥著數千個 skills.md 文件。這些文件的安全審查機制幾乎為零——任何人都可以上傳，任何人都可以下載。當企業的智能體加載了包含惡意憑證的技能文件時，實際上等於把自家系統的訪問權限交給了未知來源。

一位安全研究員在分析 4000 個 skills.md 儲存庫後發現，不僅有憑證泄露的問題，還存在技能文件被篡改的風險。攻擊者可以提交一個看似正常的技能文件，但其中包含指向惡意 API 端點的 URL，從而攔截智能體發送的敏感數據。

OWASP Agentic AI Top 10 的現實意義

2026 年，OWASP 正式發布了 Agentic AI Top 10 安全風險清單。這份清單不是學術論文，而是基於實際事件總結出來的實戰指南。以下是與當前危機最相關的幾項：

1. 提示詞注入（Prompt Injection） 智能體的核心是大語言模型，而 LLM 的輸入是自然語言。攻擊者可以在數據源中嵌入惡意指令，誘導智能體執行非預期操作。這和傳統的 SQL 注入類似，但防禦難度更大——因為你無法像過濾 SQL 那樣簡單地過濾自然語言。

2. 過度權限（Excessive Agency） 很多企業在部署 AI Agent 時，給智能體授予的權限遠超其实际需要。一個只需要讀取日誌文件的智能體，被授予了整個文件系統的讀寫權限。當這個智能體被提示詞注入攻擊操控時，攻擊者就能獲得完整的系統訪問權。

3. 不安全的工具執行（Unsafe Tool Execution） 智能體調用的工具（MCP Server、API 端點、命令行工具）往往缺少足夠的沙盒隔離。一個被操控的智能體可以在宿主機上執行任意命令，而宿主機可能連接了企業的生產環境。

4. 訓練數據與上下文泄露 智能體在執行任務過程中會累積大量上下文信息，其中可能包含用戶的個人數據、企業機密，或者其他敏感信息。如果這些上下文沒有被正確清理或加密，就會成為新的洩露渠道。

框架安全性的現狀

目前主流的 AI Agent 框架在安全方面的表現各不相同：

LangGraph 在安全方面投入最多。它支持持久化執行（durable execution）和檢查點機制（checkpointing），這意味著智能體的每一步操作都可以被審計和回滾。已有 400 多家企業在生產環境中使用 LangGraph，這也推動了其在安全合規方面的持續改進。

Claude Agent SDK 提供了 18 個生命周期鉤子（lifecycle hooks），允許開發者在智能體執行的各個階段插入安全檢查。它還原生支持 MCP（Model Context Protocol），這為工具調用的安全控制提供了標準化的接口。不過，Claude Agent SDK 僅限 Anthropic 生態，這是一個明顯的供應商鎖定。

OpenAI Agents SDK 支持超過 100 種模型，並內置了追蹤（tracing）功能。它的類型化交接（typed handoffs）機制允許在多個智能體之間傳遞元數據，這對於審計鏈的建立很有幫助。但在權限細粒度控制方面，它仍然落後於 LangGraph。

CrewAI 的優勢在於快速原型開發。一個團隊可以在 35 行代碼內搭建一個可運行的智能體團隊。但這種便利性是以安全性為代價的——CrewAI 默認的安全配置相當寬鬆，需要開發者手動加固。

Google ADK 和 Microsoft Agent Framework 在企業合規性方面表現突出，特別是微軟的方案覆蓋了 OWASP Agentic Top 10 的全部條目，並且提供雙語言支持（.NET + Python）。但這兩者的社區生態相對較小，可用的第三方工具和技能文件也較少。

企業部署的務實建議

如果你正在考慮或已經在生產環境中部署 AI Agent，以下是我們認為最關鍵的幾件事：

第一，實施最小權限原則。 智能體只需要完成任務所需的最低權限。不要因為「方便」而授予過度的訪問權。如果一個智能體只需要讀取數據，就給它只讀權限。如果它只需要訪問特定的數據庫表，就不要給整個數據庫的權限。

第二，建立技能文件的審查流程。 在將任何第三方技能文件集成到你的智能體之前，必須進行安全審查。檢查內容包括：是否有硬編碼憑證？是否有指向外部服務器的可疑 URL？是否有過度寬泛的權限聲明？

第三，使用沙盒隔離。 智能體的執行環境應該與生產環境隔離。使用容器、虛擬機或操作系統級別的沙盒來限制智能體的影響範圍。即使智能體被攻陷，攻擊者也無法橫向移動到關鍵系統。

第四，啟用審計日誌。 記錄智能體的每一個決策和行動。這不僅是為了事後追溯，更是為了建立行為基線——當智能體的行為模式出現異常時，能夠及時發出警報。

第五，定期轮换憑證。 即使你使用了密鑰管理器來管理憑證，也需要定期轮换。Capsule Security 的調查顯示，很多泄露的憑證已經存在了數月甚至數年之久。如果這些憑證定期轮换，即使被泄露，其有效期也會大大縮短。

未來的走向

AI Agent 安全不是一個可以「一次性解決」的問題。隨著智能體的能力越來越強，它們獲得的權限也會越來越大，安全風險的後果也會越來越嚴重。

我們預計在接下來的 6 到 12 個月內，會看到以下趨勢：

• 更多的 AI Agent 安全框架和工具出現，特別是針對技能文件自動掃描和憑證檢測的工具
• 主要雲服務商會推出專門為 AI Agent 設計的身份和訪問管理方案
• 行業標準組織會推動 AI Agent 安全合規的強制性要求，類似於 GDPR 對數據隱私的影響
• 保險公司會開始提供針對 AI Agent 安全事故的專門保險產品

這些都是好的方向。但在此之前，企業不能等待標準和工具成熟才開始行動。現在就應該把 AI Agent 安全納入現有的安全體系中——因為攻擊者不會等到標準出台才開始利用這些漏洞。

安全不是一個功能，而是一種持續的狀態。在 AI Agent 的世界裡，這個道理比以往任何時候都更加重要。