Codex、Claude Code 能直接操作电脑后，如何限制权限？

先说结论：如果你已经允许 Codex、Claude Code、Cline 或 OpenClaw 在真实电脑上执行命令、读写文件和调用 MCP，仅靠提示词约束与逐次确认，已经很难构成稳定的安全边界。

一个更实际的办法，是在 Agent 与工具之间增加独立的策略执行层。

采用 Apache-2.0 许可证的开源项目 Rampart，做的正是这件事。它会在宿主执行工具调用之前，根据本地 YAML 规则决定允许、拒绝、观察或请求人工批准，并把经过它的决策写入可校验的审计记录。

Rampart 不是沙箱，也不能观察电脑里发生的所有行为。但对于 AI Agent 最常见的几类风险——误删文件、读取凭证、错误部署、调用危险 MCP 工具，以及提示注入诱导的越界操作——它提供了一个比“希望模型谨慎一点”更确定的控制位置。

为什么 Agent 权限正在变成一个独立问题？

传统聊天模型的主要风险，往往停留在回答错误。

工具型 Agent 的错误会被转化成操作。

当用户说“帮我修好这个项目”，Agent 可能自动完成一连串动作：读取仓库、搜索依赖、修改配置、执行测试、访问网页、调用数据库工具、提交代码，甚至触发部署。

这条链路越长，用户越不可能逐条理解和判断。

常见的权限控制方式有两种。

第一种是在系统提示词或项目说明里写下规则，例如“不要读取敏感文件”“不要修改生产环境”。这种方式有协助，但本质上仍由模型理解和遵守。一旦任务冲突、上下文丢失或遭遇提示注入，规则可能被错误解释。

第二种是对每个高权限操作弹出确认框。它把最终决定留给人，但也会制造审批疲劳。一个连续工作的 Agent 可能短时间产生几十次调用，用户很容易从“认真检查”退化为“继续、继续、全部允许”。

更麻烦的是，确认框往往只展示单次操作，无法自动表达团队长期规则。例如：

• 所有项目都禁止读取 ~/.ssh/；
• 当前仓库禁止直接推送主分支；
• 访问公司允许列表以外的域名需要拒绝；
• 任何生产部署都必须人工批准；
• 某个数据库 MCP 只允许查询，不允许删除。

这类要求更适合由独立策略引擎持续执行，而不是每次交给模型和用户临场判断。

Rampart 的机制：先检查工具调用，再决定是否执行

Rampart 位于 Agent 和外部工具之间。

在支持的接入路径里，Agent 即将执行的 Shell 命令、文件读写、网络请求或 MCP 调用，会先以元数据形式进入 Rampart。策略引擎根据工具类型和匹配条件作出决定，再把结果交还给宿主。

核心动作可以概括为四类：

决策结果典型用途allow正常执行并记录日常开发和已知安全操作deny执行前拒绝破坏性命令、读取密钥、危险外传watch允许执行但重点记录暂时观察、尚未形成强规则的行为ask暂停并请求人工批准部署、发布、权限提升和高风险变更

此外，Rampart 还支持 webhook，把选定的决策交给外部 HTTP 服务。

按照官方策略文档，多份策略同时命中时采用 deny-wins：deny 的优先级高于 webhook、ask、watch 和 allow。项目规则也只能增加限制，不能削弱全局策略。

这套机制的价值并不在 YAML 本身，而在于它把安全要求从“给模型看的提议”转换成“工具执行前必须经过的判断”。

它具体能检查哪些内容？

Rampart 当前公开文档列出的主要工具类型包括：

工具类型可检查内容execShell 命令字符串read文件读取路径write文件写入路径fetch请求域名MCP 工具工具类别、工具名及相关参数

因此，一套策略可以同时处理多类边界。

例如，标准配置会关注破坏性命令、SSH 私钥和 .env 等敏感路径，也可以对生产部署或未知 MCP 工具提出人工审批要求。

对于 MCP，Rampart 会按工具名称中的危险特征进行分类。官方文档举出的破坏性关键词包括 delete、destroy、remove 和 drop。标准配置会拒绝识别出的破坏性工具，并对危险或无法分类的工具要求批准。管理员还可以直接匹配完整 MCP 工具名，避免仅依赖关键词。

这种统一策略层的好处，是 Agent 接入多个工具后，不必完全依赖每个工具自己的权限提示。

但要注意，Rampart 只能检查集成实际交给它的调用。如果某类操作绕过了对应 Hook、插件或代理，它就无法凭空发现。

为什么“策略即代码”比连续弹窗更适合团队？

Rampart 的全局策略一般位于 ~/.rampart/policies/。项目还可以保存 .rampart/policy.yaml，把仓库特有要求跟随代码版本管理。

这样做带来几个直接变化。

一是规则可以被 Review。团队能明确看到新增了哪些限制，是否存在误拦截，谁修改了生产审批要求。

二是规则可以被测试。rampart test 可以在不实际执行目标命令的情况下查看决策，策略也可以进入 CI 流程。

三是规则可以回滚。相比某个人曾经点过一次“永远允许”，版本化文件更容易追踪和恢复。

