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