AI 编码 Agent 执行命令前，怎样先系好安全带？Paveo 用策略拦截危险操作
AI 编码 Agent 能执行 shell 命令、改写文件，效率很高；但一旦提示注入或错误计划让它执行 rm -rf、强制推送，损失也可能直接落到开发者的工作区。常见的事后审计只能告诉你发生了什么，Paveo 选择在工具调用前加一道策略检查：命令或文件写入先交给本地 hook 判断，拒绝时把原因返回给 Agent，并将决策写入可验证的审计记录。
Paveo 是 Apache-2.0 许可的 Python 项目，支持 Claude Code、Codex 和 Cursor 的编码 Agent 防护，也提供供自建 Agent 使用的策略 API。它强调本地运行、不向外发送数据；不过要准确理解它的边界：README 将其称为“安全带”，不是沙箱。基于模式和策略的拦截不能替代操作系统隔离、最小权限账户或容器边界。
先从现有项目安装并试跑
项目要求 Python 3.11 或更新版本。可以在项目目录创建独立环境，再安装并初始化 Claude Code hook：
python3 -m venv ~/.paveo ~/.paveo/bin/pip install paveo cd /your/project ~/.paveo/bin/paveo init claude-code
README 还列出 init codex 与 init cursor。初始化会写入对应配置，并测试刚生成的 hook；不要把“命令执行成功”直接等同于策略一定适合团队，仍应检查配置路径、规则范围和 Agent 实际调用行为。若希望先检查已有 Claude Code hooks，文档提供 paveo doctor；要回放已有 Claude Code 会话是否会触发策略，可使用 paveo replay claude-code。这两项的覆盖对象和适配状态应以项目文档为准。
策略重点：不只看命令字符串
Paveo 的策略文件可规定 Agent 可调用哪些工具、工具参数约束、调用顺序、频率限制，以及允许使用的模型和预算。例如退款 Agent 可以被限制只能调用 lookup_order 与 refund，并要求退款前对同一个订单执行过查询；金额还可设置上限。如此一来，策略描述的是“允许做什么”，而不只是黑名单命令。
自建 Agent 可以在调用实际工具前先检查请求，拒绝时把安全原因作为工具结果交回模型：
from paveo import Paveo, PolicyDenied
with Paveo.from_file("paveo.json", audit_path="audit.jsonl") as pf:
with pf.session(agent_id="refund-bot", principal="user_123") as session:
try:
session.check_tool("lookup_order", {"order_id": "A-104"})
except PolicyDenied as denied:
result = denied.for_model
else:
result = lookup_order("A-104")
示例中的 lookup_order 是应用自己的业务函数，不是 Paveo 内置工具。实际集成时要保证检查与执行的参数完全一致，并妥善管理策略文件和审计日志。对于预算管理，Paveo 也提供模型调用检查接口；README 指出部分输入（例如图片、音频、视频、文件或无法定价的请求）无法可靠估算成本时会拒绝放行，这比假装所有请求都可计价更安全。
先观察，再逐步执行
策略可采用 shadow 模式：会记录原本会拒绝的调用，但仍让调用通过，便于先发现误报；模型预算限制并不会因此变成影子模式。团队部署则可参考仓库的 rollout 文档，理解 hook 的托管方式及其未覆盖的边界。不要一开始就把宽泛规则应用到所有开发者机器；建议用测试仓库验证高危命令、正常构建流程、拒绝反馈和审计链，再逐步扩展。
还要牢记：如果 Agent 有能力修改保护自身的策略、hook 或运行环境，纯软件规则可能被绕开。Paveo 的文档讨论了加强配置所有权的团队部署方案，但它仍不能限制 Agent 通过其他未纳入检查的入口做事。对高风险工作，应组合使用专用凭据、最小权限、隔离工作区和人工审批。
Paveo 的价值不在于保证 Agent 永不犯错，而是把关键动作变成可审查的策略决策，并在执行前给出拒绝机会。把它视作纵深防御的一层，再用真实工作流测试其覆盖范围，才是稳妥的落地方式。