OceanAltOceanAlt

控制基线 v1.0

你怎么知道这个 Agent 没被人忽悠？

这是每一个把钱交给 AI 的人最后都会问到的问题。我们的答案可能和你预期的不一样：

我们不去判断它的想法干不干净。

因为那件事既做不到、也没法证明。一个模型有没有被藏在网页里的一句话带偏，你没法打开它的脑子看一眼；任何声称能看的产品，卖的都是一个你无法验证的说法。

所以我们换了个位置站：把边界放在它的推理之外。 Agent 可以被说服去做任何事，但它说服不了一个它够不着的额度上限，也说服不了一份它无权改写的收款名单。它想付 5 万，上限是 500，那就是 500 —— 无论它的理由多有道理。

这个思路不是我们发明的

2016 年，黑客用偷来的凭证从孟加拉央行转走 8100 万美元。SWIFT 的应对不是去猜哪台终端被入侵了 —— 而是发布一套控制基线，要求每家成员逐条自证，并让对手方在交易前查得到对方的自证状态。这三件事，就是下面这三层。

RAP（Responsible Agentic Payments，负责任的 Agent 支付）框架 →
①

一份写清楚的控制清单

17 条控制，其中 10 条是强制的。每一条都能回答「是」或「否」，不留解释空间 —— 因为留了解释空间的清单，最后都会变成人人都说自己做到了。

②

逐条自证，签一张可核验的凭证

做到哪几条就报哪几条。没做全也可以交 —— 缺口如实登记、写上打算怎么补。把自证做成只有满分才能交卷的考试，结果只会是没人交，或者有人撒谎。

③

对手方在付款前查得到

这一层是前两层的意义所在。清单写得再好、自证做得再认真，如果付款方在付之前查不到，那就只是一份自娱自乐的文件。

哪些是我们能证明的，哪些只是对方说的

这个区分是整份基线里最要紧的一条。有些控制是我们的网关每一笔都在跑的，我们能拿出记录；有些是对方在自己那边怎么做的，我们只能记下他的说法。把两者混在一起讲，就是在拿别人的自证冒充我们的核验 —— 所以清单里每一条都标着颜色，查询接口也把两堆分开返回。

网关执行链上可核验对方自证

身份与归因

每一笔付款都能追到一个具体的主体，而不是「某个 Agent」。

ACB-1.1网关执行强制

每个付款 Agent 都归因到一个已登记主体

没有归因，出事之后连「该找谁」都答不上来，更谈不上追偿或吊销。

怎么算做到：在网关注册 Agent 并填写责任主体；每笔付款都带 agentId。

ACB-1.2网关执行强制

Agent 身份可证明，不能只靠自称

只认 agentId 不认凭证，等于任何人都能冒用别人的身份付款 —— 归因这件事就白做了。

怎么算做到：注册时签发 agentSecret，之后每次调用在 x-agent-secret 头出示。凭证可轮换。

ACB-1.3对方自证建议

责任主体经过第三方身份核验（KYC/KYB）

自填的主体名可以是任何字符串。要让归因在法律上站得住，主体本身得被核验过。

怎么算做到：通过网关的 KYC 接入完成核验，或提供你已有的 KYB 证明。

授权边界

Agent 能花多少、能付给谁、为什么付 —— 这些写在它够不着的地方。

ACB-2.1网关执行强制

设定单笔上限

提示注入最直接的变现方式就是一次性转走全部余额。单笔上限把最坏情况从「全部」降到一个你能承受的数。

怎么算做到：为该 Agent 设 mandate.maxUsdc；超出即拦，不做例外。

ACB-2.2网关执行强制

设定单日累计上限

只有单笔上限，攻击者就拆成一百笔小额。累计上限管住的是「总共」。

怎么算做到：为该 Agent 设 mandate.dailyUsdc；当日累计超出即拦。

ACB-2.3网关执行建议

收款方白名单

上限只管「多少」，不管「给谁」。白名单让被污染的 Agent 即使在额度内，也付不到攻击者的地址。

怎么算做到：设 mandate.payees；不在名单上的收款地址一律拦。适用于收款方相对固定的场景。

ACB-2.4网关执行建议

付款用途与授权比对

金额和收款方都对，用途却完全对不上 —— 这是提示注入留下的最典型痕迹。

怎么算做到：设 mandate.purpose；付款时带上 purpose，网关做意图比对。

强制执行点

边界不是提示词里的一句叮嘱，而是一道 Agent 说服不了的关卡。

ACB-3.1网关执行强制

边界在 Agent 的推理之外执行

