现在的 AI Agent，已经不只是给你补几行代码了。

Codex、Claude Code、Cline、OpenClaw 这类工具可以读取项目文件、执行 Shell、调用 MCP、访问网络，甚至连续运行几十分钟。

能力越强，一个问题也越难回避：

当 Agent 真能操作你的电脑时，谁来限制它的权限？

只靠提示词里写一句“不要做危险操作”，显然不够。

每次弹出确认框再人工判断，也很容易在连续工作中点成“全部允许”。

最近看到一个采用 Apache-2.0 许可证的开源项目 Rampart，它做的事情很直接：在 AI Agent 和工具执行之间，加一道本地策略防火墙。

普通的 git status 可以继续运行；读取 SSH 私钥可以直接拒绝；生产部署可以暂停并等待人工批准；可疑操作则放行但重点记录。

它不是让 Agent 自己“更谨慎”，而是把哪些事能做、哪些事不能做，变成一套真正会执行的规则。

AI Agent 的安全，为什么不能只靠确认框？

传统开发工具通常等人下命令。

Agent 不一样。它会自己拆任务、选工具、读文件、改代码，再根据运行结果继续下一步。

这让一次自然语言指令，可能在后台展开成几十次工具调用。

风险也不只是一条夸张的 rm -rf /。

  • 它可能为了排查问题读取 .env、SSH 私钥或云凭证；
  • 它可能把本地内容发送到一个外部域名；
  • 它可能在错误的环境执行数据库或部署命令；
  • 它可能调用名称含糊、权限却很大的 MCP 工具；
  • 它还可能被网页、文档或代码注释里的提示注入误导。

提示词约束的问题是，它仍然依赖模型遵守。

确认框的问题是，它把策略判断全部推给了当时正在操作的人。你需要在几秒钟里判断命令、路径、环境和后果，连续弹窗还会让人形成点击惯性。

Rampart 的思路是把这部分判断提前固化：已知危险操作自动拒绝，已知安全操作自动放行，真正需要判断的少数操作再找人。

Rampart 到底插在什么位置？

Rampart 不是聊天模型，也不是另一个 Agent。

它是一个策略执行层。

支持的 Agent 集成会把即将执行的工具调用交给 Rampart。Rampart 根据 YAML 策略检查命令、文件路径、域名或 MCP 工具，再返回相应决定。

目前主要动作包括：

动作 会发生什么 适合什么场景
allow 允许执行并记录 普通开发命令、已知安全路径
deny 执行前拦截 删除、密钥读取、危险外传
ask 暂停并请求人工批准 部署、发布、高权限变更
watch 允许执行，但提高审计级别 暂时不确定、希望先观察的行为

另外还有 webhook，可以把特定决策交给外部 HTTP 服务。

当多份策略同时命中时，官方文档给出的优先级是 deny 最高，然后才是 webhook、ask、watch 和 allow。也就是说，只要任意一份策略明确拒绝，就不会被另一条放行规则轻易覆盖。

这里最关键的变化，是把“Agent 能不能做某件事”从一段自然语言，变成了确定性的策略匹配。

模型负责思考下一步，Rampart 负责检查这一步是否越界。

不只是拦命令，也能管文件、网络和 MCP

从官方策略引擎文档看，Rampart 当前可以针对这些工具类型匹配规则：

  • exec：检查 Shell 命令；
  • read：检查读取的文件路径；
  • write：检查写入的文件路径；
  • fetch：检查访问的域名；
  • MCP 工具：按工具类别或具体工具名设置策略。

例如，标准策略可以拦截读取 .env 和 SSH 私钥，阻止破坏性命令，也可以要求 Agent 在执行生产部署前获得批准。

MCP 尤其值得注意。

一个 Agent 接上文件系统、数据库、云平台和消息工具以后，风险不再只存在于 Shell。一个名为 delete、destroy、drop 的 MCP 工具，本身就可能造成不可逆结果。

Rampart 会对 MCP 工具做分类，标准配置会拒绝被识别为破坏性的工具，对危险或无法分类的工具要求批准；你也可以直接为某个具体工具名写规则。

这比在每个 MCP Server 里各写一遍安全逻辑更集中，但它能看到的范围仍取决于接入方式是否把对应调用交给了 Rampart。

规则可以和项目一起版本管理

Rampart 的全局策略默认放在 ~/.rampart/policies/。

项目也可以包含自己的 .rampart/policy.yaml，把仓库特有的约束随代码一起维护。

例如，一个项目可以规定：

  • 不允许 Agent 读取生产密钥目录；
  • 不允许直接向主分支推送；
  • terraform apply 必须人工批准；
  • 只能访问指定的文档与包管理域名；
  • 某些 MCP 查询可以执行，删除类操作全部拒绝。

这种方式很适合团队协作。

规则可以 Review、可以 Diff、可以回滚，也能在 CI 中用 rampart test 验证。安全边界不再藏在某个人点过的确认框里，而是变成仓库里一份可讨论的配置。

官方威胁模型还特别说明：项目策略只能增加限制，不能削弱全局策略，最终仍然遵循 deny-wins。

不过，项目策略文件本身也应该被当成安全边界。

对陌生仓库，仍然要先检查其中的配置；也可以设置 RAMPART_NO_PROJECT_POLICY=1，跳过项目本地策略。

