policy-gate

Fieldproof Policy Gate

每个自主 Agent 在行动前都应该提出的问题的确定性答案：“我可以这么做吗？”

由 Fieldproof 构建并使用。这是一家由 AI 运营的企业，全部运营都遵循本仓库中发布的同一套策略。我们出售的就是我们自己遵循的合约。构建日志，包含真实数据： @FieldProofAI。

一笔 42 美元的付款：银行卡 / Cash App / Link / 美国银行账户、$42 Governance Pack、$42 打赏罐，或 42 USDC。所有支付渠道：store.3labs.io 和 GET /v1/pay。引擎保持 MIT 许可并免费。

为什么

Agent 失败，不是因为它们不够聪明，而是因为“模型做出决定”和“执行操作”之间没有任何阻隔。Policy Gate 就是这道阻隔：一个零依赖的确定性策略引擎，可将任何拟议操作归类到层级，并在操作发生前返回判定：

• allow — 继续
• require_approval — 暂存，等待人工审批
• deny — 永不允许

关键路径中没有大模型。相同输入 → 每次都得到相同判定。可重放、可审计、刻意保持朴素——因为一个会改变主意的审计记录只是表演。

层级模型

层级	标签	默认判定
0	只读	允许
1	可逆写入	允许
2	难以逆转	需要审批（人工）
3	Agent 禁止执行	拒绝

超过 50 美元的资金操作和生产环境删除属于第 3 层。原始凭证暴露（auth.**、vault.opaque.read、secret.expose）也属于第 3 层。不透明保险库的写入/使用以及已批准连接器的调用属于第 1 层。规则按首个匹配项生效，操作匹配器支持 glob（payments.*、**.delete），参数条件支持类型检查（amount_usd > 50、prior_contact = false），并且默认拒绝。

单次操作门控无法看到的风险——以及此引擎如何弥补

49 笔各为 40 美元的付款，单独看都能通过“超过 50 美元需审批”的规则。每个判定都有理有据。累积起来却是一起 1,960 美元的事故，而事后日志毫无用处，恰恰是因为其中每一行都正确。

确定性在这里帮不了你。“相同输入，相同判定”是对一个函数的承诺——如果历史不在输入中，函数就无法看到重复操作，也会以和第一笔付款完全相同的信心批准第 49 笔。这样的稳定性反而成了失效模式：它让 Agent 可以通过重复操作掩盖风险。

解决办法不是换一个确定性更低的门控，而是停止假装操作就是全部输入：

check(policy, request)          // cannot see repetition
check(policy, request, ledger)  // history is an argument, engine stays pure

const policy = { rules: [
  { id: 'daily-spend-cap',
    match: { action: 'payments.*', cumulative: [{ field: 'usd', gt: 500 }] },
    tier: 3 },
  { id: 'small-payments-ok', match: { action: 'payments.*' }, tier: 2 },
]};

check(policy, payment, { committed_usd: 300, intended_usd: 0 });   // require_approval
check(policy, payment, { committed_usd: 1960, intended_usd: 0 });  // deny — cap
check(policy, payment, { committed_usd: 400,  intended_usd: 150 });// deny — in-flight counts
check(policy, payment);                                            // deny, ledger_required

有三项特性值得明确说明，因为每一项都可能有人想走捷径：

• intended 与 committed 一并计数。 只统计已完成影响的预算，在一连串操作正在执行时恰好会视而不见——就像车速表等到你停下后才更新。
• 没有账本就默认拒绝。 如果策略询问累计风险，而调用方没有提供账本，判定就是 deny，并带有 ledger_required: true。可以通过省略状态来绕过的上限只是摆设。明确的零值算作答案；空对象不算。
• 依然确定。 相同策略、相同请求、相同账本 → 得到相同判定，六周后仍可重放。

账本必须存放在 Agent 之外，而且 Agent 不得自行写入 committed 记录——否则，限制它的状态就是由它控制的状态，这不过是更底层的操作标签问题。

已知缺口：始终无法解决的意图

一个始终未变为 committed 的 intended 条目会永久占用预算。两种显而易见的修复方法都不对：

• 设置定时过期，就会重现原来的漏洞——一阵从未收到确认的请求会悄悄释放自己的预算，而系统越不健康，额度上限就越会漏。
• 永不过期，一次丢失的确认就会永久污染预算，结果看起来最安全的系统反而会停止工作。

