這兩天 AWS 和 Vercel 幾乎前后腳開源了兩個項目，一個叫 Rex（github.com/trusted-remote-execution），一個叫 deepsec(github.com/vercel-labs/deepsec)

剛開始我以為這倆沒啥關系，仔細看完發現它們是同一道題的正反兩面：

• Rex ： 約束 Agent 能干啥——你給它寫 Cedar 策略，越界一律拒絕

• deepsec ： 派 Agent 當安全研究員——專門去你代碼庫里挖那些躺了幾年的漏洞

一個負責"別讓 Agent 亂來"，一個負責"讓 Agent 拼命找事"，今天一起聊

一、AWS Rex：給 AI 腳本套上策略韁繩 它解決啥問題

老 DevOps 同學都懂一個無解的痛：腳本拿到了執行環境的全部權限

一個本來只是想"讀讀日志"的腳本，能力上和"刪庫跑路"的腳本是一模一樣的——靠的是寫腳本的人有良心、Reviewer 沒看走眼、CI 配得仔細

人類還能扛住，Agent 時代直接崩塌：

? 當 Agent 自己生成、自己執行腳本時，沒有人 review 每一次系統調用——代碼評審、審批流、白名單這些防護，全在"代碼運行時才生成"這一前提下失效

Rex 的思路簡單粗暴：腳本說要做什么，策略說什么被允許，每個操作都先查策略再執行

用一張流程文字圖描述：

Rhai 腳本 ──? Rex SDK 操作（read/write/open…）──? Cedar 策略檢查
                                                  │
                              通過 ─────? 執行系統調用
                              拒絕 ─────? ACCESS_DENIED_EXCEPTION

組件

選了啥

為啥

腳本語言

Rhai

輕量級嵌入式語言， 零內置系統訪問

策略引擎

Cedar

AWS 自家的策略語言，已經在 IAM/Verified Permissions 里跑了

Runtime

rex-runner（Rust）

唯一能碰主機的入口

最關鍵的是 Rhai 這個選擇——它本身根本沒有 read/write/exec 這些系統調用，所有能摸到主機的能力都得通過 Rex 提供的 SDK，而 SDK 的每一次調用都先過 Cedar 策略

這就把"腳本"和"權限"徹底解耦了：腳本一字不改，換個策略就換一套權限

Agent 撞墻了會怎樣

這是我覺得 Rex 最妙的地方：

? 如果 Agent 因為幻覺、提示詞注入或者過度發揮，生成了一個超出策略的腳本——它會收到一個明確的 ACCESS_DENIED_EXCEPTION，而不是造成意料之外的副作用 Agent 可以觀察到這個錯誤、推理、然后調整

換句話說，Rex 不是把 Agent 關進沙箱（那種思路約束的是 Agent 本身），而是約束 Agent 能對宿主機做什么——主權在服務 owner 手上，不管 Agent 怎么折騰，硬邊界守得住

5 分鐘跑通 Demo

按官方教程，一行 Cargo 裝好：

cargo install rex-runner

寫一個策略文件，明確只允許 open 和 read：

permit(
    principal,
    action in [
        file_system::Action::"open",
        file_system::Action::"read",


         // 取消注釋才允許 write：
        //file_system::Action::"create",
        //file_system::Action::"write",
    ],
    resource
);

寫一個故意"越權"的腳本——先寫文件再讀：

write("/tmp/hello.txt", "Hello from Rex!");
cat("/tmp/hello.txt")

跑：

rex-runner \
  --script-file script.rhai \
  --policy-file policy.cedar \
  --output-format human

直接報錯：

error: Permission denied:
  file_system::Action::"create" on /tmp/hello.txt

把 create、write 在策略里取消注釋再跑，腳本一字不改，這回就能正常輸出 Hello from Rex!

? 腳本沒變，只改了策略——這就是 Rex 想傳遞的核心

文檔里還提到可以和 IAM、SSM 配合，把這套策略接到 AWS 已有的權限體系里，企業級落地的鏈路是通的

二、Vercel deepsec：讓 Agent 自己去挖漏洞 它解決啥問題

聊完防守，聊進攻

deepsec 的定位是 "agent-powered vulnerability scanner"——不是 SAST、不是 DAST，是讓 Claude 和 Codex 這兩個最強的 coding agent 真的去你代碼里翻

按官方原話：

? 配置上用最強模型 + 最大思考預算（Opus 4.7 max effort + GPT-5.5 xhigh reasoning），掃一個大倉庫可能花幾千甚至上萬美元