四是环境差异可以显式表达。全局策略负责所有项目共同的底线，项目策略负责当前仓库的额外限制。

不过，项目策略文件本身也需要审查。官方威胁模型提议对不受信任的仓库保持警惕，并提供 RAMPART_NO_PROJECT_POLICY=1 跳过项目策略。Rampart 当前还通过 deny-wins 限制项目策略只能加严，不能放宽全局规则。

安装方式与最小验证流程

官方当前推荐的入门方式是安装后运行 rampart quickstart。macOS 可以使用 Homebrew：

brew install peg/tap/rampart
rampart quickstart

也可以使用官方安装脚本或 go install。从源码构建时，仓库当前说明需要 Go 1.25.12 以上版本。

如果希望明确配置某个平台，可以使用对应命令：

# 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"

rampart test 只测试策略判断，不执行传入命令，适合先确认危险命令会被拒绝、普通命令会按预期处理。

接下来可以在隔离目录中创建假的 .env，验证文件读取规则；再用无害的模拟部署命令验证 ask 路径。不要用真实凭证来证明安全工具能否保护凭证。

同样是“支持”，不同 Agent 的保护路径并不一样

Rampart 当前对 Codex、Claude Code、Cline、OpenClaw 等平台提供专门接入，但不能把“支持”理解成完全一样的能力。

根据官方支持矩阵：

• Claude Code 通过原生 Hook 接入，本地策略执行不强制依赖后台服务，原生审批提示可承接 ask；
• Codex CLI、IDE 和桌面端使用原生生命周期 Hook，本地允许和拒绝不依赖服务，但外部审批队列需要服务；
• Cline 也使用原生 Hook，但当前没有原生的暂停后继续审批界面，审批请求会以撤销并返回上下文的方式处理；
• OpenClaw 的推荐路径是 rampart protect openclaw 安装托管原生 Guard，需要本地服务参与策略判断，并配置更严格的故障行为；
• 其他命令行 Agent 可以使用 wrap，MCP Server 可以使用协议代理，但覆盖面与原生集成不同。

部署前应查阅当时版本的支持矩阵，确认三件事：哪些工具会经过策略层，rampart serve 是否必须运行，以及服务故障时是放行还是拒绝。

这比“能不能安装”重大得多。

Rampart 能替代沙箱吗？不能

这是评价 Rampart 时最重大的边界。

官方威胁模型明确写着：Rampart 是 AI Agent 工具调用的策略引擎，不是沙箱、虚拟机、Hypervisor 或完整网络防火墙。

它看到的是 Agent 框架报告的命令、路径、请求和工具参数，不是原始系统调用或网络数据包。

这会带来几类限制。

1. 放行命令后，未必能看见进程内部全部行为

如果 Agent 执行 python3 script.py，Rampart 第一检查的是这条启动命令。脚本内部读取什么、连接哪里，不必定都能通过同一边界观察。

项目提供 preload 等方式拦截部分子进程，但这种补充能力受操作系统、动态链接方式和接入路径影响，不能等同于系统级隔离。

2. 黑名单无法穷举所有绕过方式

标准策略默认是 deny-on-match，只有命中规则的危险行为会被拒绝。Shell 引号、变量展开、编码和新的工具形态，都可能增加匹配难度。

Rampart 会对命令做必定的规范化与拆分，但官方仍提议高安全环境使用默认拒绝、显式放行的 paranoid 思路，而不是把所有希望寄托在危险模式列表上。

3. 故障时放行还是拒绝，取决于集成

不同路径在服务不可用、Hook 超时或插件异常时的行为不同。有些路径继续本地执行允许/拒绝，有些审批会直接失败，还有些兼容路径需要额外配置才会 fail-closed。

因此，生产环境不仅要写规则，还要监控服务、验证接入状态，并定期重新检查升级后的覆盖证据。

4. 它主要防误操作和被诱导的 Agent

Rampart 针对的是 Agent 幻觉、上下文错误、提示注入和误选环境造成的危险工具调用。

如果一名攻击者已经拿到系统 Shell 权限，他可能直接停止服务、修改二进制或绕过用户态工具。此时仍需要独立用户、最小权限、容器或虚拟机、网络分段和凭证轮换。

Rampart 更像纵深防御中的一层，而不是所有安全措施的替代品。

它与常见方案应该怎样组合？

方案主要解决什么与 Rampart 的关系提示词规则告知模型应该怎样做成本低，但不构成确定执行边界Agent 原生确认框把单次高风险决定交给人适合临时判断，容易产生审批疲劳Rampart 策略层对宿主暴露的工具调用执行规则适合固定边界、审计与项目策略容器或虚拟机隔离文件、进程和系统资源提供更强隔离，与 Rampart 互补独立账号与最小权限限制凭证和操作系统权限即使策略被绕过，也能缩小损失范围网络控制限制能够连接的服务和出口弥补工具调用之外的网络边界

一个更稳妥的组合一般是：让 Agent 在受限用户或容器中运行，凭证只给最低权限；Rampart 再负责对可见工具调用做精细策略、审批与审计。

这样即使某一层失效，其他层仍能限制影响范围。