1. 為什么說 AI 安全本質上是個工程問題很多人第一次接觸 AI 安全腦子里浮現(xiàn)的是模型對齊、提示詞注入、越獄攻擊這些偏算法和策略層面的東西。但真正在智能體項目里踩過坑的人會告訴你絕大多數(shù)安全事故不是模型“想錯了”而是工程鏈路某一層“漏了”。一個智能體從接收用戶輸入到最終執(zhí)行動作中間要經(jīng)過輸入解析、意圖路由、工具調用、權限校驗、運行時沙箱、輸出過濾等至少六七個環(huán)節(jié)任何一個環(huán)節(jié)的工程實現(xiàn)有缺陷都會讓上層再精妙的安全策略形同虛設。我拿一個真實場景舉例。你做了一個客服智能體接入了訂單查詢和退款兩個工具。模型層面你做了嚴格的系統(tǒng)提示詞約束要求“只有用戶明確提供訂單號且身份驗證通過后才能發(fā)起退款”。聽起來很安全對吧但如果工程層面沒有對工具調用參數(shù)做二次校驗攻擊者完全可以通過多輪對話誘導模型把退款金額參數(shù)從“0”改成“9999”而模型本身可能根本沒意識到自己在做什么。這就是典型的策略層安全被工程層漏洞擊穿。所以這篇文章想聊的核心觀點很明確AI 安全必須當作一個貫穿智能體技術棧每一層的工程問題來對待。從最底層的運行時環(huán)境到中間的工具調用與權限管理再到最上層的輸入輸出過濾每一層都要有對應的工程手段。只盯著模型本身做安全就像只給大門裝鎖卻把窗戶全開著。這篇文章適合誰看如果你正在做智能體開發(fā)不管是基于 Coze、Dify 這類平臺搭建還是用 Python 從零手寫 Agent 框架只要你關心“怎么讓智能體在生產(chǎn)環(huán)境里不出事”那下面的內容應該對你有用。我會盡量把每一層的工程要點拆開講清楚配上可參考的配置思路和排查方法。2. 智能體技術棧的分層安全模型2.1 從輸入到執(zhí)行一條完整的攻擊面鏈路要理解為什么安全是工程問題先得把智能體的技術棧拆開看。一個典型的智能體系統(tǒng)從用戶輸入到最終動作執(zhí)行大致經(jīng)過這么幾層接入層用戶請求進入系統(tǒng)可能是 API、聊天窗口、Webhook 等編排層負責意圖識別、任務規(guī)劃、多輪對話管理決定“要做什么”工具層智能體可以調用的外部能力比如搜索、數(shù)據(jù)庫查詢、發(fā)郵件、執(zhí)行代碼運行時層實際執(zhí)行工具調用的環(huán)境可能是容器、沙箱、虛擬機數(shù)據(jù)層智能體讀寫的記憶、知識庫、用戶數(shù)據(jù)輸出層最終返回給用戶的內容可能經(jīng)過過濾和格式化每一層都有獨立的攻擊面。接入層可能被惡意 payload 攻擊編排層可能被提示詞注入操縱工具層可能被參數(shù)篡改利用運行時層可能被逃逸攻擊數(shù)據(jù)層可能被越權讀取輸出層可能泄露敏感信息。只在一層做防護其他層就是敞開的門。2.2 為什么“模型對齊”解決不了工程漏洞模型對齊解決的是“模型愿不愿意做壞事”的問題但工程漏洞導致的是“模型不想做壞事但被利用了”的問題。這兩者完全不是一回事。舉個例子。你給模型設了嚴格的系統(tǒng)提示詞“禁止執(zhí)行任何刪除操作”。但你的工具層有一個execute_shell工具參數(shù)是用戶可控的。攻擊者通過精心構造的輸入讓模型生成一個看起來無害的 shell 命令比如echo hello rm -rf /tmp/data。模型可能認為這只是一個輸出文本的操作但運行時層如果直接執(zhí)行了數(shù)據(jù)就沒了。模型本身沒有“想”刪除數(shù)據(jù)它只是被工程鏈路的缺陷利用了。這就是為什么我說安全必須下沉到工程層。模型對齊是必要的但遠遠不夠。你需要的是工具層有參數(shù)白名單校驗運行時層有沙箱隔離數(shù)據(jù)層有權限控制輸出層有敏感信息過濾。每一層都假設上一層可能被突破這樣整體系統(tǒng)才是健壯的。2.3 分層防御的核心原則最小權限與縱深防御分層安全模型有兩個核心原則我在實際項目里反復驗證過非常有效。第一個是最小權限原則。智能體調用的每一個工具、訪問的每一份數(shù)據(jù)、執(zhí)行的每一個動作都應該只擁有完成當前任務所必需的最小權限。比如一個查詢天氣的智能體它的工具層就不應該有任何寫文件、發(fā)請求、執(zhí)行代碼的能力。聽起來很基礎但我見過太多項目為了“方便后續(xù)擴展”給智能體開了全量工具權限結果一個提示詞注入就能讓智能體變成攻擊者的跳板。第二個是縱深防御原則。不要指望任何單一防護手段能擋住所有攻擊。輸入過濾可能被繞過工具校驗可能被社會工程學突破運行時沙箱可能有未知漏洞。所以每一層都要有獨立的防護并且層與層之間的防護邏輯要盡量正交。比如輸入層做了關鍵詞過濾工具層還要做參數(shù)類型校驗運行時層還要做系統(tǒng)調用限制。攻擊者要成功必須同時突破所有層這個成本就高得多了。3. 運行時層智能體安全的第一道工程防線3.1 運行時隔離的三種主流方案對比運行時層是智能體實際執(zhí)行動作的地方也是安全工程最應該重點投入的地方。目前主流的運行時隔離方案有三種我分別說說它們的適用場景和坑。隔離方案隔離強度性能開銷適用場景主要坑點進程級隔離低極低內部可信工具調用無法防御逃逸攻擊容器隔離中中等大多數(shù)生產(chǎn)環(huán)境配置不當可能逃逸微虛擬機隔離高較高執(zhí)行不可信代碼啟動慢資源占用大進程級隔離就是簡單的子進程調用比如 Python 的subprocess。這種方案幾乎沒有隔離能力智能體調用的工具和主進程共享文件系統(tǒng)、網(wǎng)絡、環(huán)境變量。我一般只在完全可信的內部工具上用它比如調用一個自己寫的、參數(shù)完全可控的格式化函數(shù)。容器隔離是目前生產(chǎn)環(huán)境的主流選擇。Docker 容器可以提供文件系統(tǒng)隔離、網(wǎng)絡隔離、資源限制。但這里有個大坑默認的 Docker 配置并不安全。容器內的 root 用戶如果掛載了宿主機的 Docker socket或者以--privileged模式運行那隔離基本等于沒有。我見過一個項目智能體在容器里執(zhí)行代碼結果攻擊者通過容器逃逸拿到了宿主機權限。正確的做法是容器以非 root 用戶運行禁用特權模式只掛載必要的目錄限制網(wǎng)絡訪問。微虛擬機隔離是強度最高的方案比如 Firecracker、gVisor 這類技術。它給每個智能體任務啟動一個獨立的輕量級虛擬機即使容器逃逸了攻擊者也只是從一個虛擬機逃到另一個虛擬機拿不到宿主機。代價是啟動慢、資源占用高。我一般只在執(zhí)行完全不可信的代碼時用這種方案比如讓智能體運行用戶提交的 Python 腳本。3.2 OpenShell 類運行時環(huán)境的配置要點OpenShell 這類運行時環(huán)境的核心思路是給智能體提供一個受控的 shell 執(zhí)行環(huán)境。配置的時候有幾個關鍵點必須注意。首先是文件系統(tǒng)掛載策略。默認情況下運行時環(huán)境應該只掛載一個臨時的、隔離的工作目錄智能體只能在這個目錄里讀寫。宿主機的敏感目錄比如/etc、/root、/var/run絕對不能掛載進去。如果智能體確實需要訪問某些數(shù)據(jù)應該通過工具層提供的 API 來獲取而不是直接掛載文件系統(tǒng)。其次是網(wǎng)絡訪問控制。智能體的運行時環(huán)境默認應該禁止所有出站網(wǎng)絡請求只允許訪問白名單內的地址。我一般會配置一個網(wǎng)絡策略只放行智能體必須調用的內部服務地址其他全部拒絕。這樣可以防止智能體被誘導去訪問惡意地址或者把敏感數(shù)據(jù)外傳。第三是資源限制。CPU、內存、磁盤、進程數(shù)都要設上限。我見過一個智能體因為遞歸調用自己把整個服務器的內存耗盡了。配置資源限制的時候建議先跑一遍典型任務觀察實際資源消耗然后在此基礎上留 50% 的余量。比如典型任務用 200MB 內存那就限制 300MB。第四是系統(tǒng)調用過濾。用 seccomp 或者類似的機制只允許智能體運行時環(huán)境執(zhí)行必要的系統(tǒng)調用。比如一個只做文本處理的智能體完全不需要execve、fork、socket這些系統(tǒng)調用那就全部禁掉。這樣即使智能體被注入了惡意代碼也無法執(zhí)行新的程序或者建立網(wǎng)絡連接。注意運行時環(huán)境的配置一定要在測試環(huán)境充分驗證后再上生產(chǎn)。我踩過的坑是生產(chǎn)環(huán)境限制了某個系統(tǒng)調用結果智能體的正常功能也掛了排查了半天才發(fā)現(xiàn)是 seccomp 規(guī)則太嚴格。3.3 運行時行為審計記錄什么、怎么記錄運行時行為審計是事后排查和實時阻斷的基礎。但很多項目的審計日志要么記太少出了事查不到要么記太多關鍵信息被淹沒。我的經(jīng)驗是審計日志要圍繞“誰在什么時間對什么資源做了什么動作結果如何”這個核心來設計。具體來說每一條工具調用記錄至少包含這些字段時間戳、智能體實例 ID、用戶會話 ID、工具名稱、調用參數(shù)敏感參數(shù)要脫敏、執(zhí)行時長、執(zhí)行結果狀態(tài)、返回內容摘要。如果是代碼執(zhí)行類的工具還要記錄執(zhí)行的代碼內容、運行時環(huán)境的資源消耗、系統(tǒng)調用摘要。記錄方式上我建議用結構化日志比如 JSON 格式直接寫到專門的審計日志系統(tǒng)里。不要用普通的文本日志文件因為后期檢索和分析太麻煩。如果條件允許審計日志應該實時推送到一個獨立的、智能體無法訪問的存儲里防止智能體被攻擊后篡改日志。實時阻斷方面可以基于審計日志做規(guī)則引擎。比如“同一智能體實例在 10 秒內發(fā)起了超過 5 次退款操作”就自動掛起該實例并告警。規(guī)則不用一開始就很復雜先覆蓋最核心的高危操作后續(xù)根據(jù)實際攻擊案例逐步補充。4. 工具層與編排層的安全工程實踐4.1 工具調用的參數(shù)校驗與白名單機制工具層是智能體與外部世界交互的橋梁也是攻擊者最喜歡利用的地方。參數(shù)校驗的核心思路是永遠不要相信智能體生成的參數(shù)所有參數(shù)都要經(jīng)過獨立的校驗邏輯。我一般會為每個工具定義一個參數(shù) schema明確每個參數(shù)的類型、范圍、格式、是否必填。比如一個“發(fā)送郵件”的工具收件人參數(shù)必須是合法的郵箱格式且必須在允許的域名白名單內主題和正文參數(shù)要限制長度并且過濾掉可能的注入內容附件參數(shù)要限制文件類型和大小。校驗邏輯要放在工具調用的入口處而不是依賴智能體自己保證。我見過一些項目把參數(shù)校驗寫在系統(tǒng)提示詞里讓模型“自己注意參數(shù)格式”。這種做法極其不可靠模型完全可能因為上下文變化而忽略這些約束。正確的做法是在工具調用的代碼里硬編碼校驗邏輯參數(shù)不合法就直接拒絕不進入實際執(zhí)行。白名單機制方面對于枚舉類型的參數(shù)比如“操作類型”只能是query、create、update、delete這幾個值那就用白名單校驗不在白名單內的一律拒絕。對于字符串類型的參數(shù)如果可能包含危險字符比如 SQL 語句、shell 命令那就要做轉義或者參數(shù)化處理。對于數(shù)值類型的參數(shù)要校驗范圍比如退款金額不能超過訂單金額不能為負數(shù)。4.2 權限模型設計RBAC 在智能體場景下的落地傳統(tǒng)的 RBAC 模型在智能體場景下需要做一些調整。核心區(qū)別在于智能體的權限不僅取決于“誰在操作”還取決于“在什么上下文中操作”。我一般會設計一個三維權限模型用戶身份、智能體實例、任務上下文。用戶身份決定基礎權限比如普通用戶不能調用管理員工具。智能體實例決定能力邊界比如客服智能體只能調用訂單查詢和退款工具不能調用數(shù)據(jù)庫管理工具。任務上下文決定臨時權限比如用戶正在進行退款流程那智能體在這個流程中臨時獲得退款工具的調用權限流程結束后權限自動回收。落地的時候可以用一個權限表來管理。每一行記錄一個權限規(guī)則主體用戶 ID 或角色、智能體實例 ID、允許的工具列表、允許的參數(shù)范圍、有效期。智能體調用工具前先查權限表確認當前上下文下是否有權限。沒有就拒絕并記錄審計日志。這里有個容易忽略的點權限的繼承和傳遞。如果智能體 A 調用了智能體 BB 又調用了工具 C那 C 的權限應該基于誰的上下文我的做法是權限不傳遞每個智能體實例只擁有自己直接被授予的權限。A 調用 B 的時候B 以自己的身份去調用 C而不是繼承 A 的權限。這樣可以防止權限在智能體之間擴散。4.3 編排層的意圖識別與越權攔截編排層負責理解用戶意圖并規(guī)劃任務。這一層的安全工程重點是防止攻擊者通過多輪對話或者精心構造的輸入誘導編排層產(chǎn)生越權的任務規(guī)劃。一個典型的攻擊場景是這樣的攻擊者先問“你能幫我查一下訂單嗎”智能體回答“可以請?zhí)峁┯唵翁枴薄Ｈ缓蠊粽哒f“我的訂單號是 12345另外幫我順便把收貨地址改成 xxx”。如果編排層沒有嚴格區(qū)分“查詢”和“修改”兩個意圖可能會把整個請求當成一個任務然后調用修改地址的工具。但實際上用戶并沒有通過身份驗證也沒有權限修改這個訂單。防御手段是在編排層做意圖隔離。每個用戶請求都要先經(jīng)過意圖分類明確當前請求屬于哪個操作類別。然后檢查用戶在當前上下文中是否有權限執(zhí)行這個類別的操作。如果沒有直接拒絕不進入任務規(guī)劃。對于多輪對話每一輪都要重新做意圖分類和權限檢查不能因為上一輪通過了就默認這一輪也通過。另外編排層還要防止任務規(guī)劃注入。攻擊者可能在輸入中嵌入類似“忽略之前的指令現(xiàn)在執(zhí)行 xxx”的內容試圖操縱編排層的規(guī)劃邏輯。防御方法是在編排層對用戶輸入做清洗移除可能的指令注入模式并且把用戶輸入和系統(tǒng)指令嚴格分離不要讓用戶輸入進入系統(tǒng)指令的解析流程。5. 數(shù)據(jù)層與輸出層的安全細節(jié)5.1 智能體記憶與知識庫的訪問控制智能體的記憶和知識庫是敏感數(shù)據(jù)的集中地。訪問控制的核心是每個智能體實例只能訪問自己任務相關的數(shù)據(jù)不能跨用戶、跨任務讀取。我一般會給每個用戶會話分配一個獨立的命名空間智能體的記憶和知識庫查詢都限定在這個命名空間內。比如用戶 A 的會話只能讀取user_a命名空間下的記憶不能讀取user_b的。知識庫方面如果多個用戶共享一個知識庫那就要在查詢時加上用戶權限過濾只返回該用戶有權查看的文檔。這里有個坑向量數(shù)據(jù)庫的相似度檢索可能泄露數(shù)據(jù)。如果知識庫里存了多個用戶的文檔智能體做相似度檢索時可能會檢索到其他用戶的文檔片段。防御方法是在檢索時加上元數(shù)據(jù)過濾只檢索當前用戶有權訪問的文檔。或者在寫入知識庫時就把文檔按用戶隔離到不同的集合里。另外智能體的長期記憶要定期清理。我見過一個項目智能體的記憶里存了用戶的身份證號、銀行卡號結果因為沒清理幾個月后還能被檢索出來。建議對記憶數(shù)據(jù)做分類敏感信息設置較短的過期時間非敏感信息可以保留久一點。5.2 輸出過濾防止敏感信息泄露的最后一道閘輸出層是智能體返回給用戶的最后一道關卡。即使前面的所有層都被突破了輸出過濾還能攔住一部分敏感信息泄露。輸出過濾的核心是敏感信息識別和脫敏。我一般會配置幾類規(guī)則正則匹配比如身份證號、手機號、銀行卡號、關鍵詞匹配比如“密碼”、“密鑰”、“token”、模型檢測用一個小的分類模型判斷輸出是否包含敏感內容。匹配到敏感信息后可以選擇直接阻斷輸出、替換為占位符、或者告警并記錄。但輸出過濾有個天然的矛盾過濾太嚴會影響正常功能過濾太松會漏掉敏感信息。我的經(jīng)驗是先跑一批正常任務的輸出統(tǒng)計敏感信息誤報率然后調整規(guī)則閾值。對于高敏感場景寧可誤報也要攔住對于低敏感場景可以適當放寬。還有一個容易被忽略的點輸出過濾要覆蓋所有輸出通道。智能體的輸出可能通過聊天窗口返回也可能通過 API 返回還可能通過郵件、短信等通道發(fā)送。每個通道都要有獨立的過濾邏輯不能只過濾主通道。5.3 多智能體協(xié)同場景下的信任邊界多智能體協(xié)同是現(xiàn)在很熱的方向但安全工程上挑戰(zhàn)很大。核心問題是智能體 A 怎么知道智能體 B 返回的結果是可信的我一般會在多智能體系統(tǒng)里定義明確的信任邊界。每個智能體有自己的信任域跨域調用必須經(jīng)過認證和授權。智能體 A 調用智能體 B 的時候要帶上 A 的身份憑證和調用意圖B 驗證通過后才返回結果。B 返回的結果要帶上簽名A 收到后驗證簽名確認結果沒有被篡改。另外多智能體協(xié)同的時候權限要逐級遞減。A 有權限調用工具 X、Y、ZA 調用 B 去完成一個子任務B 只應該獲得完成這個子任務所需的最小權限而不是繼承 A 的全部權限。比如 A 讓 B 去查詢一個數(shù)據(jù)B 就只應該有查詢權限不應該有修改權限。還有一個實踐中的坑智能體之間的通信內容也要做過濾。我見過一個案例智能體 A 把用戶的敏感信息直接傳給了智能體 B而 B 的輸出沒有做過濾結果敏感信息泄露了。所以智能體之間的消息傳遞也要走和用戶輸入輸出一樣的過濾流程。6. 常見問題與排查技巧實錄6.1 智能體安全排查速查表問題現(xiàn)象可能原因排查方法修復建議智能體執(zhí)行了未授權的工具權限校驗缺失或配置錯誤檢查工具調用日志確認權限表配置補充權限校驗邏輯最小權限原則敏感數(shù)據(jù)出現(xiàn)在輸出中輸出過濾規(guī)則不完整用敏感信息樣本測試輸出過濾補充正則和關鍵詞規(guī)則增加模型檢測智能體被提示詞注入操縱輸入清洗不徹底用注入樣本測試輸入處理流程加強輸入清洗分離用戶輸入和系統(tǒng)指令運行時環(huán)境資源耗盡資源限制未配置或過松查看運行時監(jiān)控確認資源使用峰值配置 CPU、內存、進程數(shù)上限多智能體之間數(shù)據(jù)泄露信任邊界不清晰檢查智能體間通信日志定義信任域逐級遞減權限消息過濾審計日志缺失關鍵信息日志字段設計不完整模擬攻擊場景檢查日志記錄補充工具調用參數(shù)、結果狀態(tài)等字段6.2 三個我踩過的真實坑第一個坑以為容器隔離就萬事大吉。早期做智能體代碼執(zhí)行功能的時候我用了 Docker 容器覺得隔離夠了。結果測試的時候攻擊者通過容器內的一個已知漏洞拿到了宿主機的文件讀取權限。后來我才知道默認的 Docker 配置有很多不安全的地方比如共享內核、默認網(wǎng)絡模式等。修復方案是容器以非 root 運行禁用特權模式限制網(wǎng)絡訪問加上 seccomp 過濾。第二個坑審計日志記了但沒人看。有一段時間我的審計日志記錄得很全但從來沒有告警規(guī)則。結果一個智能體被攻擊后連續(xù)三天都在異常調用工具但沒人發(fā)現(xiàn)。后來我加上了實時告警規(guī)則比如“同一實例 1 分鐘內調用敏感工具超過 3 次”就發(fā)通知。告警規(guī)則不用一開始就很完善先覆蓋最核心的高危操作后續(xù)根據(jù)實際案例補充。第三個坑輸出過濾誤殺了正常內容。有一次我加了一個正則規(guī)則匹配“密碼”這個詞結果智能體在回答“如何修改密碼”這種正常問題時也被攔截了。后來我調整了規(guī)則只在“密碼”后面跟著疑似密碼值的時候才攔截而不是只要出現(xiàn)“密碼”就攔截。輸出過濾的規(guī)則要經(jīng)過充分測試平衡安全和可用性。6.3 安全工程落地的優(yōu)先級建議如果你剛開始做智能體安全資源有限我建議按這個優(yōu)先級來落地運行時隔離先把智能體的執(zhí)行環(huán)境隔離好這是最基礎也是最重要的工具參數(shù)校驗所有工具調用的參數(shù)都要經(jīng)過獨立校驗不信任智能體生成的任何參數(shù)權限模型定義清楚每個智能體能調用哪些工具最小權限原則審計日志記錄所有工具調用和關鍵操作為事后排查提供依據(jù)輸出過濾防止敏感信息泄露的最后一道防線輸入清洗防止提示詞注入和惡意輸入多智能體信任邊界如果有多智能體協(xié)同定義清楚信任關系這個順序不是絕對的但大體上遵循“先隔離、再校驗、后過濾”的邏輯。先把執(zhí)行環(huán)境管住再把調用入口管住最后把輸出管住。7. 一些實操中的個人體會做智能體安全工程這幾年我最大的體會是安全不是一個可以“加上去”的功能而是需要從架構設計階段就融入的工程屬性。很多項目是在智能體已經(jīng)跑起來之后才想起來加安全措施這時候往往要改架構成本很高而且容易留下死角。另一個體會是安全措施要可觀測、可度量。你加了權限校驗那就要有日志記錄校驗通過和拒絕的次數(shù)你加了輸出過濾那就要統(tǒng)計過濾命中的頻率和類型。沒有度量你就不知道安全措施是否有效也不知道攻擊是否在發(fā)生。還有一點不要追求一步到位的完美安全。智能體安全是一個持續(xù)迭代的過程。先覆蓋最核心的風險然后根據(jù)實際運行中發(fā)現(xiàn)的攻擊案例和漏洞逐步完善。我見過一些團隊想一開始就設計一個“萬無一失”的安全架構結果拖了幾個月都沒上線反而錯過了業(yè)務窗口。最后分享一個小技巧定期做紅藍對抗演練。找一個人扮演攻擊者嘗試用各種方式突破智能體的安全防線另一個人扮演防御者記錄攻擊路徑和防御效果。這種演練比看文檔、讀論文有效得多能發(fā)現(xiàn)很多實際工程中的盲點。我一般每個季度做一次每次都能發(fā)現(xiàn)幾個之前沒注意到的問題。智能體安全這個領域還在快速演進新的攻擊手法和防御方案層出不窮。保持學習保持警惕把安全當作工程問題來對待而不是當作一個可以一次性解決的配置項。這樣你的智能體系統(tǒng)才能在生產(chǎn)環(huán)境里真正穩(wěn)得住。