How do you know this agent hasn't been talked into it?
It is the question everyone who hands money to an AI eventually asks. Our answer may not be the one you expect:
We do not try to judge whether its thinking is clean.
Because that cannot be done, and cannot be shown. Whether a model was nudged off course by a sentence hidden in a web page is not something you can open its head and check; any product claiming otherwise is selling you a statement you cannot verify.
So we stand somewhere else: we put the boundary outside its reasoning. An agent can be persuaded to do anything, but it cannot persuade a spending ceiling it has no reach over, or rewrite a payee list it has no authority to touch. If it wants to send $50,000 and the ceiling is $500, the answer is $500 — however good its reasons sound.
In 2016 attackers used stolen credentials to move $81 million out of Bangladesh Bank. SWIFT's response was not to guess which terminal had been compromised — it published a control baseline, required every member to attest against it, and made each member's attestation visible to counterparties before they transacted. Those three moves are the three layers below.
The RAP (Responsible Agentic Payments) framework →A control list written down plainly
17 controls, 10 of them mandatory. Each one is answerable yes or no, with no room to explain — because a list that leaves room to explain ends up being one that everybody claims to meet.
Attest control by control, and get a verifiable receipt
Report what you actually do. You can file with gaps — declare them, and say how you plan to close them. Make attestation a test only a perfect score can pass, and you get no filings, or dishonest ones.
The counterparty can look you up before paying
This layer is what makes the other two matter. However good the list and however careful the attestation, if the payer cannot see it before paying, it is a document that talks only to itself.
What we can prove, and what is only a claim
This distinction is the most important thing in the baseline. Some controls run at our gateway on every single payment, and we can produce the record. Others are about what the counterparty does on their own side, where all we hold is their statement. Presenting the two as one would be passing someone's claim off as our verification — so every control below is colour-coded, and the lookup API returns the two sets separately.
Identity & attribution
Every payment traces back to a specific accountable party, not merely “some agent”.
ACB-1.1Every paying agent is attributed to a registered party
Without attribution, after an incident you cannot even say whom to go to — let alone claw back or revoke.
ACB-1.2Agent identity is proven, not merely claimed
Accepting an agentId without a credential lets anyone impersonate another agent — which nullifies attribution entirely.
ACB-1.3The accountable party has passed third-party identity verification (KYC/KYB)
A self-typed entity name can be any string. For attribution to hold up legally, the party itself must have been verified.
Mandate boundary
How much it may spend, to whom, and for what — written down where the agent cannot reach.
ACB-2.1A per-payment ceiling is set
The most direct way to monetise a prompt injection is a single transfer of everything. A per-payment ceiling caps the worst case at a number you can absorb.
ACB-2.2A daily cumulative ceiling is set
With only a per-payment cap, an attacker splits the theft into a hundred small ones. The cumulative cap governs the total.
ACB-2.3A payee allowlist is in place
Ceilings govern how much, not to whom. An allowlist means a compromised agent cannot reach the attacker's address even within its limits.
ACB-2.4Payment purpose is matched against the mandate
Amount and payee both fine, purpose entirely unrelated — that is the most characteristic trace a prompt injection leaves.
Enforcement point
The boundary is not an instruction in a prompt; it is a checkpoint the agent cannot talk its way past.
ACB-3.1The boundary is enforced outside the agent's reasoning
This is the core of the whole baseline. “Never exceed $100” written in a system prompt is a sentence that can be argued with; the same rule at the gateway is not. Any limit the agent can rewrite, bypass, or explain its way around is not a control.
ACB-3.2The payee is screened for compliance before settlement
Once funds are on-chain they do not come back. Screening has to happen before settlement, not during reconciliation afterwards.
ACB-3.3Replay and double-spend are prevented
A request that passed every check will pass again on replay, each time “legitimately”. The control point has to remember it already approved that payment.
ACB-3.4The same rules are also written into an on-chain policy contract
When an agent settles directly on-chain it does not pass the gateway. For the boundary to hold on that rail too, the rules must be enforced on-chain — where anyone can verify them.
Observability & audit trail
After an incident you can reconstruct what happened — and the agent did not author that record.
ACB-4.1Both approvals and blocks leave a non-repudiable record
Logging only blocks leaves you unable to explain why a given payment was let through. And the record must not be authored by the agent — a compromised agent will compromise its own log too.
ACB-4.2Verdicts can be verified by a third party
“We screened it” is a claim. A verifiable attestation lets the counterparty, an auditor or a regulator confirm it themselves rather than take your word.
ACB-4.3Someone actually watches for anomalies
Every control shares one precondition: somebody notices when it fires. An alert nobody reads is not an alert.
Revocation & incident response
When something looks wrong there is a stop button that takes effect now, not at the next deploy.
ACB-5.1A mandate can be revoked with immediate effect
When an agent goes wrong you need it stopped now, not at the next deploy. Revocation has to take effect before the next payment.
ACB-5.2Credentials are rotatable, and rotation actually happens
Credential leaks are a when, not an if. Being able to rotate is what makes a leak an incident rather than an ending.
ACB-5.3Large payments are held for human approval
Not everything should be fully autonomous. Above a chosen amount, have a human look — that look costs far less than one wrong payment.
How to use it
I run an agent and want to attest
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"}'I am about to pay and want to check the other side
curl "https://oceanalt.com/api/baseline/lookup?entity=Acme%20Robotics%20Ltd" # or ask for it inside the payment decision curl "https://oceanalt.com/api/decide?to=0x…&counterparty=acme-robotics-ltd"
Meeting this baseline is not compliance, not a licence, and not safety. What it lowers is the ceiling on how much damage a persuaded agent can do — it does not promise nothing goes wrong. Items marked as self-attested have not been verified by OceanAlt.