- 它可能把本地内容发送到一个外部域名；
- 它可能在错误的环境执行数据库或部署命令；- 它可能调用名称含糊、权限却很大的 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 用户可以先用：
```bash
brew install peg/tap/rampartrampart quickstart
````quickstart` 会检测当前环境里可接入的 Agent，选择对应保护路径并做验证。也可以单独配置：```bash# Codex CLI、IDE 和桌面端
rampart setup codexrampart verify codex
# Claude Code
rampart setup claude-code# Clinerampart setup cline
rampart verify cline# OpenClawrampart protect openclaw
```安装后，建议先检查整体状态：```bashrampart verify --all
rampart doctor```
再用不会真正执行命令的测试功能验证策略：
```bash
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/
","createTime":1786594889,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,