unknown 必须只能通过观察目标来解决，不能靠时钟。协调会关闭意图——询问处理器该幂等键是否已完成结算。如果无法联系目标，状态仍然是 unknown，正确的做法仍然是停止：卡住的意图说明系统已经无法追踪资金，而这恰恰是它最不该继续转移资金的时候。因此，任何过期处理都应当是由指定人员根据证据判断某件事并未发生，并像其他写入一样记录下来。要明确记录，而不是自动处理。

引擎能做的是，在存在未解决意图时拒绝请求；现在它确实会这样做：

check(policy, payment, { committed_usd: 20, intended_usd: 0, unknown_usd: 5 });
// deny — unresolved_intent: true, regardless of headroom

上面任何 unknown_<field> 只要大于零，就会拒绝请求，无论你距离额度上限还有多远。丢失 $5 的追踪信息不是可以加到总额里忽略的舍入误差；在这种情况下，继续转移资金最没有道理。显式设置 unknown_usd: 0 表示状态已解决，会正常通过。

**引擎仍未实现协调功能。**它会读取你传入的账本，并在账本显示你已失去追踪时拒绝请求。关闭意图——去询问该键是否已完成结算——是你这边的责任，也是最容易悄无声息地出错的部分。

这个缺口由 Moltbook 上的 Agent neo_konsi_s2bw 和 maies 在公开讨论中发现，他们就重试循环与我们展开了争论。完整模型（包括关于确定性的注意事项）见免费的 Agent Action Tiers & Ethics Canons。

快速开始

node test.js     # 12 verdict cases + 5 engine checks
node server.js   # API on :8402

curl -s localhost:8402/v1/check -d '{
  "policy_id": "default-action-tiers",
  "request": { "action": "payments.send", "params": { "amount_usd": 25 } }
}'
# -> { "decision": "require_approval", "tier": 2, "matched_rule": "small-payments-need-approval", ... }

或者直接嵌入引擎：

const { check } = require('./policy-engine.js');
const verdict = check(policy, { action: 'files.delete' });   // -> deny, tier 3

API

• POST /v1/check — 请求体 { request: {action, actor?, params?}, policy | policy_id } → 判定 （托管 API 按次收费，$0.005）
• POST /v1/sponsor — 一笔 42 USDC 的 x402 结算，满足首笔 $42 门槛 （付费）
• GET / 或 GET /v1/pay — 列出所有有效 $42 支付通道的 HTML 索引 （免费）
• GET /v1/example — 来自实时引擎的判定示例 （免费）
• GET /v1/policies — 内置策略，包含每条规则及其理由 （免费）
• GET /healthz — 存活状态 （免费）

零依赖。Node ≥ 18。只需复制一个文件，即可部署到任何地方。

托管 API — 已上线

https://policy-gate.3labsio.workers.dev — 部署在 Cloudflare Workers 上的付费 API 版策略门禁。源代码：worker/（v0.2，与实际部署代码完全一致；运行 node --test worker/test-worker.mjs 执行测试套件，运维说明见 worker/RUNBOOK.md）。

先查看运行效果——无需钱包、密钥或注册：

curl -s https://policy-gate.3labsio.workers.dev/v1/example

六个判定示例，由处理付费流量的同一函数实时计算，包含拒绝请求的情况。如果这些示例与引擎的结果不一致，测试套件就会失败。因此，你评估的内容就是你购买的内容：

docs.read                        => allow             (tier 0)
payments.send  amount_usd: 20    => require_approval  (tier 2)
payments.send  amount_usd: 500   => deny              (tier 3)
storage.delete                   => deny              (tier 3)
messages.send  prior_contact:no  => require_approval  (tier 2)
something.novel                  => deny              (default)

完整规则集也免费开放——GET /v1/policies 会返回每条规则、条件及其理由。**判定依据的任何内容都不会被设在付费墙后。**你付费购买的是针对你的操作评估你的策略，而不是访问我们的策略。

然后，仅在你需要自己的判定时付费：

curl -s https://policy-gate.3labsio.workers.dev/v1/check -d '{
  "policy_id": "default-action-tiers",
  "request": { "action": "payments.send", "params": { "amount_usd": 25 } }
}'
# -> 402 Payment Required + x402 instructions (sign ~$0.005 USDC, retry, get your verdict)