聽起來燒錢？是真燒錢，但 Vercel 的用戶反饋值這價：

? James Perkins, Unkey CEO：deepsec 的掃描是我們用過最徹底的，問題最多，真陽性率也好 Steven Tey, dub.co Founder：我們收到過太多自動化安全報告，大多數都不可執行——deepsec 是第一個能挖出"我們真希望安全工程師能 flag 出來"的問題的工具

deepsec 把"讓 Agent 找漏洞"拆得很工程化：

步驟

干啥

Scan

先用 regex 全倉掃一遍，定位安全敏感的文件

Investigate

Agent 對每個候選文件做深度調查——追數據流、查緩解措施、給出嚴重級

Revalidate

第二個 Agent 對發現做交叉驗證，去假陽性、重新分級

Enrich

用 Git 元數據找到對應該修復的人

Export

把發現導出成可以變工單的指令格式（人類和 Agent 都能用）

這套流程里我最欣賞的是 Revalidate——單 Agent 給的 finding 信噪比注定不會高，再過一遍專門做"挑刺"的 Agent，假陽性率官方說是 10–20%

10–20% 的假陽性率是個什么概念？SonarQube、CodeQL 這類傳統 SAST 工具能做到 20–30% 已經算可以接受，deepsec 在面對"非確定性 LLM"的前提下還能壓到這個水平，工程上是花了功夫的

跑一遍要錢 + 要算力

# 在你倉庫根目錄
npx deepsec init
cd .deepsec
pnpm install

然后官方建議你讓你自己的 coding agent 去自舉——給 Claude/Codex 喂這個 prompt：

? 讀 .deepsec/node_modules/deepsec/SKILL.md 理解工具，然后讀 .deepsec/data/ /SETUP.md 跟著做：掃一下 README、AGENTS.md/CLAUDE.md 和幾個有代表性的代碼文件，把 INFO.md 各個章節填上 控制在 50–100 行——抓 3–5 個例子就夠，別窮舉

填完跑：

pnpm deepsec scan
pnpm deepsec process
pnpm deepsec revalidate   # 可選，能壓假陽性
pnpm deepsec export --format md-dir --out ./findings

大倉庫單機要掃好幾天，于是 deepsec 還提供了一個殺手锏——散到 Vercel Sandbox 上并發跑：

pnpm deepsec sandbox process --project-id my-app --sandboxes 10 --concurrency 4

按 Vercel 自己的說法，他們掃自家代碼經常拉到 1000+ 并發 sandbox，幾天的活兒壓成幾小時

不需要"安全特供模型"

很多人以為安全任務必須用 Anthropic / OpenAI 那種"cyber 微調版"——deepsec 實測下來，原版的 Opus 4.7 和 GPT-5.5 完全夠用，工具內置了一個 classifier 檢測拒答，遇到拒絕會自動重試

這個細節挺重要：意味著普通用戶用現成訂閱就能跑，不用走特殊審批

三、放一起看：Agent × Security 的攻守同源

我把這兩個項目放一起聊不是湊數，它們其實在回答同一個問題：

? 當 AI Agent 真的在生產環境里寫代碼、跑腳本、改系統時，安全模型該怎么變？

AWS Rex

Vercel deepsec

角色

防守

進攻

誰是主體

Agent 是被約束方

Agent 是研究員

信任假設

"Agent 會出錯/被注入"

"Agent 比規則更會找漏洞"

落地形態

Rust runtime + Cedar 策略

Coding agent + 5 步流水線

關鍵技術押注

策略與代碼解耦

用最強模型 + 多 Agent 交叉驗證

注意它們都不約而同地承認了一個前提：單個 Agent 不可信

• Rex 的回答：那就不讓你越界，每個操作都查

• deepsec 的回答：那就讓兩個 Agent 互相挑刺，把假陽性壓下去

這種"不相信單點 Agent，但相信 Agent + 工程化約束"的思路，我覺得是 2026 年 Agent 落地最成熟的姿態

總結

• Rex ：值得每一個準備讓 Agent 碰生產環境的團隊認真試試，Cedar + Rhai 這套配置確實優雅；缺點是目前操作集還偏基礎（文件系統等），SDK 擴展看后續社區

• deepsec ：要錢要算力，但 對中大型代碼庫是真有用 ——尤其是 auth、數據層、后端服務這種安全面大的場景，跑一次幾千美元換出 5 個真陽性 critical 漏洞，怎么算都劃算

• 共同啟示 ：未來一年 Agent 安全工具會爆發，"約束 Agent"和"使用 Agent 當安全員"會同時成為標配

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！