行時(shí)安全管控框架解析)
1. 項(xiàng)目緣起與核心定位OpenShell 這個(gè)標(biāo)題第一次出現(xiàn)在我視野里的時(shí)候我下意識(shí)以為是某個(gè)終端工具的別名或者是某款開(kāi)源 shell 的 fork 版本。真正花時(shí)間研究之后才發(fā)現(xiàn)它指向的是一個(gè)更底層、也更有意思的方向——一個(gè)面向 AI 智能體Agent的運(yùn)行時(shí)安全管控框架。簡(jiǎn)單說(shuō)它解決的是這樣一個(gè)問(wèn)題當(dāng)你把一個(gè)大模型驅(qū)動(dòng)的智能體放進(jìn)真實(shí)環(huán)境里讓它去執(zhí)行命令、讀寫(xiě)文件、調(diào)用外部接口的時(shí)候你怎么保證它不會(huì)把系統(tǒng)搞崩、不會(huì)越權(quán)訪問(wèn)、不會(huì)在你不注意的時(shí)候做出危險(xiǎn)操作。這個(gè)問(wèn)題的緊迫性只要真正跑過(guò) Agent 項(xiàng)目的人都有體會(huì)。早期大家做 Demo 的時(shí)候Agent 就是在一個(gè)沙箱里跑幾條命令出錯(cuò)了重啟就行。但一旦進(jìn)入生產(chǎn)環(huán)境Agent 要操作的是真實(shí)的文件系統(tǒng)、真實(shí)的數(shù)據(jù)庫(kù)、真實(shí)的云資源一次誤刪或者一次越權(quán)調(diào)用代價(jià)可能是不可逆的。OpenShell 要做的就是在 Agent 和真實(shí)系統(tǒng)之間插一層可控的、可審計(jì)的、可策略化的執(zhí)行外殼。它適合誰(shuí)來(lái)參考我梳理了一下大概三類人最需要第一類是正在做 Agent 應(yīng)用落地的工程師尤其是那些需要讓 Agent 執(zhí)行 shell 命令、操作文件系統(tǒng)的場(chǎng)景第二類是做 AI 基礎(chǔ)設(shè)施的平臺(tái)團(tuán)隊(duì)需要給上層業(yè)務(wù)提供統(tǒng)一的 Agent 執(zhí)行環(huán)境第三類是對(duì) AI 安全、權(quán)限隔離感興趣的研究者想看看業(yè)界是怎么處理讓 AI 干活但又不讓它闖禍這個(gè)矛盾的。我個(gè)人的判斷是OpenShell 這類東西的價(jià)值不在于它本身有多復(fù)雜而在于它把一套原本散落在各個(gè)項(xiàng)目里的安全實(shí)踐收斂成了一個(gè)可以復(fù)用的運(yùn)行時(shí)層。這個(gè)思路本身就值得拆開(kāi)來(lái)講。2. 為什么 Agent 需要一個(gè)執(zhí)行外殼2.1 裸跑 Agent 的三種典型翻車方式我先說(shuō)說(shuō)自己踩過(guò)的坑這樣你更能理解 OpenShell 存在的意義。第一種翻車是路徑逃逸。Agent 拿到一個(gè)任務(wù)說(shuō)清理一下臨時(shí)文件它理解成rm -rf /tmp/*但某次拼接路徑的時(shí)候變量為空實(shí)際執(zhí)行的是rm -rf /*。這種事故在純腳本時(shí)代就有但 Agent 的問(wèn)題在于它的命令是動(dòng)態(tài)生成的你沒(méi)法像審查固定腳本那樣逐行 review。第二種翻車是權(quán)限溢出。Agent 為了完成一個(gè)任務(wù)可能需要讀某個(gè)配置文件但它順手把整個(gè)目錄都遍歷了一遍甚至把敏感的環(huán)境變量打印到了日志里。你給它的是一個(gè)寬泛的權(quán)限它用這個(gè)權(quán)限做了超出預(yù)期的事。第三種翻車是不可審計(jì)。Agent 執(zhí)行了一堆操作出了問(wèn)題你想回溯結(jié)果發(fā)現(xiàn)日志里只有任務(wù)成功四個(gè)字中間執(zhí)行了什么命令、訪問(wèn)了哪些資源、耗時(shí)多久全都沒(méi)有記錄。這在合規(guī)場(chǎng)景下是致命的。OpenShell 的設(shè)計(jì)思路本質(zhì)上就是針對(duì)這三類問(wèn)題各給一套機(jī)制路徑和資源的邊界約束、權(quán)限的最小化授予、以及全鏈路的執(zhí)行審計(jì)。2.2 執(zhí)行外殼與沙箱的區(qū)別這里要澄清一個(gè)容易混淆的概念。很多人一聽(tīng)安全執(zhí)行就想到沙箱Sandbox覺(jué)得把 Agent 扔進(jìn)容器里就完事了。但沙箱和執(zhí)行外殼是兩回事。沙箱解決的是隔離問(wèn)題——讓 Agent 在一個(gè)受限的環(huán)境里跑跑壞了不影響宿主。但沙箱不解決策略問(wèn)題——Agent 在沙箱里依然可以執(zhí)行任意命令只是影響范圍被限制了。而 OpenShell 這類執(zhí)行外殼解決的是管控問(wèn)題——它不只是隔離還要在每一次執(zhí)行前做策略判斷執(zhí)行中做資源監(jiān)控執(zhí)行后做審計(jì)記錄。打個(gè)比方沙箱像是給小孩一個(gè)圍欄讓他在圍欄里玩執(zhí)行外殼像是給小孩配了一個(gè)保姆保姆會(huì)判斷這個(gè)動(dòng)作能不能做這個(gè)玩具能不能碰做完要記下來(lái)。兩者可以疊加使用但職責(zé)不同。我實(shí)測(cè)下來(lái)的體會(huì)是如果你的 Agent 只是做只讀操作沙箱可能就夠了但只要涉及寫(xiě)操作、外部調(diào)用、資源消耗執(zhí)行外殼這一層就省不掉。2.3 核心設(shè)計(jì)原則最小權(quán)限加顯式授權(quán)OpenShell 背后有一條很清晰的設(shè)計(jì)原則我把它總結(jié)成八個(gè)字最小權(quán)限顯式授權(quán)。最小權(quán)限的意思是Agent 默認(rèn)什么都不能做每一樣能力都需要被顯式地授予。這跟傳統(tǒng)的給個(gè)管理員賬號(hào)隨便用是完全相反的思路。顯式授權(quán)的意思是授權(quán)不是一次性的而是每次執(zhí)行都要經(jīng)過(guò)策略判斷策略可以基于命令內(nèi)容、目標(biāo)路徑、時(shí)間窗口、調(diào)用頻率等多個(gè)維度。這條原則聽(tīng)起來(lái)簡(jiǎn)單但落地的時(shí)候有很多細(xì)節(jié)。比如命令內(nèi)容怎么判斷是字符串匹配還是語(yǔ)法解析字符串匹配容易被繞過(guò)語(yǔ)法解析又太重。OpenShell 在這塊的取舍后面我會(huì)專門(mén)講。3. 核心架構(gòu)拆解與關(guān)鍵組件3.1 整體分層策略層、執(zhí)行層、審計(jì)層OpenShell 的架構(gòu)我理解下來(lái)是三層結(jié)構(gòu)從上到下依次是策略層、執(zhí)行層、審計(jì)層。策略層負(fù)責(zé)能不能做的判斷。它接收 Agent 發(fā)來(lái)的執(zhí)行請(qǐng)求請(qǐng)求里包含要執(zhí)行的命令、目標(biāo)資源、上下文信息然后根據(jù)預(yù)定義的策略規(guī)則返回允許、拒絕或者需要人工確認(rèn)。策略層的核心是一套規(guī)則引擎規(guī)則可以用聲明式的方式寫(xiě)比如允許讀取 /data 目錄下的文件但禁止寫(xiě)入。執(zhí)行層負(fù)責(zé)怎么做的落地。一旦策略層放行執(zhí)行層就在受控的環(huán)境里真正執(zhí)行命令同時(shí)監(jiān)控資源使用情況比如 CPU、內(nèi)存、執(zhí)行時(shí)長(zhǎng)、輸出大小。執(zhí)行層還要處理超時(shí)、中斷、異常這些情況。審計(jì)層負(fù)責(zé)做了什么的記錄。每一次執(zhí)行請(qǐng)求無(wú)論放行還是拒絕都要留下完整的記錄包括請(qǐng)求內(nèi)容、策略判斷結(jié)果、執(zhí)行結(jié)果、資源消耗。審計(jì)層的記錄要能支撐事后回溯和合規(guī)檢查。這三層的邊界要清晰不能混在一起。我見(jiàn)過(guò)一些項(xiàng)目把策略判斷寫(xiě)在執(zhí)行邏輯里結(jié)果就是策略改一次要?jiǎng)訄?zhí)行代碼維護(hù)成本極高。OpenShell 把三層分開(kāi)策略可以獨(dú)立迭代執(zhí)行層保持穩(wěn)定審計(jì)層獨(dú)立擴(kuò)展。3.2 策略引擎的規(guī)則表達(dá)策略引擎是 OpenShell 最核心也最需要仔細(xì)設(shè)計(jì)的部分。規(guī)則怎么表達(dá)直接決定了這套東西好不好用。我梳理了一下規(guī)則表達(dá)大概有三種粒度粒度表達(dá)方式優(yōu)點(diǎn)缺點(diǎn)命令級(jí)匹配命令字符串或正則簡(jiǎn)單直接容易被繞過(guò)維護(hù)成本高語(yǔ)法級(jí)解析命令的 AST按語(yǔ)義匹配準(zhǔn)確難繞過(guò)實(shí)現(xiàn)復(fù)雜需要覆蓋各種 shell 語(yǔ)法能力級(jí)抽象成讀、寫(xiě)、執(zhí)行、網(wǎng)絡(luò)等能力穩(wěn)定易理解粒度粗可能誤傷OpenShell 實(shí)際采用的是混合策略對(duì)常見(jiàn)命令用語(yǔ)法級(jí)解析對(duì)復(fù)雜場(chǎng)景降級(jí)到命令級(jí)匹配同時(shí)提供能力級(jí)的抽象接口給上層業(yè)務(wù)用。這個(gè)取舍我覺(jué)得是合理的因?yàn)榧冋Z(yǔ)法級(jí)解析的成本太高而純命令級(jí)匹配又太不安全。規(guī)則的具體寫(xiě)法通常是聲明式的配置類似這樣rules: - name: allow-read-data match: capability: read path: /data/** action: allow - name: deny-write-system match: capability: write path: /system/** action: deny - name: confirm-network match: capability: network action: confirm這種聲明式的好處是策略和代碼解耦安全團(tuán)隊(duì)可以獨(dú)立維護(hù)策略不用改執(zhí)行代碼。壞處是表達(dá)能力有限遇到復(fù)雜邏輯還是得寫(xiě)代碼。3.3 執(zhí)行隔離的技術(shù)選型執(zhí)行層怎么隔離是個(gè)技術(shù)選型問(wèn)題。常見(jiàn)的有幾種方案進(jìn)程級(jí)隔離、容器級(jí)隔離、虛擬機(jī)級(jí)隔離。進(jìn)程級(jí)隔離最輕用操作系統(tǒng)的用戶權(quán)限和命名空間做限制啟動(dòng)快開(kāi)銷小但隔離強(qiáng)度弱遇到內(nèi)核漏洞可能被突破。容器級(jí)隔離居中用容器技術(shù)做文件系統(tǒng)、網(wǎng)絡(luò)、進(jìn)程的隔離啟動(dòng)較快隔離強(qiáng)度夠用是目前主流的選擇。虛擬機(jī)級(jí)隔離最重隔離強(qiáng)度最高但啟動(dòng)慢開(kāi)銷大一般用在多租戶場(chǎng)景。OpenShell 默認(rèn)走的是容器級(jí)隔離同時(shí)保留了切換到進(jìn)程級(jí)和虛擬機(jī)級(jí)的接口。這個(gè)選擇我覺(jué)得是對(duì)的因?yàn)榇蟛糠?Agent 場(chǎng)景不需要虛擬機(jī)級(jí)別的隔離容器級(jí)已經(jīng)能覆蓋絕大多數(shù)風(fēng)險(xiǎn)而且啟動(dòng)速度能滿足交互式 Agent 的需求。注意容器級(jí)隔離不是萬(wàn)能的如果 Agent 需要訪問(wèn)宿主機(jī)的某些資源比如 GPU、特定設(shè)備隔離配置會(huì)變得復(fù)雜需要仔細(xì)設(shè)計(jì)掛載和權(quán)限。3.4 審計(jì)數(shù)據(jù)的結(jié)構(gòu)與存儲(chǔ)審計(jì)層的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)直接決定了事后能不能查得清楚。我見(jiàn)過(guò)一些項(xiàng)目審計(jì)日志就記個(gè)時(shí)間戳和命令出了問(wèn)題根本查不出上下文。OpenShell 的審計(jì)記錄我理解至少包含這幾個(gè)字段請(qǐng)求 ID、會(huì)話 ID、Agent 標(biāo)識(shí)、請(qǐng)求時(shí)間、命令內(nèi)容、目標(biāo)資源、策略判斷結(jié)果、執(zhí)行狀態(tài)、開(kāi)始時(shí)間、結(jié)束時(shí)間、資源消耗、輸出摘要、錯(cuò)誤信息。這些字段組合起來(lái)才能支撐誰(shuí)在什么時(shí)候讓哪個(gè) Agent 做了什么結(jié)果如何這樣的查詢。存儲(chǔ)方面審計(jì)數(shù)據(jù)的特點(diǎn)是寫(xiě)入頻繁、查詢較少、需要長(zhǎng)期保留。所以通常用追加寫(xiě)的日志存儲(chǔ)或者時(shí)序數(shù)據(jù)庫(kù)而不是關(guān)系型數(shù)據(jù)庫(kù)。如果數(shù)據(jù)量特別大還要考慮冷熱分離近期數(shù)據(jù)放快存儲(chǔ)歷史數(shù)據(jù)歸檔到對(duì)象存儲(chǔ)。4. 實(shí)操落地從零搭一個(gè)受控執(zhí)行環(huán)境4.1 環(huán)境準(zhǔn)備與依賴確認(rèn)假設(shè)你要在自己的項(xiàng)目里落地一套類似 OpenShell 的受控執(zhí)行環(huán)境我按實(shí)操順序講一遍。第一步是確認(rèn)基礎(chǔ)環(huán)境。你需要一臺(tái) Linux 機(jī)器內(nèi)核版本建議 5.10 以上因?yàn)橐玫揭恍┹^新的命名空間和 cgroup 特性。容器運(yùn)行時(shí)我推薦用 containerd 而不是 Docker因?yàn)?containerd 更輕API 更干凈適合做底層集成。如果團(tuán)隊(duì)已經(jīng)重度使用 Docker用 Docker 也行只是多一層封裝。第二步是確認(rèn)權(quán)限模型。執(zhí)行環(huán)境需要一個(gè)專用的系統(tǒng)用戶來(lái)跑 Agent 進(jìn)程這個(gè)用戶不能有 sudo 權(quán)限不能屬于 docker 組家目錄要獨(dú)立。我一般會(huì)建一個(gè)叫agent-runner的用戶專門(mén)用來(lái)跑執(zhí)行層。sudo useradd -r -s /bin/false -d /var/lib/agent-runner agent-runner sudo mkdir -p /var/lib/agent-runner sudo chown agent-runner:agent-runner /var/lib/agent-runner第三步是規(guī)劃目錄結(jié)構(gòu)。我習(xí)慣把策略、執(zhí)行、審計(jì)三塊的數(shù)據(jù)分開(kāi)存放/opt/openshell/ policies/ # 策略配置 runtime/ # 執(zhí)行層工作目錄 audit/ # 審計(jì)日志 workspace/ # Agent 可操作的沙箱目錄workspace 目錄是 Agent 唯一能自由讀寫(xiě)的地方其他目錄都要通過(guò)策略嚴(yán)格控制。4.2 策略配置的編寫(xiě)與調(diào)試策略配置是落地過(guò)程中最花時(shí)間的部分。我的經(jīng)驗(yàn)是不要一上來(lái)就寫(xiě)一堆規(guī)則而是先跑一遍典型任務(wù)把 Agent 實(shí)際會(huì)執(zhí)行的命令都收集起來(lái)再針對(duì)性地寫(xiě)規(guī)則。收集命令的方法很簡(jiǎn)單先開(kāi)一個(gè)只記錄不攔截的模式讓 Agent 正常跑把所有執(zhí)行請(qǐng)求都記下來(lái)。跑個(gè)幾十次典型任務(wù)你就能看到 Agent 實(shí)際的行為模式。然后基于這些數(shù)據(jù)來(lái)寫(xiě)策略比拍腦袋寫(xiě)要靠譜得多。寫(xiě)策略的時(shí)候我建議遵循幾個(gè)原則默認(rèn)拒絕沒(méi)明確允許的一律拒絕不要圖省事寫(xiě)通配的 allow。路徑收斂允許的路徑要盡量具體能用/data/reports/*.csv就不要用/data/**。能力分離讀和寫(xiě)分開(kāi)授權(quán)不要給一個(gè)讀寫(xiě)的籠統(tǒng)權(quán)限。頻率限制對(duì)高頻操作加限流防止 Agent 陷入循環(huán)瘋狂調(diào)用。調(diào)試策略的時(shí)候OpenShell 一般會(huì)提供一個(gè) dry-run 模式就是只判斷不執(zhí)行把判斷結(jié)果打出來(lái)。這個(gè)模式非常有用可以在不影響真實(shí)環(huán)境的情況下驗(yàn)證策略是否符合預(yù)期。4.3 執(zhí)行層的資源限制參數(shù)執(zhí)行層的資源限制是防止 Agent 把機(jī)器跑掛的關(guān)鍵。我梳理了幾個(gè)必須設(shè)置的參數(shù)參數(shù)建議值說(shuō)明CPU 限額2 核防止單個(gè) Agent 占滿 CPU內(nèi)存限額2GB防止內(nèi)存泄漏拖垮系統(tǒng)執(zhí)行超時(shí)300 秒防止命令卡死輸出大小10MB防止輸出爆炸進(jìn)程數(shù)64防止 fork 炸彈文件描述符1024防止句柄耗盡這些參數(shù)不是拍腦袋定的要根據(jù)實(shí)際任務(wù)調(diào)整。比如做數(shù)據(jù)處理的 Agent內(nèi)存限額可能要調(diào)到 8GB做交互式查詢的 Agent超時(shí)可以調(diào)到 60 秒。關(guān)鍵是每個(gè)參數(shù)都要有明確的理由不能隨便填。設(shè)置這些參數(shù)的時(shí)候要注意 cgroup 的層級(jí)關(guān)系。如果執(zhí)行層本身跑在容器里容器已經(jīng)有資源限制那執(zhí)行層內(nèi)部的限制要小于容器的限制否則內(nèi)層限制形同虛設(shè)。4.4 審計(jì)日志的采集與查詢審計(jì)日志的采集我建議用結(jié)構(gòu)化日志每條記錄是一個(gè) JSON 對(duì)象方便后續(xù)解析和查詢。不要用純文本日志因?yàn)榧兾谋窘馕銎饋?lái)太痛苦。{ request_id: req-20240115-001, session_id: sess-abc123, agent_id: agent-data-cleaner, timestamp: 2024-01-15T10:30:00Z, command: rm -f /workspace/temp/*.tmp, capability: write, target_path: /workspace/temp, policy_result: allow, exec_status: success, duration_ms: 45, resource_usage: { cpu_ms: 12, memory_kb: 2048 }, output_summary: removed 3 files }查詢方面如果日志量不大用 grep 加 jq 就夠了。如果日志量大建議上專門(mén)的日志系統(tǒng)比如 Loki 或者 Elasticsearch。查詢的時(shí)候最常用的幾個(gè)維度是按 Agent 查、按時(shí)間范圍查、按策略結(jié)果查、按目標(biāo)路徑查。提示審計(jì)日志本身也要保護(hù)不能讓 Agent 有權(quán)限修改或刪除。審計(jì)目錄的權(quán)限要設(shè)置成只有審計(jì)服務(wù)能寫(xiě)Agent 只能讀自己的記錄。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 策略誤判該放行的被攔了策略誤判是最常見(jiàn)的問(wèn)題尤其是剛上線的時(shí)候。典型表現(xiàn)是 Agent 執(zhí)行一個(gè)正常操作結(jié)果被策略攔了任務(wù)失敗。排查思路是這樣的先看審計(jì)日志里這條請(qǐng)求的策略判斷結(jié)果確認(rèn)是被哪條規(guī)則攔的。然后看這條規(guī)則的匹配條件對(duì)比請(qǐng)求的實(shí)際內(nèi)容找出不匹配的地方。常見(jiàn)的原因有幾個(gè)路徑匹配用了絕對(duì)路徑但請(qǐng)求里是相對(duì)路徑命令匹配用了完整命令但請(qǐng)求里帶了參數(shù)能力判斷把讀操作誤判成了寫(xiě)操作。解決方法是調(diào)整規(guī)則的匹配條件或者給規(guī)則加例外。但要注意加例外不能破壞最小權(quán)限原則例外的范圍要盡量小。我踩過(guò)的一個(gè)坑是策略里寫(xiě)了允許/workspace/**的寫(xiě)操作但 Agent 實(shí)際用的是/workspace這個(gè)路徑本身不帶尾部斜杠結(jié)果匹配不上。后來(lái)統(tǒng)一了路徑規(guī)范所有路徑都做標(biāo)準(zhǔn)化處理問(wèn)題就解決了。5.2 執(zhí)行超時(shí)命令卡住不返回執(zhí)行超時(shí)是另一個(gè)高頻問(wèn)題。Agent 執(zhí)行一個(gè)命令等了很久沒(méi)返回最后超時(shí)失敗。這種情況可能是命令本身耗時(shí)也可能是命令卡死了。排查的時(shí)候先看審計(jì)日志里的執(zhí)行時(shí)長(zhǎng)如果接近超時(shí)閾值說(shuō)明命令確實(shí)慢。然后看命令內(nèi)容判斷是正常慢還是異常慢。正常慢的話調(diào)大超時(shí)閾值異常慢的話要找出卡住的原因。常見(jiàn)的卡死原因有命令在等待輸入比如read或者cat不帶參數(shù)命令在等待網(wǎng)絡(luò)響應(yīng)但網(wǎng)絡(luò)不通命令陷入了死循環(huán)。針對(duì)這些情況執(zhí)行層要設(shè)置標(biāo)準(zhǔn)輸入為空網(wǎng)絡(luò)訪問(wèn)要加超時(shí)循環(huán)要有次數(shù)限制。我一般會(huì)在執(zhí)行層加一個(gè)心跳檢測(cè)命令執(zhí)行過(guò)程中定期檢查進(jìn)程狀態(tài)如果發(fā)現(xiàn)進(jìn)程已經(jīng)僵死就主動(dòng)殺掉不用等到超時(shí)。5.3 資源耗盡Agent 把機(jī)器跑掛了資源耗盡是最危險(xiǎn)的問(wèn)題輕則影響其他任務(wù)重則導(dǎo)致整臺(tái)機(jī)器不可用。典型表現(xiàn)是 CPU 打滿、內(nèi)存耗盡、磁盤(pán)寫(xiě)滿。排查的時(shí)候先看監(jiān)控?cái)?shù)據(jù)確認(rèn)是哪個(gè)資源先耗盡的。然后看審計(jì)日志找出耗盡前執(zhí)行的那批命令。常見(jiàn)的原因有Agent 陷入了重試循環(huán)瘋狂調(diào)用Agent 處理的數(shù)據(jù)量超出預(yù)期內(nèi)存爆了Agent 的輸出沒(méi)有限制把磁盤(pán)寫(xiě)滿了。解決方法是多管齊下執(zhí)行層設(shè)置硬性資源限制超出就殺策略層加頻率限制防止循環(huán)調(diào)用審計(jì)層加告警資源使用超過(guò)閾值就通知。我個(gè)人的經(jīng)驗(yàn)是資源限制的閾值要留足余量不能卡得太死。比如內(nèi)存限額設(shè) 2GB實(shí)際任務(wù)峰值用到 1.8GB那就很危險(xiǎn)稍微波動(dòng)一下就超了。一般建議閾值是峰值的 1.5 到 2 倍。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案策略誤攔規(guī)則匹配條件不準(zhǔn)確對(duì)比規(guī)則和請(qǐng)求內(nèi)容調(diào)整匹配條件或加例外執(zhí)行超時(shí)命令卡死或確實(shí)慢看執(zhí)行時(shí)長(zhǎng)和命令內(nèi)容調(diào)閾值或修命令資源耗盡循環(huán)調(diào)用或數(shù)據(jù)量超預(yù)期看監(jiān)控和審計(jì)日志加限制和告警審計(jì)缺失審計(jì)服務(wù)異?；驒?quán)限問(wèn)題檢查審計(jì)服務(wù)狀態(tài)修復(fù)服務(wù)或權(quán)限隔離失效容器配置錯(cuò)誤檢查容器配置修正掛載和權(quán)限5.5 幾個(gè)容易被忽略的細(xì)節(jié)最后分享幾個(gè)我在實(shí)操中發(fā)現(xiàn)的、文檔里一般不會(huì)寫(xiě)的細(xì)節(jié)。第一個(gè)是環(huán)境變量的處理。Agent 執(zhí)行命令的時(shí)候環(huán)境變量會(huì)繼承執(zhí)行層的環(huán)境。如果執(zhí)行層環(huán)境里有敏感信息比如 API keyAgent 就能讀到。所以執(zhí)行層要清理環(huán)境變量只保留必要的幾個(gè)。第二個(gè)是工作目錄的隔離。Agent 執(zhí)行命令的默認(rèn)工作目錄要設(shè)置成沙箱目錄不能是執(zhí)行層的工作目錄。否則 Agent 用相對(duì)路徑操作的時(shí)候可能操作到不該操作的地方。第三個(gè)是信號(hào)處理。Agent 執(zhí)行命令的時(shí)候如果執(zhí)行層收到終止信號(hào)要正確傳遞給子進(jìn)程不能直接殺掉執(zhí)行層導(dǎo)致子進(jìn)程變成孤兒進(jìn)程。這個(gè)細(xì)節(jié)在容器環(huán)境里尤其重要。第四個(gè)是日志脫敏。審計(jì)日志里可能包含敏感信息比如命令里的密碼、路徑里的用戶名。記錄之前要做脫敏處理把敏感部分替換掉。這個(gè)工作要在審計(jì)層做不能指望 Agent 自己處理。6. 擴(kuò)展方向與個(gè)人實(shí)踐體會(huì)OpenShell 這類執(zhí)行外殼往深了做還有很多空間。我梳理了幾個(gè)我覺(jué)得有價(jià)值的方向。一個(gè)是策略的自動(dòng)化生成?，F(xiàn)在策略主要靠人工寫(xiě)成本高且容易遺漏。如果能基于歷史執(zhí)行數(shù)據(jù)自動(dòng)學(xué)習(xí)出合理的策略基線再讓人工微調(diào)效率會(huì)高很多。這個(gè)方向已經(jīng)有了一些研究但落地還不成熟。另一個(gè)是多 Agent 的協(xié)同管控。單個(gè) Agent 的執(zhí)行管控相對(duì)簡(jiǎn)單但多個(gè) Agent 協(xié)同工作時(shí)權(quán)限的傳遞、資源的競(jìng)爭(zhēng)、依賴的管理都會(huì)變復(fù)雜。比如 Agent A 生成的文件Agent B 能不能讀這個(gè)需要一套跨 Agent 的權(quán)限模型。還有一個(gè)是執(zhí)行結(jié)果的可驗(yàn)證性?，F(xiàn)在審計(jì)記錄的是執(zhí)行了什么但沒(méi)法驗(yàn)證執(zhí)行結(jié)果是否正確。如果能結(jié)合一些校驗(yàn)機(jī)制比如文件哈希、數(shù)據(jù)庫(kù)快照就能做到執(zhí)行結(jié)果的可驗(yàn)證這在合規(guī)場(chǎng)景下很有價(jià)值。我自己在實(shí)際項(xiàng)目里落地這套東西的體會(huì)是技術(shù)實(shí)現(xiàn)只是一半另一半是流程和習(xí)慣。策略要有人維護(hù)審計(jì)要有人看告警要有人處理。如果只是搭了框架沒(méi)人管那跟沒(méi)搭區(qū)別不大。所以落地之前先想清楚誰(shuí)來(lái)負(fù)責(zé)這套東西的日常運(yùn)營(yíng)比急著寫(xiě)代碼更重要。最后再分享一個(gè)小技巧剛開(kāi)始落地的時(shí)候不要追求一步到位先把記錄做起來(lái)把 Agent 的行為都記下來(lái)跑一段時(shí)間有了數(shù)據(jù)再基于數(shù)據(jù)做策略。這樣比一上來(lái)就寫(xiě)一堆規(guī)則要穩(wěn)妥得多也不會(huì)因?yàn)檎`攔影響業(yè)務(wù)。等策略穩(wěn)定了再逐步收緊權(quán)限最終達(dá)到最小權(quán)限的狀態(tài)。這個(gè)過(guò)程可能要幾周甚至幾個(gè)月但每一步都走得踏實(shí)。 OpenShell：AI智能體運(yùn)行時(shí)安全管控框架解析
1. 項(xiàng)目緣起與核心定位OpenShell 這個(gè)標(biāo)題第一次出現(xiàn)在我視野里的時(shí)候我下意識(shí)以為是某個(gè)終端工具的別名或者是某款開(kāi)源 shell 的 fork 版本。真正花時(shí)間研究之后才發(fā)現(xiàn)它指向的是一個(gè)更底層、也更有意思的方向——一個(gè)面向 AI 智能體Agent的運(yùn)行時(shí)安全管控框架。簡(jiǎn)單說(shuō)它解決的是這樣一個(gè)問(wèn)題當(dāng)你把一個(gè)大模型驅(qū)動(dòng)的智能體放進(jìn)真實(shí)環(huán)境里讓它去執(zhí)行命令、讀寫(xiě)文件、調(diào)用外部接口的時(shí)候你怎么保證它不會(huì)把系統(tǒng)搞崩、不會(huì)越權(quán)訪問(wèn)、不會(huì)在你不注意的時(shí)候做出危險(xiǎn)操作。這個(gè)問(wèn)題的緊迫性只要真正跑過(guò) Agent 項(xiàng)目的人都有體會(huì)。早期大家做 Demo 的時(shí)候Agent 就是在一個(gè)沙箱里跑幾條命令出錯(cuò)了重啟就行。但一旦進(jìn)入生產(chǎn)環(huán)境Agent 要操作的是真實(shí)的文件系統(tǒng)、真實(shí)的數(shù)據(jù)庫(kù)、真實(shí)的云資源一次誤刪或者一次越權(quán)調(diào)用代價(jià)可能是不可逆的。OpenShell 要做的就是在 Agent 和真實(shí)系統(tǒng)之間插一層可控的、可審計(jì)的、可策略化的執(zhí)行外殼。它適合誰(shuí)來(lái)參考我梳理了一下大概三類人最需要第一類是正在做 Agent 應(yīng)用落地的工程師尤其是那些需要讓 Agent 執(zhí)行 shell 命令、操作文件系統(tǒng)的場(chǎng)景第二類是做 AI 基礎(chǔ)設(shè)施的平臺(tái)團(tuán)隊(duì)需要給上層業(yè)務(wù)提供統(tǒng)一的 Agent 執(zhí)行環(huán)境第三類是對(duì) AI 安全、權(quán)限隔離感興趣的研究者想看看業(yè)界是怎么處理讓 AI 干活但又不讓它闖禍這個(gè)矛盾的。我個(gè)人的判斷是OpenShell 這類東西的價(jià)值不在于它本身有多復(fù)雜而在于它把一套原本散落在各個(gè)項(xiàng)目里的安全實(shí)踐收斂成了一個(gè)可以復(fù)用的運(yùn)行時(shí)層。這個(gè)思路本身就值得拆開(kāi)來(lái)講。2. 為什么 Agent 需要一個(gè)執(zhí)行外殼2.1 裸跑 Agent 的三種典型翻車方式我先說(shuō)說(shuō)自己踩過(guò)的坑這樣你更能理解 OpenShell 存在的意義。第一種翻車是路徑逃逸。Agent 拿到一個(gè)任務(wù)說(shuō)清理一下臨時(shí)文件它理解成rm -rf /tmp/*但某次拼接路徑的時(shí)候變量為空實(shí)際執(zhí)行的是rm -rf /*。這種事故在純腳本時(shí)代就有但 Agent 的問(wèn)題在于它的命令是動(dòng)態(tài)生成的你沒(méi)法像審查固定腳本那樣逐行 review。第二種翻車是權(quán)限溢出。Agent 為了完成一個(gè)任務(wù)可能需要讀某個(gè)配置文件但它順手把整個(gè)目錄都遍歷了一遍甚至把敏感的環(huán)境變量打印到了日志里。你給它的是一個(gè)寬泛的權(quán)限它用這個(gè)權(quán)限做了超出預(yù)期的事。第三種翻車是不可審計(jì)。Agent 執(zhí)行了一堆操作出了問(wèn)題你想回溯結(jié)果發(fā)現(xiàn)日志里只有任務(wù)成功四個(gè)字中間執(zhí)行了什么命令、訪問(wèn)了哪些資源、耗時(shí)多久全都沒(méi)有記錄。這在合規(guī)場(chǎng)景下是致命的。OpenShell 的設(shè)計(jì)思路本質(zhì)上就是針對(duì)這三類問(wèn)題各給一套機(jī)制路徑和資源的邊界約束、權(quán)限的最小化授予、以及全鏈路的執(zhí)行審計(jì)。2.2 執(zhí)行外殼與沙箱的區(qū)別這里要澄清一個(gè)容易混淆的概念。很多人一聽(tīng)安全執(zhí)行就想到沙箱Sandbox覺(jué)得把 Agent 扔進(jìn)容器里就完事了。但沙箱和執(zhí)行外殼是兩回事。沙箱解決的是隔離問(wèn)題——讓 Agent 在一個(gè)受限的環(huán)境里跑跑壞了不影響宿主。但沙箱不解決策略問(wèn)題——Agent 在沙箱里依然可以執(zhí)行任意命令只是影響范圍被限制了。而 OpenShell 這類執(zhí)行外殼解決的是管控問(wèn)題——它不只是隔離還要在每一次執(zhí)行前做策略判斷執(zhí)行中做資源監(jiān)控執(zhí)行后做審計(jì)記錄。打個(gè)比方沙箱像是給小孩一個(gè)圍欄讓他在圍欄里玩執(zhí)行外殼像是給小孩配了一個(gè)保姆保姆會(huì)判斷這個(gè)動(dòng)作能不能做這個(gè)玩具能不能碰做完要記下來(lái)。兩者可以疊加使用但職責(zé)不同。我實(shí)測(cè)下來(lái)的體會(huì)是如果你的 Agent 只是做只讀操作沙箱可能就夠了但只要涉及寫(xiě)操作、外部調(diào)用、資源消耗執(zhí)行外殼這一層就省不掉。2.3 核心設(shè)計(jì)原則最小權(quán)限加顯式授權(quán)OpenShell 背后有一條很清晰的設(shè)計(jì)原則我把它總結(jié)成八個(gè)字最小權(quán)限顯式授權(quán)。最小權(quán)限的意思是Agent 默認(rèn)什么都不能做每一樣能力都需要被顯式地授予。這跟傳統(tǒng)的給個(gè)管理員賬號(hào)隨便用是完全相反的思路。顯式授權(quán)的意思是授權(quán)不是一次性的而是每次執(zhí)行都要經(jīng)過(guò)策略判斷策略可以基于命令內(nèi)容、目標(biāo)路徑、時(shí)間窗口、調(diào)用頻率等多個(gè)維度。這條原則聽(tīng)起來(lái)簡(jiǎn)單但落地的時(shí)候有很多細(xì)節(jié)。比如命令內(nèi)容怎么判斷是字符串匹配還是語(yǔ)法解析字符串匹配容易被繞過(guò)語(yǔ)法解析又太重。OpenShell 在這塊的取舍后面我會(huì)專門(mén)講。3. 核心架構(gòu)拆解與關(guān)鍵組件3.1 整體分層策略層、執(zhí)行層、審計(jì)層OpenShell 的架構(gòu)我理解下來(lái)是三層結(jié)構(gòu)從上到下依次是策略層、執(zhí)行層、審計(jì)層。策略層負(fù)責(zé)能不能做的判斷。它接收 Agent 發(fā)來(lái)的執(zhí)行請(qǐng)求請(qǐng)求里包含要執(zhí)行的命令、目標(biāo)資源、上下文信息然后根據(jù)預(yù)定義的策略規(guī)則返回允許、拒絕或者需要人工確認(rèn)。策略層的核心是一套規(guī)則引擎規(guī)則可以用聲明式的方式寫(xiě)比如允許讀取 /data 目錄下的文件但禁止寫(xiě)入。執(zhí)行層負(fù)責(zé)怎么做的落地。一旦策略層放行執(zhí)行層就在受控的環(huán)境里真正執(zhí)行命令同時(shí)監(jiān)控資源使用情況比如 CPU、內(nèi)存、執(zhí)行時(shí)長(zhǎng)、輸出大小。執(zhí)行層還要處理超時(shí)、中斷、異常這些情況。審計(jì)層負(fù)責(zé)做了什么的記錄。每一次執(zhí)行請(qǐng)求無(wú)論放行還是拒絕都要留下完整的記錄包括請(qǐng)求內(nèi)容、策略判斷結(jié)果、執(zhí)行結(jié)果、資源消耗。審計(jì)層的記錄要能支撐事后回溯和合規(guī)檢查。這三層的邊界要清晰不能混在一起。我見(jiàn)過(guò)一些項(xiàng)目把策略判斷寫(xiě)在執(zhí)行邏輯里結(jié)果就是策略改一次要?jiǎng)訄?zhí)行代碼維護(hù)成本極高。OpenShell 把三層分開(kāi)策略可以獨(dú)立迭代執(zhí)行層保持穩(wěn)定審計(jì)層獨(dú)立擴(kuò)展。3.2 策略引擎的規(guī)則表達(dá)策略引擎是 OpenShell 最核心也最需要仔細(xì)設(shè)計(jì)的部分。規(guī)則怎么表達(dá)直接決定了這套東西好不好用。我梳理了一下規(guī)則表達(dá)大概有三種粒度粒度表達(dá)方式優(yōu)點(diǎn)缺點(diǎn)命令級(jí)匹配命令字符串或正則簡(jiǎn)單直接容易被繞過(guò)維護(hù)成本高語(yǔ)法級(jí)解析命令的 AST按語(yǔ)義匹配準(zhǔn)確難繞過(guò)實(shí)現(xiàn)復(fù)雜需要覆蓋各種 shell 語(yǔ)法能力級(jí)抽象成讀、寫(xiě)、執(zhí)行、網(wǎng)絡(luò)等能力穩(wěn)定易理解粒度粗可能誤傷OpenShell 實(shí)際采用的是混合策略對(duì)常見(jiàn)命令用語(yǔ)法級(jí)解析對(duì)復(fù)雜場(chǎng)景降級(jí)到命令級(jí)匹配同時(shí)提供能力級(jí)的抽象接口給上層業(yè)務(wù)用。這個(gè)取舍我覺(jué)得是合理的因?yàn)榧冋Z(yǔ)法級(jí)解析的成本太高而純命令級(jí)匹配又太不安全。規(guī)則的具體寫(xiě)法通常是聲明式的配置類似這樣rules: - name: allow-read-data match: capability: read path: /data/** action: allow - name: deny-write-system match: capability: write path: /system/** action: deny - name: confirm-network match: capability: network action: confirm這種聲明式的好處是策略和代碼解耦安全團(tuán)隊(duì)可以獨(dú)立維護(hù)策略不用改執(zhí)行代碼。壞處是表達(dá)能力有限遇到復(fù)雜邏輯還是得寫(xiě)代碼。3.3 執(zhí)行隔離的技術(shù)選型執(zhí)行層怎么隔離是個(gè)技術(shù)選型問(wèn)題。常見(jiàn)的有幾種方案進(jìn)程級(jí)隔離、容器級(jí)隔離、虛擬機(jī)級(jí)隔離。進(jìn)程級(jí)隔離最輕用操作系統(tǒng)的用戶權(quán)限和命名空間做限制啟動(dòng)快開(kāi)銷小但隔離強(qiáng)度弱遇到內(nèi)核漏洞可能被突破。容器級(jí)隔離居中用容器技術(shù)做文件系統(tǒng)、網(wǎng)絡(luò)、進(jìn)程的隔離啟動(dòng)較快隔離強(qiáng)度夠用是目前主流的選擇。虛擬機(jī)級(jí)隔離最重隔離強(qiáng)度最高但啟動(dòng)慢開(kāi)銷大一般用在多租戶場(chǎng)景。OpenShell 默認(rèn)走的是容器級(jí)隔離同時(shí)保留了切換到進(jìn)程級(jí)和虛擬機(jī)級(jí)的接口。這個(gè)選擇我覺(jué)得是對(duì)的因?yàn)榇蟛糠?Agent 場(chǎng)景不需要虛擬機(jī)級(jí)別的隔離容器級(jí)已經(jīng)能覆蓋絕大多數(shù)風(fēng)險(xiǎn)而且啟動(dòng)速度能滿足交互式 Agent 的需求。注意容器級(jí)隔離不是萬(wàn)能的如果 Agent 需要訪問(wèn)宿主機(jī)的某些資源比如 GPU、特定設(shè)備隔離配置會(huì)變得復(fù)雜需要仔細(xì)設(shè)計(jì)掛載和權(quán)限。3.4 審計(jì)數(shù)據(jù)的結(jié)構(gòu)與存儲(chǔ)審計(jì)層的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)直接決定了事后能不能查得清楚。我見(jiàn)過(guò)一些項(xiàng)目審計(jì)日志就記個(gè)時(shí)間戳和命令出了問(wèn)題根本查不出上下文。OpenShell 的審計(jì)記錄我理解至少包含這幾個(gè)字段請(qǐng)求 ID、會(huì)話 ID、Agent 標(biāo)識(shí)、請(qǐng)求時(shí)間、命令內(nèi)容、目標(biāo)資源、策略判斷結(jié)果、執(zhí)行狀態(tài)、開(kāi)始時(shí)間、結(jié)束時(shí)間、資源消耗、輸出摘要、錯(cuò)誤信息。這些字段組合起來(lái)才能支撐誰(shuí)在什么時(shí)候讓哪個(gè) Agent 做了什么結(jié)果如何這樣的查詢。存儲(chǔ)方面審計(jì)數(shù)據(jù)的特點(diǎn)是寫(xiě)入頻繁、查詢較少、需要長(zhǎng)期保留。所以通常用追加寫(xiě)的日志存儲(chǔ)或者時(shí)序數(shù)據(jù)庫(kù)而不是關(guān)系型數(shù)據(jù)庫(kù)。如果數(shù)據(jù)量特別大還要考慮冷熱分離近期數(shù)據(jù)放快存儲(chǔ)歷史數(shù)據(jù)歸檔到對(duì)象存儲(chǔ)。4. 實(shí)操落地從零搭一個(gè)受控執(zhí)行環(huán)境4.1 環(huán)境準(zhǔn)備與依賴確認(rèn)假設(shè)你要在自己的項(xiàng)目里落地一套類似 OpenShell 的受控執(zhí)行環(huán)境我按實(shí)操順序講一遍。第一步是確認(rèn)基礎(chǔ)環(huán)境。你需要一臺(tái) Linux 機(jī)器內(nèi)核版本建議 5.10 以上因?yàn)橐玫揭恍┹^新的命名空間和 cgroup 特性。容器運(yùn)行時(shí)我推薦用 containerd 而不是 Docker因?yàn)?containerd 更輕API 更干凈適合做底層集成。如果團(tuán)隊(duì)已經(jīng)重度使用 Docker用 Docker 也行只是多一層封裝。第二步是確認(rèn)權(quán)限模型。執(zhí)行環(huán)境需要一個(gè)專用的系統(tǒng)用戶來(lái)跑 Agent 進(jìn)程這個(gè)用戶不能有 sudo 權(quán)限不能屬于 docker 組家目錄要獨(dú)立。我一般會(huì)建一個(gè)叫agent-runner的用戶專門(mén)用來(lái)跑執(zhí)行層。sudo useradd -r -s /bin/false -d /var/lib/agent-runner agent-runner sudo mkdir -p /var/lib/agent-runner sudo chown agent-runner:agent-runner /var/lib/agent-runner第三步是規(guī)劃目錄結(jié)構(gòu)。我習(xí)慣把策略、執(zhí)行、審計(jì)三塊的數(shù)據(jù)分開(kāi)存放/opt/openshell/ policies/ # 策略配置 runtime/ # 執(zhí)行層工作目錄 audit/ # 審計(jì)日志 workspace/ # Agent 可操作的沙箱目錄workspace 目錄是 Agent 唯一能自由讀寫(xiě)的地方其他目錄都要通過(guò)策略嚴(yán)格控制。4.2 策略配置的編寫(xiě)與調(diào)試策略配置是落地過(guò)程中最花時(shí)間的部分。我的經(jīng)驗(yàn)是不要一上來(lái)就寫(xiě)一堆規(guī)則而是先跑一遍典型任務(wù)把 Agent 實(shí)際會(huì)執(zhí)行的命令都收集起來(lái)再針對(duì)性地寫(xiě)規(guī)則。收集命令的方法很簡(jiǎn)單先開(kāi)一個(gè)只記錄不攔截的模式讓 Agent 正常跑把所有執(zhí)行請(qǐng)求都記下來(lái)。跑個(gè)幾十次典型任務(wù)你就能看到 Agent 實(shí)際的行為模式。然后基于這些數(shù)據(jù)來(lái)寫(xiě)策略比拍腦袋寫(xiě)要靠譜得多。寫(xiě)策略的時(shí)候我建議遵循幾個(gè)原則默認(rèn)拒絕沒(méi)明確允許的一律拒絕不要圖省事寫(xiě)通配的 allow。路徑收斂允許的路徑要盡量具體能用/data/reports/*.csv就不要用/data/**。能力分離讀和寫(xiě)分開(kāi)授權(quán)不要給一個(gè)讀寫(xiě)的籠統(tǒng)權(quán)限。頻率限制對(duì)高頻操作加限流防止 Agent 陷入循環(huán)瘋狂調(diào)用。調(diào)試策略的時(shí)候OpenShell 一般會(huì)提供一個(gè) dry-run 模式就是只判斷不執(zhí)行把判斷結(jié)果打出來(lái)。這個(gè)模式非常有用可以在不影響真實(shí)環(huán)境的情況下驗(yàn)證策略是否符合預(yù)期。4.3 執(zhí)行層的資源限制參數(shù)執(zhí)行層的資源限制是防止 Agent 把機(jī)器跑掛的關(guān)鍵。我梳理了幾個(gè)必須設(shè)置的參數(shù)參數(shù)建議值說(shuō)明CPU 限額2 核防止單個(gè) Agent 占滿 CPU內(nèi)存限額2GB防止內(nèi)存泄漏拖垮系統(tǒng)執(zhí)行超時(shí)300 秒防止命令卡死輸出大小10MB防止輸出爆炸進(jìn)程數(shù)64防止 fork 炸彈文件描述符1024防止句柄耗盡這些參數(shù)不是拍腦袋定的要根據(jù)實(shí)際任務(wù)調(diào)整。比如做數(shù)據(jù)處理的 Agent內(nèi)存限額可能要調(diào)到 8GB做交互式查詢的 Agent超時(shí)可以調(diào)到 60 秒。關(guān)鍵是每個(gè)參數(shù)都要有明確的理由不能隨便填。設(shè)置這些參數(shù)的時(shí)候要注意 cgroup 的層級(jí)關(guān)系。如果執(zhí)行層本身跑在容器里容器已經(jīng)有資源限制那執(zhí)行層內(nèi)部的限制要小于容器的限制否則內(nèi)層限制形同虛設(shè)。4.4 審計(jì)日志的采集與查詢審計(jì)日志的采集我建議用結(jié)構(gòu)化日志每條記錄是一個(gè) JSON 對(duì)象方便后續(xù)解析和查詢。不要用純文本日志因?yàn)榧兾谋窘馕銎饋?lái)太痛苦。{ request_id: req-20240115-001, session_id: sess-abc123, agent_id: agent-data-cleaner, timestamp: 2024-01-15T10:30:00Z, command: rm -f /workspace/temp/*.tmp, capability: write, target_path: /workspace/temp, policy_result: allow, exec_status: success, duration_ms: 45, resource_usage: { cpu_ms: 12, memory_kb: 2048 }, output_summary: removed 3 files }查詢方面如果日志量不大用 grep 加 jq 就夠了。如果日志量大建議上專門(mén)的日志系統(tǒng)比如 Loki 或者 Elasticsearch。查詢的時(shí)候最常用的幾個(gè)維度是按 Agent 查、按時(shí)間范圍查、按策略結(jié)果查、按目標(biāo)路徑查。提示審計(jì)日志本身也要保護(hù)不能讓 Agent 有權(quán)限修改或刪除。審計(jì)目錄的權(quán)限要設(shè)置成只有審計(jì)服務(wù)能寫(xiě)Agent 只能讀自己的記錄。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 策略誤判該放行的被攔了策略誤判是最常見(jiàn)的問(wèn)題尤其是剛上線的時(shí)候。典型表現(xiàn)是 Agent 執(zhí)行一個(gè)正常操作結(jié)果被策略攔了任務(wù)失敗。排查思路是這樣的先看審計(jì)日志里這條請(qǐng)求的策略判斷結(jié)果確認(rèn)是被哪條規(guī)則攔的。然后看這條規(guī)則的匹配條件對(duì)比請(qǐng)求的實(shí)際內(nèi)容找出不匹配的地方。常見(jiàn)的原因有幾個(gè)路徑匹配用了絕對(duì)路徑但請(qǐng)求里是相對(duì)路徑命令匹配用了完整命令但請(qǐng)求里帶了參數(shù)能力判斷把讀操作誤判成了寫(xiě)操作。解決方法是調(diào)整規(guī)則的匹配條件或者給規(guī)則加例外。但要注意加例外不能破壞最小權(quán)限原則例外的范圍要盡量小。我踩過(guò)的一個(gè)坑是策略里寫(xiě)了允許/workspace/**的寫(xiě)操作但 Agent 實(shí)際用的是/workspace這個(gè)路徑本身不帶尾部斜杠結(jié)果匹配不上。后來(lái)統(tǒng)一了路徑規(guī)范所有路徑都做標(biāo)準(zhǔn)化處理問(wèn)題就解決了。5.2 執(zhí)行超時(shí)命令卡住不返回執(zhí)行超時(shí)是另一個(gè)高頻問(wèn)題。Agent 執(zhí)行一個(gè)命令等了很久沒(méi)返回最后超時(shí)失敗。這種情況可能是命令本身耗時(shí)也可能是命令卡死了。排查的時(shí)候先看審計(jì)日志里的執(zhí)行時(shí)長(zhǎng)如果接近超時(shí)閾值說(shuō)明命令確實(shí)慢。然后看命令內(nèi)容判斷是正常慢還是異常慢。正常慢的話調(diào)大超時(shí)閾值異常慢的話要找出卡住的原因。常見(jiàn)的卡死原因有命令在等待輸入比如read或者cat不帶參數(shù)命令在等待網(wǎng)絡(luò)響應(yīng)但網(wǎng)絡(luò)不通命令陷入了死循環(huán)。針對(duì)這些情況執(zhí)行層要設(shè)置標(biāo)準(zhǔn)輸入為空網(wǎng)絡(luò)訪問(wèn)要加超時(shí)循環(huán)要有次數(shù)限制。我一般會(huì)在執(zhí)行層加一個(gè)心跳檢測(cè)命令執(zhí)行過(guò)程中定期檢查進(jìn)程狀態(tài)如果發(fā)現(xiàn)進(jìn)程已經(jīng)僵死就主動(dòng)殺掉不用等到超時(shí)。5.3 資源耗盡Agent 把機(jī)器跑掛了資源耗盡是最危險(xiǎn)的問(wèn)題輕則影響其他任務(wù)重則導(dǎo)致整臺(tái)機(jī)器不可用。典型表現(xiàn)是 CPU 打滿、內(nèi)存耗盡、磁盤(pán)寫(xiě)滿。排查的時(shí)候先看監(jiān)控?cái)?shù)據(jù)確認(rèn)是哪個(gè)資源先耗盡的。然后看審計(jì)日志找出耗盡前執(zhí)行的那批命令。常見(jiàn)的原因有Agent 陷入了重試循環(huán)瘋狂調(diào)用Agent 處理的數(shù)據(jù)量超出預(yù)期內(nèi)存爆了Agent 的輸出沒(méi)有限制把磁盤(pán)寫(xiě)滿了。解決方法是多管齊下執(zhí)行層設(shè)置硬性資源限制超出就殺策略層加頻率限制防止循環(huán)調(diào)用審計(jì)層加告警資源使用超過(guò)閾值就通知。我個(gè)人的經(jīng)驗(yàn)是資源限制的閾值要留足余量不能卡得太死。比如內(nèi)存限額設(shè) 2GB實(shí)際任務(wù)峰值用到 1.8GB那就很危險(xiǎn)稍微波動(dòng)一下就超了。一般建議閾值是峰值的 1.5 到 2 倍。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案策略誤攔規(guī)則匹配條件不準(zhǔn)確對(duì)比規(guī)則和請(qǐng)求內(nèi)容調(diào)整匹配條件或加例外執(zhí)行超時(shí)命令卡死或確實(shí)慢看執(zhí)行時(shí)長(zhǎng)和命令內(nèi)容調(diào)閾值或修命令資源耗盡循環(huán)調(diào)用或數(shù)據(jù)量超預(yù)期看監(jiān)控和審計(jì)日志加限制和告警審計(jì)缺失審計(jì)服務(wù)異?；驒?quán)限問(wèn)題檢查審計(jì)服務(wù)狀態(tài)修復(fù)服務(wù)或權(quán)限隔離失效容器配置錯(cuò)誤檢查容器配置修正掛載和權(quán)限5.5 幾個(gè)容易被忽略的細(xì)節(jié)最后分享幾個(gè)我在實(shí)操中發(fā)現(xiàn)的、文檔里一般不會(huì)寫(xiě)的細(xì)節(jié)。第一個(gè)是環(huán)境變量的處理。Agent 執(zhí)行命令的時(shí)候環(huán)境變量會(huì)繼承執(zhí)行層的環(huán)境。如果執(zhí)行層環(huán)境里有敏感信息比如 API keyAgent 就能讀到。所以執(zhí)行層要清理環(huán)境變量只保留必要的幾個(gè)。第二個(gè)是工作目錄的隔離。Agent 執(zhí)行命令的默認(rèn)工作目錄要設(shè)置成沙箱目錄不能是執(zhí)行層的工作目錄。否則 Agent 用相對(duì)路徑操作的時(shí)候可能操作到不該操作的地方。第三個(gè)是信號(hào)處理。Agent 執(zhí)行命令的時(shí)候如果執(zhí)行層收到終止信號(hào)要正確傳遞給子進(jìn)程不能直接殺掉執(zhí)行層導(dǎo)致子進(jìn)程變成孤兒進(jìn)程。這個(gè)細(xì)節(jié)在容器環(huán)境里尤其重要。第四個(gè)是日志脫敏。審計(jì)日志里可能包含敏感信息比如命令里的密碼、路徑里的用戶名。記錄之前要做脫敏處理把敏感部分替換掉。這個(gè)工作要在審計(jì)層做不能指望 Agent 自己處理。6. 擴(kuò)展方向與個(gè)人實(shí)踐體會(huì)OpenShell 這類執(zhí)行外殼往深了做還有很多空間。我梳理了幾個(gè)我覺(jué)得有價(jià)值的方向。一個(gè)是策略的自動(dòng)化生成?，F(xiàn)在策略主要靠人工寫(xiě)成本高且容易遺漏。如果能基于歷史執(zhí)行數(shù)據(jù)自動(dòng)學(xué)習(xí)出合理的策略基線再讓人工微調(diào)效率會(huì)高很多。這個(gè)方向已經(jīng)有了一些研究但落地還不成熟。另一個(gè)是多 Agent 的協(xié)同管控。單個(gè) Agent 的執(zhí)行管控相對(duì)簡(jiǎn)單但多個(gè) Agent 協(xié)同工作時(shí)權(quán)限的傳遞、資源的競(jìng)爭(zhēng)、依賴的管理都會(huì)變復(fù)雜。比如 Agent A 生成的文件Agent B 能不能讀這個(gè)需要一套跨 Agent 的權(quán)限模型。還有一個(gè)是執(zhí)行結(jié)果的可驗(yàn)證性?，F(xiàn)在審計(jì)記錄的是執(zhí)行了什么但沒(méi)法驗(yàn)證執(zhí)行結(jié)果是否正確。如果能結(jié)合一些校驗(yàn)機(jī)制比如文件哈希、數(shù)據(jù)庫(kù)快照就能做到執(zhí)行結(jié)果的可驗(yàn)證這在合規(guī)場(chǎng)景下很有價(jià)值。我自己在實(shí)際項(xiàng)目里落地這套東西的體會(huì)是技術(shù)實(shí)現(xiàn)只是一半另一半是流程和習(xí)慣。策略要有人維護(hù)審計(jì)要有人看告警要有人處理。如果只是搭了框架沒(méi)人管那跟沒(méi)搭區(qū)別不大。所以落地之前先想清楚誰(shuí)來(lái)負(fù)責(zé)這套東西的日常運(yùn)營(yíng)比急著寫(xiě)代碼更重要。最后再分享一個(gè)小技巧剛開(kāi)始落地的時(shí)候不要追求一步到位先把記錄做起來(lái)把 Agent 的行為都記下來(lái)跑一段時(shí)間有了數(shù)據(jù)再基于數(shù)據(jù)做策略。這樣比一上來(lái)就寫(xiě)一堆規(guī)則要穩(wěn)妥得多也不會(huì)因?yàn)檎`攔影響業(yè)務(wù)。等策略穩(wěn)定了再逐步收緊權(quán)限最終達(dá)到最小權(quán)限的狀態(tài)。這個(gè)過(guò)程可能要幾周甚至幾個(gè)月但每一步都走得踏實(shí)。