安装和接入并不复杂，但不同 Agent 不完全一样

官方提供了 Homebrew、安装脚本和 Go 安装三种方式。

macOS 用户可以先用：

brew install peg/tap/rampart
rampart quickstart

quickstart 会检测当前环境里可接入的 Agent，选择对应保护路径并做验证。

也可以单独配置：

# Codex CLI、IDE 和桌面端
rampart setup codex
rampart verify codex

# Claude Code
rampart setup claude-code

# Cline
rampart setup cline
rampart verify cline

# OpenClaw
rampart protect openclaw

安装后，建议先检查整体状态：

rampart verify --all
rampart doctor

再用不会真正执行命令的测试功能验证策略：

rampart test "rm -rf /"
rampart test "git status"

这里不要把“支持多个 Agent”理解为每个平台表现完全相同。

根据官方支持矩阵，Codex、Claude Code、Cline 主要走原生 Hook；OpenClaw 当前推荐走托管原生 Guard。它们在审批界面、服务依赖、响应扫描和故障时的行为上都有差异。

例如 Codex 的本地允许/拒绝不要求 rampart serve 持续运行，但 ask 所需的外部审批队列依赖服务；OpenClaw 的推荐保护路径则需要本地服务参与策略判断。

真正接入前，应该按你使用的平台核对支持矩阵，而不是只跑完安装命令就默认所有边界都已覆盖。

它不是沙箱，这一点必须讲清楚

Rampart 官方把自己定义为策略执行层，而不是系统沙箱、虚拟机或网络防火墙。

它检查的是 Agent 框架交给它的工具调用元数据，不是操作系统的每一次系统调用和网络数据包。

这意味着它有几类明确边界。

第一，没有经过 Rampart 的调用，它就看不见。

不同接入路径覆盖的工具不同。如果某个 Agent 或插件没有把文件、网络或工具调用交给 Rampart，规则就无法生效。

第二，放行一个进程，不等于看清进程内部所有行为。

如果策略允许执行 python3 script.py，Rampart 能看到的是启动脚本这件事，未必知道脚本内部每一步做了什么。官方提供 preload 等补充路径去拦截部分子进程，但也明确说明覆盖范围依接入方式和平台而异。

第三，策略质量决定保护质量。

标准配置默认是 deny-on-match：命中危险规则才拒绝，其他操作继续执行。对高安全环境，官方建议使用 paranoid 一类默认拒绝、显式放行的配置，而不是只依赖黑名单。

第四，它防的是失误、幻觉和提示注入驱动的越界，不是已经入侵系统的专业攻击者。

如果攻击者已经拿到同一用户的 Shell 权限，用户态工具本身也可能被停止、替换或绕过。生产环境仍然需要最小权限、不同用户隔离、容器或虚拟机、网络分段和凭证管理。

所以更准确的理解是：Rampart 像安全带，不是防滚架。

它适合和沙箱组合，而不是替代沙箱。

谁适合尝试？

比较适合：

  • 每天重度使用 Codex、Claude Code、Cline 或 OpenClaw；
  • 已经允许 Agent 执行命令、读写文件或调用 MCP；
  • 希望把权限规则随项目版本管理；
  • 团队需要审计 Agent 做过什么、为什么被拦截；
  • 有生产部署、云资源、数据库等高风险工具需要人工批准。

不太适合：

  • Agent 只在隔离的临时容器里运行，且没有任何真实凭证；
  • 只使用聊天功能，从不开放工具权限；
  • 希望装一个工具就获得完整系统级隔离；
  • 不愿意维护规则，也不准备检查误拦截和漏拦截；
  • 需要成熟商业产品的 SLA、集中管理与正式合规承诺。

项目目前只有约 79 个 GitHub Star，功能更新很快，集成矩阵也在持续变化。它值得关注，但还不应该仅凭一篇介绍就直接接进关键生产流程。

本文基于项目仓库与官方文档整理，没有在本机把 Rampart 接入真实 Agent 环境。正式使用前，建议先在隔离测试目录里验证文件读取、无害模拟命令和人工审批三条路径。

小结

AI Agent 的权限问题，不能永远靠“相信模型会听话”，也不能把所有判断都塞进连续弹出的确认框。

Rampart 最值得关注的地方，是把权限边界变成了可执行、可审计、可版本管理的本地策略。

允许什么、拒绝什么、什么必须找人，不再由 Agent 自己解释。

对于已经让 Codex、Claude Code 或 OpenClaw 接触真实代码、凭证和部署环境的人，我建议至少了解一下这类策略层，并从标准配置和测试命令开始试。

但如果你的目标是对不可信代码做强隔离，容器、虚拟机、独立用户和网络控制仍然不能省。

Rampart 解决的是“看得见的工具调用该不该执行”，不是“系统里发生的一切都能被它控制”。

这个边界讲清楚以后，它才是一个值得使用的开源安全工具，而不是又一个“装上就安全”的口号。

项目地址

  • GitHub：https://github.com/peg/rampart
  • 官方文档：https://docs.rampart.sh/
  • 支持矩阵：https://docs.rampart.sh/getting-started/support-matrix/
  • 威胁模型：https://docs.rampart.sh/reference/threat-model/