大模型 Agent 安全问题，需要认真管管了

这两天 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 当安全员"会同时成为标配

制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个，谢谢你看我的文章，我们下篇再见！