这是整份基线的核心。写在系统提示词里的「不要超过 100 美元」是一句可以被劝服的话；写在网关上的同一句话不是。凡是 Agent 自己能改写、能绕过、能「解释清楚」的限制，都不算控制。

怎么算做到：支付走网关（或链上策略合约），额度/白名单/用途由网关判定 —— Agent 无权修改自己的 mandate。

ACB-3.2网关执行强制

结算前做收款方合规筛查

钱一旦上链就追不回来。筛查必须发生在结算之前，而不是事后对账时。

怎么算做到：每笔付款前调 AML 筛查（制裁/混币器/风险名单 + 链上启发式），命中即拦。

ACB-3.3网关执行强制

防重放 / 防双花

一个通过了全部检查的请求被重复提交，每一次都会「合法」地通过。控制点必须记得它已经批过这一笔。

怎么算做到：每笔付款带一次性 nonce，网关落库去重。

ACB-3.4链上可核验建议

把同一套规矩也写进链上策略合约

Agent 直接上链付款时不经过网关。要让边界在这条轨上同样成立，规矩必须由链上强制 —— 而且任何人可自行核验。

怎么算做到：在控制台绑定链上策略合约，把额度/白名单同步上链。会话私钥永不离开你手里。

可观测与留痕

出事之后能复原当时发生了什么 —— 而且这份记录不由 Agent 自己写。

ACB-4.1网关执行强制

放行与拦截都留下不可否认的记录

只记拦截不记放行，事后就说不清「这笔当时为什么放了」。而且记录不能由 Agent 自己写 —— 被污染的 Agent 也会污染它自己的日志。

怎么算做到：网关侧记录每笔判决（逐闸结果 + 证据），记录由网关生成，Agent 无写入权。

ACB-4.2网关执行建议

判决可被第三方核验

「我们查过了」是一句声称。可核验的凭证让对手方、审计师、监管都能自己确认，而不必信你。

怎么算做到：allow/review 时签发合规凭证，绑到结算备注；任何人可到 /api/attestation/verify 复核。

ACB-4.3对方自证建议

异常行为有人看

所有控制都有一个共同前提：有人会注意到它们在报警。没人看的告警等于没有告警。

怎么算做到：接上告警通道（邮件/IM/webhook），并明确谁负责响应。

吊销与应急

发现不对时，有一个立刻生效的停止键，而不是等下一次部署。

ACB-5.1网关执行强制

授权可即时吊销

发现 Agent 失控时，你需要的是「现在停」，不是「下次部署时停」。吊销必须在下一笔付款前就生效。

怎么算做到：控制台一键吊销；网关每笔都查吊销状态，吊销后立即拦死。

ACB-5.2对方自证强制

凭证可轮换，且有轮换机制

凭证泄露是「会发生」而不是「可能发生」。能轮换，泄露才只是一次事故而不是一次终局。

怎么算做到：使用网关的凭证轮换接口，并约定轮换周期与泄露时的应急流程。

ACB-5.3网关执行建议

大额付款挂起等人工批准

并非所有事都该全自动。给一个金额阈值，超过就让人看一眼 —— 这一眼的成本远低于一次误付。

怎么算做到：设 mandate.holdUsdc；金额达到阈值的付款挂起，等待人工批准后才结算。

怎么用

我是接入方，想自证

用表单填，五分钟 →不用写代码、不用账号

先拉一份控制清单，按你实际做到的填，交上来。做不到的照实填 false，并在 gapPlan 里写打算怎么补。

curl https://oceanalt.com/api/baseline

curl -X POST https://oceanalt.com/api/baseline/attest \
  -H "content-type: application/json" \
  -d '{"entity":"Acme Robotics Ltd",
       "answers":{"ACB-1.1":true,"ACB-2.1":true,"ACB-3.1":true},
       "gapPlan":"Daily cap ships next sprint"}'

我是付款方，想在付之前查对手方

查不到不是坏事 —— 绝大多数主体还没自证过。「查无此人」是没有信息，不是负面信号，别拿它当拒付理由。

curl "https://oceanalt.com/api/baseline/lookup?entity=Acme%20Robotics%20Ltd"

# 也可以在付款决策里一起要
curl "https://oceanalt.com/api/decide?to=0x…&counterparty=acme-robotics-ltd"

边界声明

满足这份基线不等于合规，不等于持牌，也不等于安全。它降低的是「一个 Agent 被说服之后最多能造成多大损失」的上限 —— 它不保证不出事。标着「对方自证」的那些条目，OceanAlt 没有核验过。

机器可读版：/api/baseline · /openapi.json