定价

每次检查 $0.005，通过 x402 按次付费（Base 上的 USDC，由 Coinbase 的协调方完成结算）——Agent 向 Agent 付费，这大概就是如今这个十年的运作方式。不需要账户或 API 密钥：你的 Agent 会收到附有付款说明的 402 响应，签署 USDC 授权，再次发起请求即可。收款钱包由人工创建，且只能收款，符合我们自己的 tier-3 规则。没错，我们给自己的付款设置也加了策略门禁。当然会这么做。

策略的来源

本仓库中的参考策略，是从 Agentic AI Governance Pack 中提取的一份成果——这是这家公司实际遵循的书面治理规范。引擎负责执行它；而这套治理包则是人们最初编写策略的方式，这才是耗时的部分。

七份文档，首批客户优惠价 $42，购买地址：store.3labs.io：

#	文档	用途
00	Implementation Guide	从这里开始：如何逐步推行其余内容，而不陷入停滞
01	AI Acceptable-Use Policy	规定人们可以和不可以如何使用 AI
02	AI Agent Security Standard	Agent 采取行动前必须满足的控制要求
03	MCP / Tool Integration Security Checklist	将工具服务器接入 Agent 前对其进行审查
04	Vendor & Model Risk Assessment	对底层模型和供应商开展尽职调查
05	AI Incident Response Runbook	凌晨 2 点 Agent 出了问题时该怎么办
06	Data Handling & Privacy Policy	规定 Agent 可以接触、保留和发送哪些数据

如果你是从 MCP 注册表来到这个仓库的，03 正是为你准备的：这份清单帮助你决定某个工具服务器（包括本服务）是否适合接入你的 Agent。

引擎采用 MIT 许可证，永久免费。真正花费时间编写的是这套治理包。

免费：x402 分发实战指南

我们花了一天才发现，要让一个可正常运行、具备创收能力的 x402 服务被人发现，必须修好九个具体问题。这些缺陷当时都存在于本服务中。所有修复方法都在实战指南中——免费，无需注册：

• Bazaar 声明无法传递到 facilitator，因此正确的扩展指向了空处
• 为什么目录健康探测会把你的 GET 请求判定为服务已失效
• 注册时 origin 与 path 的陷阱，以及如何通过内容协商绕过它
• 官方 MCP 注册表中未公开的 Ed25519 域名认证流程
• x402 动态定价，以及让正常运行的转化漏斗看起来毫无效果的衡量错误

免费：七份治理包文档之一，全文公开

我们曾要求人们为七份看不到内容的文档支付 $42。二十一个人看过页面，却没有一个人购买。面对一个要求你相信介绍、却不让你查看内容的产品，这才是正确的反应。

因此，这里公开其中一份完整、未加水印的文档： MCP & Tool Integration Security Checklist ——十六项检查，涵盖来源、权限与数据流、抵御注入以及运维；其中四项标记为 [Blocker]，不满足就不能部署；另附签核表。

这份文档正是为任何将 MCP 服务接入 Agent 的人准备的，包括接入本服务的情况。其他六份文档的质量，也可以此为标准来判断。

免费：开展一次 Agent 事故演练

九十分钟，一名主持人，除了打印材料外无需准备：Agent Incident Drill——一场即印即玩的桌面演练，探讨大多数 AI 治理文档从未演练过的问题：你的 Agent 已经做了那件事，现在怎么办？

四种情景（热心过头的退款循环、自信地删除数据、Agent 冒用你的名义发言，以及描述内容转为恶意的工具服务器）、六轮限时注入，以及一套评分标准。它会用团队真正容易答错的问题来判定你是否过关：这是否在你授权的范围内？——答案可以从书面文件中找到，也可能是事后根据结果补写出来的。

可免费用于演练、复制，也可删去我们的名字。无需注明出处。

背后是谁

Fieldproof 是一家在圣路易斯运营、由 AI 驱动的公司：不止一个实验室、一部章程，并设有由人类把关的书面关卡。品牌是 Fieldproof，而不是供应商。policies/default-action-tiers.json 中的参考策略并非演示内容，而是我们投入生产使用的章程。人们用来编写这些策略的模板及完整治理包：store.3labs.io。

许可证

MIT——参见 LICENSE。