Six months from now, an auditor will walk into a bank that deployed AI agents last quarter and ask one question: who authorised this transaction? Banking already has an answer for that question. Today's agent stacks do not.
The missing piece has a name: the decision token. It is a short, signed statement that a named person approved a specific action, within a specific limit, for a specific window of time, before the agent acted. Without it, every agent-initiated transaction in a regulated bank is a finding waiting to be written up. With it, the agent fits inside the controls the bank already uses, the auditor already knows how to check, and the regulator signed off on decades ago.
This piece defines the decision token, walks through one worked banking example, maps the primitive to the controls banks have run for five decades, and explains why the management layer that produces decision tokens is now inevitable.
Why banking has always required a signed approval before an action
Banks govern unaccountable action by design. They have for five decades. The framework pre-dates computing. Each wave of regulation (SOX, Basel operational-risk controls, PSD2) digitised more of it. The pattern continues: every new technology that comes within reach of a customer account has to meet the same controls.
Four controls run that framework.
Identity. Every money-moving action traces back to a named person with KYC-grade attribution. The bank knows who authorised it. So does the regulator.
Scoped authority. Segregation of duties, maker-checker approvals, role-based delegation. One person cannot both start and approve a payment above a given threshold. Authority depends on the role, what it has been delegated to do, and the circumstances it is allowed to act in.
Signed authorisation. Wet signatures became digital signatures became bank-grade non-repudiation (the property that an authorised party cannot later deny they authorised something). Every material instruction carries proof that a named principal, acting under a named authority, agreed to the specific action.
System of record. Settlement systems, trade-reconstruction archives, SWIFT message logs. The record is authoritative. The regulator calls it the book of record for a reason.
A decision token sits inside the third control. It carries the first and second as fields of its own. It writes directly into the fourth. The decision token is the agent-era version of a signed instruction banks have required since the telex era.
The four fields every decision token carries
A decision token is a signed record with four fields. All four must be present. If any one is missing, what you have is a different kind of credential.
Payload. The specific action being authorised. One operation, one resource, one amount, one target. "Reduce the overdraft limit on account 7291 to £0 for the rest of this quarter" is a payload. "The agent is allowed to use the credit API" is not. The second gives access to a capability without binding it to a decision.
Signer. The named person who gave the authorisation. A real human in the bank's identity system, or a system account whose authority was granted by a human and recorded as such. The signer is the same identity the bank already uses for its other audited actions.
Scope. The limits the authorisation does not exceed. Monetary cap, allowed counterparties, and permitted operation types. Scope is the boundary the signer approved the agent to act within. Anything outside it has to be re-authorised.
Expiry. The time window after which the token is invalid. Short-lived by design, measured in minutes or hours for most banking operations, days at most. The regulator expects authorisations to be fresh when the action lands.
A decision token is different in kind from a prompt, a confirmation dialogue, or an audit log entry. It collapses four questions into a single record the agent carries and the executor checks: what was authorised, by whom, within what limits, and for how long.
A worked example: the credit-review agent
Consider a credit-review agent at a mid-tier bank. The agent's job is to watch overdraft usage, flag accounts in distress, and when a human reviewer approves, apply the reviewer's decision to the core banking system.
Today's path: the reviewer reads the agent's summary, types "approve" in a chat window, and the agent calls the credit API with a service-account OAuth token. The audit trail says "service account 'credit-ops-agent' reduced overdraft limit on account 7291." It does not say Priya Natarajan, Senior Credit Reviewer, authorised that specific action at 14:03 on Tuesday. It cannot. Priya's consent exists only in the agent's conversation transcript, which is not an authoritative record and does not carry her signature.
With a decision token, the shape is different. Priya reviews the agent's recommendation. She clicks approve in a client that signs on her behalf. The token it produces carries four pieces: a payload of "reduce overdraft limit on account 7291 to £0", her DID (her unique digital identifier, used to produce the signature) as the signer, a scope of "credit-review operations under the quarterly envelope", and an expiry of fifteen minutes. The agent presents the token when calling the credit API. The core system checks the signature, checks the scope against Priya's permissions, confirms the expiry, and executes. The token and the resulting change are written together to the signed record.
Two years later, an auditor pulls the record for account 7291. The decision ties to a specific human, under a specific authority, with cryptographic proof that human consented. The time window was short enough that revocation would still have been honoured. The question "who authorised this?" has one answer. It holds up in a tribunal.
How Covia verifies the token at runtime and writes the receipt to the record
Covia's management layer produces and verifies decision tokens directly. It runs as a venue, which is the name for one instance of Covia a bank operates inside its own environment. The implementation uses standard components. None of them are Covia inventions.
The signer resolves through a public identity record, a W3C decentralised identifier (DID), bound to the bank's existing identity provider. Priya's DID is her stable handle. Her signing key lives in the bank's key management system. The bank audits the resolution path the same way it audits any other identity lookup.
The capability model uses UCAN, the published specification for user-controlled authorisation networks. The token can carry a chain of permissions, each one signed, scoped, and time-limited. Covia checks the chain before any change happens.
The signature uses Ed25519, a standard scheme bank cryptographers already know. The verifier needs only the signer's public key, which the bank publishes through its identity provider. The check is local to the venue. No external call is needed at the point of action.
The record is a lattice entry (the venue's signed, immutable log) written at the moment the action succeeds. The decision token, the capability chain, the resulting change, and the venue's own signed receipt are a single artefact. An auditor with the record's address retrieves the full chain and verifies it against the signer's public key years later, without needing the venue to be running.
Four controls, one primitive, one write. The mechanism is explained in more depth on the Covia Grid.
Three failure modes a decision token prevents, and one it does not
A decision token prevents attribution to the wrong principal. When the auditor asks who authorised the action, the signer field answers directly, with cryptographic proof. There is no reconstruction from logs. No inference from timestamps. No reliance on the agent's own transcript.
A decision token prevents authority creep inside a single integration. OAuth bearers routinely accumulate scopes over time. The agent that was granted read access last quarter is now writing because a new scope got added to the client. A decision token binds the authority to the specific decision. The integration itself gets no standing permission. The scope expires when the token expires. There is no slow drift.
A decision token prevents replay in a different context. The token is scoped to one payload, one resource, one time window. An attacker who intercepts the token cannot reuse it for a different action, a different account, or a later date. The verifier enforces the scope and expiry fields at the point of action.
A decision token does not prevent a correctly-authorised action from being wrong. If Priya approves a limit reduction based on a faulty agent summary, the token proves she approved it. The quality of that approval is a separate question. This infrastructure answers who authorised the action and under what rule. It does not substitute for the human's judgement, and nothing claims it does. The runtime policy enforcement layer is what keeps bad decisions inside policy guard-rails. The decision token is what keeps the human who approved them identifiable.
Why this is inevitable
The four banking controls exist because the regulator keeps the bank's operating licence contingent on them. The regulator writes examinations against them. The board signs attestations about them. The audit firm tests them. None of that bends for new technology. The technology has to meet the controls.
AI agents will touch money in regulated banks. The productivity case is already made. The useful question is what the per-action authorisation looks like when they arrive.
Three futures are possible.
In the first, agents stay out of money-moving flows entirely, confined to internal productivity tasks. This is the current state in most tier-one banks. The pressure to extend agents into revenue-generating workflows is already visible in strategy decks. The state is not stable.
In the second, agents are deployed without decision tokens, and the bank absorbs the audit findings as a cost of doing business. This option ends with the first material incident.
In the third, the management layer that produces decision tokens becomes the infrastructure every agent in the bank runs on. The straight line from how banks are regulated to what has to exist ends here. Covia is building that layer because the layer must exist, because the regulatory floor is non-negotiable, and because the alternative is the regulator deciding what it looks like after an incident.
The enterprise case is already visible to buyers who have walked the audit scenario in their heads.
For a bank CTO or CISO reading this, two questions matter. What signed, scoped, time-bounded record does each agent action produce? And where does that record live when the auditor asks for it in two years? If the answer is "we are figuring it out," the auditor's answer in two years will be a finding. If the answer is "the agent carries a decision token into every operation, verifiable against the signer's key, written to a durable record at the point of action," the bank has met the control the regulator will test against.
The decision token is the primitive. Covia makes it available today.