Your agents can ask. They cannot pay.
Enforcement and proof for delegated payment authority.
Agentic Terminal is a control that runs inside your infrastructure, between your AI systems and your payment rails. It holds the payment credential, checks every request against the delegated authority your payor signed, and refuses anything that authority does not cover.
Those AI systems are what the rest of this page calls agents, in the software sense, not insurance agents. They have no path to the credential, and neither do we. The delegated authority itself is a signed credential we call a mandate, and a request the mandate does not authorise produces no payment.
Not a warning. Not a log entry. No payment.
For your security team Check every claim on this page against a published artifact
For organisations that disburse other people's money: claims administrators, benefits and warranty administrators, fund administrators, managing general agents, escrow agents, outsourced accounts payable.
delegation v2.6 · 3 agents, 2 approvers
-
EXC-40118reconcile-02 decided, settle-01 paidattested 82,400.00 SWIFT · USD settled
-
EXC-40122reconcile-02 decided, settle-01 requestedattested 118,600.00 SWIFT · USD awaiting approval
-
EXC-40125settle-01 requested, no decision citednone 61,250.00 RTGS · USD no attestation
-
EXC-40131fx-break-03 decided today, 90,000 already drawnattested 340,000.00 SWIFT · USD per-item cap
- Principal
- did:web:ridgeway-bank.example
- Requesting agent
- ...:agents:settle-01
- Counterparty matched as
- registered correspondent
- Amount
- 118,600.00 USD
- Constraint breached
- escalationThreshold 100,000.00
- Remaining after approval
- 4,001,400.00 of 5,000,000.00
- Decisions under this mandate
- 14 in the last 24 hours
- Decided by
- ...:agents:reconcile-02
- Outcome
- resolve-and-settle
- Vocabulary
- v2, client-defined
- Policy applied
- RWM-EXC-2026.2 · sha256 7c1e...9b40
- Inputs digest
- a4f0...2dd8
- Decider's own record
- sha256 e91b...44c7
- Held by
- you, not by us
- Decider differs from principal
- yes, as the mandate requires
Supplied by the agent, not verifiedRoutine, pre-approved, no review needed. Final instalment.
Today, the control is a document and an annual sample
The authority is real and it is written down. The enforcement is a person following it, and the evidence is a sample once a year.
Where agents move money on someone else's behalf, the authority is written down: a delegated authority agreement, a claims-handling limit, a referral threshold. It is enforced by a person following it, and evidenced by an auditor checking a sample once a year.
That engagement draws a sample from the period and opines on whether the controls operated. It is not an opinion about whether any one payment was within authority, and it was never meant to be.
That works while people are doing the work. Agents do not create the gap. They remove what made it survivable, which was a person in the loop and a volume low enough for a sample to stand for the whole. What is left is the question the arrangement was never designed to answer: prove this specific payment was authorised.
The system that decides records what was decided. The system that pays records what was paid. A claims platform and a payment rail, an administration platform and a treasury workflow: the pair is the same wherever the work is delegated. Neither records what was authorised in a form anyone outside your walls can check, and neither can stop the other. A decisioning tool can flag a claim it dislikes; it cannot prevent the disbursement. A payments platform can execute; it has no view of the authority the payment was made under.
This is a present-tense problem and it does not require agents. Across 2023 and 2024, four self-funded employers sued their administrator, alleging it paid claims from plan funds under looser adjudication standards than it applied to its own insured business, and that it recovered its own overpayments by deducting them from later payments to the same providers. Filed allegations, not findings. Dockets available on request.
| Today | With Agentic Terminal | |
|---|---|---|
| The authority | A delegated authority agreement, in a document | A signed credential a machine evaluates |
| Enforcement | A person following the document | A gate the payment cannot route around |
| Evidence | An auditor's annual sample | A record on every decision and every payment |
| Proving one payment | Reconstruct from logs, emails, and memory | Verify a credential and a decision record |
| Who can check it | Your auditor, with your cooperation | Payor, auditor, regulator, independently |
Third-party administration is a licensed activity. As many as 46 states require a licence or other regulatory filing to act as an administrator, which is what makes the next paragraph a supervised obligation rather than a matter of contract.
All claims paid by the administrator from funds collected on behalf of the insurer shall be paid only on drafts of, and as authorized by, such insurer or its designee.
Florida Statutes § 626.883(5). The provision derives from the NAIC third-party administrator model act and appears in similar form in other adopting states, among them Nebraska § 44-5808, Connecticut, and Texas Insurance Code chapter 4151.
The control already exists, and it is already binding. What does not exist is a way to enforce it on a system rather than a person, or to evidence it on anything finer than an annual sample.
You do not have to start with payments
Start with decisions, where nothing moves money. The same authority then gates the payments, and the first phase is what authorises the second.
The gate, in one sentence
An agent cannot pay unless the payment is within the mandate it was issued under; when it cites a decision, that decision is verified before anything moves; and if it breaches an escalation threshold a human approves first, and that approval is itself a signed credential naming the person.
One word in that sentence is doing work. When it cites, not unless it cites: a mandate cannot yet require a citation, because no published schema version carries the field. A citation that is present is checked, and the check does not take the requesting system's word for its own result.
Phase one, decisions.
Your agents evaluate policy and return approve or deny on claims, refunds and distributions. Each decision produces a signed record of what was decided, under which policy version, on which inputs, and by which system.
Nothing moves money. You get evidence on every decision, including the denials, which is where fairness questions live.
Phase two, disbursement.
The same mandate that governed the decisions gates the payment. A payment that cannot cite a decision record is not constructed.
Phase one is what runs. Phase two is the design: no published schema version yet carries the field that ties a payment to a decision record.
The work you do in phase one is not thrown away. It is what authorises phase two.
One chain, and the first link is structural
One chain closes the seam section 01 describes, and it covers both phases above, so the decision work you do now is what authorises the payment work you do next.
Your agents cannot reach the credential.
Your agents call a tool. The service runs in your infrastructure, holds the keys, and constructs the payment.
There is no path from an agent to a signature, so a refusal is not advice an agent can decline to take.
The mandate is a signed credential, not a configuration file.
Per-payment ceilings, daily and monthly velocity caps, counterparty concentration limits, per-rail limits. Portable between systems, and verifiable by a third party who trusts neither of you.
Signed on the principal's behalf by our issuance service today. Principal-as-issuer is specified and not yet built.
A record you cannot avoid producing, on the decisions that went either way.
An observability tool records what it sees and cannot compel being seen: an uninstrumented agent produces no record, and the money still moves. Here the record sits on the authorising path, so producing it is not optional.
A decision that produces no payment still produces a record, so a denied claim is evidenced as surely as an approved one. That is where fairness questions live.
A refusal produces a record too, and it is the thing this boundary uniquely knows. It names the agent, the mandate it was acting under, which constraint was breached, and what the payment would have moved. A system that only decides never sees a payment that was stopped, because nothing was routed through it.
Above a threshold, a human approves, and the approval is itself an artifact.
One approval, one payment, never widening future authority, and re-evaluated at redemption.
So an approval is necessary and never sufficient, and what it authorised is provable afterwards.
One mandate and one policy model, across rails that do not converge.
Bank payouts and cards, stablecoins, and Lightning. The authority is expressed once and evaluated the same way on each, rather than reimplemented per rail.
That gives one mandate and one audit trail by construction, not by integration.
A decision produces a signed record, and the mandate can require it.
Your agents evaluate policy and return approve or deny, and each decision produces a signed record we call an attestation. A mandate can require that attestation before a payment is authorised, which makes the decision record a precondition of the payment rather than a byproduct of it. No decision record, no payment.
A mandate can also require that the system which decided is not the system that pays. That is segregation of duties, enforced at the payment rather than asserted in a policy document.
The record exists and is verifiable on its own. The requirement is not built: no published schema version carries the field that expresses it, and nothing on a payment path refuses a payment for lacking a record.
| Your existing control | Expressed in the mandate as |
|---|---|
| Claims-handling limit, per-claim or per-instruction authority | per_transaction_ceiling |
| Daily or monthly aggregate authority | time_windows.daily time_windows.monthly |
| Concentration limit per vendor | counterpartyVelocityCap |
| Referral threshold, or escalation to the carrier or the investment committee | escalationThreshold, then a human approval |
| Authority by payment method | spending_limits.per_rail |
| Segregation of decider and payer | a cited decision record, under a distinct signer |
| Withdrawal of authority | credential revocation, enforced at verification |
Your keys. Your infrastructure. No vendor in the payment path.
Agentic Terminal runs on your systems. We never hold your payment credentials, and we are never a dependency between your agents and the funds they disburse.
Comparable products fall into three groups. Agent wallet providers hold your keys. Agent identity and non-human-identity security vendors observe and score, without sitting on the authorising path. Credential standards bodies define a format with no enforcement point. None of the three combines customer-held keys with an authorisation a third party can verify.
Authorisation anyone can verify, without trusting us
The mandate is a W3C Verifiable Credential signed by your principal. A regulator, an auditor, a payor or a counterparty can verify what your agents were authorised to do: cryptographically, independently, without our participation and without taking your word for it.
Signed on the principal's behalf by our issuance service today. Principal-as-issuer is specified and not yet built. The verification property does not depend on which of the two signs.
Everyone else's policy is a vendor's configuration and a vendor's log. Verifiable by that vendor, and by nobody else.
Where money moves on someone else's behalf
Wherever three parties exist, our controls have something to bind. Where only two do, they mostly do not.
Our controls matter where three parties exist: whose money it is, who is authorised to move it, and who may need proof of what was authorised.
- 01Third-party claims administrators
- 02Benefits and warranty administrators
- 03Fund administrators
- 04Managing general agents
- 05Escrow agents
- 06Outsourced accounts payable
Anywhere authority to disburse is delegated, written down, and audited.
The same three parties appear on the asset side: a fund or its general partner, an administrator processing capital calls, distributions and fee payments on its behalf, and a depositary or auditor obliged to verify. Mandate is the word that world already uses.
Each of those three can verify independently: the payor, the administrator, and a regulator or auditor. None of them has to trust the other two, and none of them has to involve us.
The questions that decide whether this gets forwarded internally
Answered as they would be answered in diligence, including where the answer is not yet.
- Can we revoke an agent's authority immediately?
- Yes, with two limits we would rather state than have you find. Revoking sets an entry in a published status list, and verification refuses a credential whose entry is set. It refuses just as firmly when the list cannot be fetched or decoded, which is the part most implementations get backwards. First limit: the status list's own signature is not yet checked on that path, so the guarantee is currently as strong as control of the address serving the list, and no stronger. Second limit: suspension, as distinct from revocation, is not evaluated yet. A suspended credential still verifies. Both limits are in the status section.
- Can we pause all disbursement without a deploy?
- Revoking the mandate is the lever, and it now does what the question above describes. What we have not done is rehearse it as a drill, end to end, from revocation through to a payment being refused, so we would want to run that with you rather than assert it here.
- Can we require human approval above a threshold, and is that approval evidenced?
- The threshold is a field in the mandate, and the approval is itself a signed artifact that names what it authorised. It authorises one payment, never a widened future authority. The enforcement logic is built; the approval interface a person would use is not. See the status section.
- Can we restrict payments to an approved vendor panel?
- Not as an allowlist, and we would rather say so than imply otherwise. The binding counterparty control today is a cumulative cap per counterparty, which limits concentration rather than membership. The allowlist-shaped field in an earlier schema version was advisory, meaning an evaluator could ignore it, and it has been withdrawn rather than left in place looking binding.
- Can we require a decision record before a payment, not just check one when it is there?
- Not yet, and the difference is worth being precise about. A citation that is present is verified before anything moves, on every routing decision rather than only when a human is involved, and the result is derived from the document rather than from what the requesting system claims about it. What does not exist is a way for the mandate to demand a citation: no published schema version carries that field, so a payment citing nothing is not refused for it.
- What happens to a request the mandate does not authorise?
- No payment is constructed. Not a warning, not a flag, not a queue for someone to review. The service holds the credential, so there is nothing for the agent to route around.
- Does a denied claim produce a record?
- Yes, and that is deliberate. A decision that moves no money still produces a signed record, so the denials are evidenced as well as the approvals.
- Can one mandate cover multiple agents and roles?
- Yes. A mandate is scoped to the authority, not to a single process, and the same authority can name a deciding agent and a paying agent as distinct subjects.
- What if an agent tries to bypass the service?
- This is the case we tested hardest, because it is the one that matters. Lightning enforcement has been demonstrated on mainnet at a node's own signing boundary, against a client written specifically to bypass it. The refusal happens where the signature would be produced, which is why the bypass has nothing to bypass.
- Where does our data go? Does the vendor see it?
- The service runs in your infrastructure. Your claim files, your policy documents and your adjudication inputs stay there. What travels to a verifier is a credential and a record, not the data behind a decision.
- What security artifacts are available, and when?
- No SOC 2 report today, and we are not yet in an observation window. We are not going to put a date on it here. The enforcement path is self-hosted and holds your keys, so our internal controls are not the control there. Yours are. The one place we sit in the chain today is mandate issuance: our service signs the authority that every enforcement decision is then evaluated against. That is exactly why principal-as-issuer is specified, and why it is named on this page as unbuilt rather than left for you to discover. In the meantime a design partner gets a source-available enforcement engine they can read, permanent published schemas, and contractual commitments.
- How does this sit alongside our claims platform and our payment processor?
- Section 07 answers this one at length, because the short answer misleads.
Between the system that decides and the rail that moves money
We are not another integration into your claims platform. We are a boundary in front of your payment rails.
Your claims platform is where the claim lives: Guidewire ClaimCenter, Duck Creek, Sapiens, Origami Risk, Majesco, Snapsheet, or something built in-house. Your agents already read from it and write back to it, and that relationship is theirs, not ours. The same is true of ServiceNow for workflow, and of SAP or Oracle for accounts payable.
We do not connect to any of them, and there is no connector to any of them on our roadmap. We sit one step further down, at the point where a decision becomes a payment. Your agents call our tool instead of calling a payment API directly, and that substitution is the entire integration surface.
Design intent, not an installed deployment
What the service is
A service inside your own environment, holding your payment credentials, exposed to your agents as a tool they call in place of a rail's API. It evaluates each request against the mandate and constructs a payment only where the mandate allows one.
What it touches
The payment request, the mandate, and the rail. Each decision produces a record a third party can verify.
What it never touches
Whatever the deciding system holds. In claims that is your claim files, your policy documents, your claimant records and your adjudication logic; on the asset side it is the equivalent book of record. None of it leaves your environment, and none of it is needed to decide whether a payment is authorised.
Rail by rail: the bank payout rail has an adapter and no processor behind it today. Cards are in scope for launch. This section describes where the product sits, which is a claim about architecture, and the status section says what is running.
Six words this page uses precisely
Each of these has a loose everyday meaning and a narrow one here. The narrow one is meant.
- Mandate
- The delegated authority itself, expressed as a signed credential rather than a document. It carries the limits, the thresholds and the conditions a payment is checked against.
- Attestation, or decision record
- A signed statement that a decision was made: what was decided, under which policy version, on which inputs, by which system. It is evidence a third party can check, not a log line.
- Enforcement point
- The place where a refusal actually stops a payment, rather than reporting on one. Here it is the boundary that holds the credential, because a refusal anywhere an agent can route around it is advice.
- Rail
- A way money actually moves: a bank payout, a card, a stablecoin transfer, a Lightning payment. Each has its own mechanics, and the mandate is expressed once across all of them.
- Principal, or payor
- Whose money it is, and whose authority the mandate expresses. In a claims arrangement this is the carrier or the plan, not the administrator disbursing on its behalf. In a fund arrangement it is the fund or its general partner, not the administrator processing on its behalf. "Principal" is the term the credential itself uses.
- Revocation
- Withdrawing the authority, in a form a verifier checks independently. It is what makes an authority you granted something you can take back without our cooperation.
Do not take our word for any of this
The specification, the schemas and the enforcement engine are public and permanent. An engineer can check this page without talking to us.
These are usable on their own, not only as evidence. The engine is MIT licensed and
installable from npm as @observer-protocol/policy-engine, and the credential
model is a published schema at a permanent URL, so an implementer can adopt either
without adopting us.
The exact document a mandate validates against, at a stable URL that never changes. Every version stays served at its own URL; a change is a new URL, never an edit.
https://observerprotocol.org/schemas/delegation/v2.6.jsonWhat every field means, what is enforced, and what is not.
https://github.com/observer-protocol/aip
MIT licensed, published, with a cross-engine parity suite at
packages/parity-harness.
Issued, signed, and verifiable with public tooling. A sample for the first vertical is not yet published. It would show a disbursement by a claims administrator from a payor's funds, with three distinct parties visible in the credential itself. We would rather name the gap than link a mandate from a different shape of relationship.
| Built and tested | Designed, not built | Specified, not built |
|---|---|---|
| The enforcement core | The console illustrated at the top of this page. It is a design, and not a screenshot of the surface that does exist. | Principal-as-issuer. Mandates are signed by our issuance service on the principal's behalf today. |
| An approvals surface: approve and deny over an API and a command line, with pending approvals that survive a restart | Bank payout and card rails, both in scope for launch | Requiring a decision record at the payment boundary. No published schema version carries the field, and nothing on a payment path refuses a payment for lacking one. |
| Decision records, signed and independently verifiable from the file alone | Suspension, as distinct from revocation. A suspended credential still verifies. | |
| Lightning enforcement, demonstrated on mainnet at a node's own signing boundary against a client written specifically to bypass it | ||
| Revocation, enforced at verification and exercised against real revoked entries | Authentication of the status list itself on the delegation path |
Settlement. A payment has been refused under enforcement. On mainnet Lightning, 200,000 sat was denied against a 100,000 sat ceiling at the node's own signing boundary, with 481,500 sat of local balance and a live channel to the destination. A 10 sat payment to that same destination, over the same channel and by the same method, settled in the same session, which is what makes the refusal a policy decision rather than a routing or liquidity failure. The mandate for that demonstration was signed by a demo key generated on the box, not by our production issuer. No payment has been made on the bank payout or card rails, and the payout rail has an adapter and no processor. The claim above about one mandate spanning rails is a claim about the policy model, not a report of payments made.
Approvals. An approvals surface exists and is exercised: a rendered queue with working approve and deny, resolution records that verify against the key recovered from the identifier they name, and pending approvals that survive a restart. It runs locally and nothing is deployed. It binds to loopback and refuses a public interface, because the payment service has no access control yet rather than because local is where we want it, and approver entitlement is bypassed in that build. The console at the top of this page is a design, not a picture of it.
Revocation. A mandate carries a revocation status, and verification refuses a credential whose entry is set, or whose status list cannot be fetched or decoded. Two limits remain. The status list's own signature is not yet checked on that path, so the guarantee is as strong as control of the address serving the list. And suspension, as distinct from revocation, is not evaluated, so a suspended credential still verifies.
Who we are working with. We are working with our first design partners. We have no production customers.
We are taking a small number of design partners
If your organisation is putting agents anywhere near a payment or a disbursement, we would like to talk, whether or not you are ready to deploy anything.
The first conversation is usually the same question: when your agents pay on your behalf, how would you prove each payment was authorised?
Most people do not have an answer yet, and that is the useful place to start.
A good second question, if you want to arrive with one: walk us through how one of your delegated authority agreements would be expressed as a mandate, and what the evidence would look like for a single payment.