Suit Up · Asia's institutional desk on tokenisation

When an AI agent acts on behalf of a principal (a human end-user, a corporate treasury, an institutional operator), the authority pattern it sits inside determines who is the legal counterparty, who controls the keys, who bears operational loss in a malfunction, and which audit trail a regulator or dispute counterparty will read. Three operator-architecture patterns dominate institutional designs in early 2026, and they sit at meaningfully different points on the spectrum between API-layer and chain-layer authorisation. None is a winner; each suits a particular instrument, use case, and operational posture. This page is the operator-architecture middle layer between the legal frame in Foundations Chapter IX, Part 1 and the institutional decision-support in the agentic-commerce playbook.

Pattern 1: Custodial API key over institution-held wallet

The dominant pattern in bank-issued tokenised-deposit programmes today. The institution holds the private keys. The customer is the named holder of the on-chain address at the institution's record-keeping layer. The agent receives an API key scoped to the customer's address with conditions enforced at the institution's settlement layer. When the agent instructs a transfer, the institution validates the API call against the scope, signs the on-chain transaction with its custodial keys, and the on-chain entry remains at the customer's address with the institution as the signing operator.

The legal counterparty is the customer (instructing the institution via the agent). The agent has no on-chain identity; its authority lives entirely in the API scope. Operational risk for key management, signing infrastructure, and chain-level execution sits with the institution because it is the chain-layer signer. The customer-agreement amendment authorising agent-mediated instruction is the load-bearing legal piece; without it, the institution is signing transactions without explicit customer authorisation for the agent layer.

Revocation is per-API-key and immediate at the institution's API gateway. The institution can throttle, scope-down, or revoke the agent's API access without touching the chain. The customer's address and broader relationship with the institution are unaffected.

The pattern is not on-chain-native. The agent's authority is API-layer, not chain-layer. A relying party reading the chain sees the institution signing on the customer's behalf and cannot, from the chain alone, distinguish a customer-instructed transfer from an agent-instructed transfer. The audit trail lives at the institution. This is a feature for regulators familiar with bank-side accountability, and a constraint for any composability story that depends on chain-level verification of the agent's authority.

The pattern fits tokenised deposits and bank-internal stablecoin rails almost without exception in current production, and is the lowest-novelty starting point for a regulated institution because it preserves the existing custody and signing model and adds only the API scope layer.

Pattern 2: Delegated authority signature on customer-controlled wallet

The model x402 and the W3C Verifiable Credential and Decentralised Identifier stack lean toward (covered in Foundations Chapter IX, Part 3). The customer holds the private keys to a wallet on a public or shared-permissioned chain. The customer signs an explicit delegation to the agent, typically time-bound, amount-capped, and merchant-scoped or category-scoped. The agent's transactions reference the delegation, sometimes via on-chain delegation registries, sometimes via off-chain credential presentation. The on-chain authority is the customer with the agent executing within the delegated scope; chain-level enforcement of the scope is via the delegation construct itself.

The legal counterparty is the customer (acting through the agent under documented authority). Apparent-authority and ostensible-scope doctrines (covered in Regulatory perimeter for agents) handle the case where the agent acts outside the scope but the counterparty reasonably trusts the agent's outward claim. The chain enforces the cryptographic delegation (the agent cannot transact outside what the customer signed for) but does not enforce the soft-law authority doctrines (the agent acting within the cryptographic scope but outside the principal's intent is a doctrine question, not a chain question).

Operational risk shifts to the agent and the customer. The customer is responsible for key management on its own wallet. The agent's developer is responsible for ensuring the agent does not trigger scope-violations through hallucination or prompt injection. The institution, where one is involved (a stablecoin issuer providing the asset, an x402 merchant accepting payment), is largely outside the operational risk because it observes the chain entry and is not a signing party.

Revocation requires customer signature. The customer revokes by signing a revocation transaction with the same finality as the original delegation. A customer who loses wallet keys cannot revoke a delegation it previously signed, and the agent retains scoped authority until the original delegation expires. Time-bounding the delegation tightly is the standard mitigation.

The pattern fits stablecoin and tokenised-cash use cases where the customer's wallet is on-chain-native and the relying party (a merchant, an x402 endpoint, another agent) can verify the delegation directly from the chain or from a presented credential. The Visa and Mastercard agent-pay programmes (covered in Visa Intelligent Commerce and Mastercard Agent Pay) are a card-rail variant: the cardholder signs an authorisation at credential issuance, the agent presents the tokenised credential at checkout, and the network resolves within the delegated scope. The mechanics are similar even though the rail is not chain-native.

Pattern 3: Directly-held wallet

The agent holds its own private keys. It custodies tokenised assets directly. It transacts on the chain as itself, without referencing a customer or institution as the on-chain principal. Examples are sparse in regulated production today; the pattern appears mostly in agent-to-agent infrastructure experiments, in some research-grade machine-to-machine settlement deployments, and in early agent-native fintech sketches.

The legal-counterparty question is the unresolved structural problem. The agent has no legal personality in any major jurisdiction (covered in Foundations Chapter IX, Part 1). It cannot enter a contract in its own name, satisfy KYC as a principal, or be sued in its own right. The fallback in current sketches is that the agent's developer is the legal counterparty for everything the agent does, with the agent treated as the developer's tool. This is workable in principle but compresses every transaction into the developer's KYC and balance sheet, which most operators are not equipped to support at meaningful volume.

Operational risk concentrates on the agent's developer and on the agent's runtime. Key management is the developer's discipline. A malfunctioning agent that misroutes funds creates a loss the developer absorbs, because there is no upstream principal to bear it.

Most institutions are not building toward this pattern in 2026. The legal-counterparty question is unresolved in every major financial jurisdiction, KYC and AML perimeters were drafted for human and corporate holders, and insurance products for directly-held agent custody are early. The pattern will likely become more relevant as agent-native infrastructure matures, but for now it is the architectural sketch to know rather than the pattern to ship.

Pattern selection by use case

A customer instructs an agent to pay a vendor from a tokenised-deposit account at the customer's bank. Pattern 1 (custodial API key over institution-held wallet) is the fit. The bank's existing custody and signing model is preserved; the agent's authority is expressed in API scope; the customer-agreement amendment is the legal piece that unlocks the programme.

An agent transacts directly with an x402-style merchant rail using the customer's stablecoin balance. Pattern 2 (delegated authority signature) is the fit. The customer's wallet is on-chain-native, the merchant verifies the delegation from the chain or a presented credential, and the rail is built for chain-layer authority.

An agent operates as a stand-alone service holding its own balance to pay sub-services it consumes (an inference agent paying for compute, an aggregator paying for data feeds). Pattern 3 (directly-held wallet) is the architectural fit, with the developer accepting the legal-counterparty role as fallback. This is the most common shape in the agent-to-API and machine-to-machine experiments tracked in Foundations Chapter IX, Part 5.

A multi-agent system where agents transact with each other in a routing graph. Pattern 3 with developer-held custody as the legal-counterparty fallback is the operative shape, and the case where the legal-counterparty question is hardest.

Open questions

The boundary between Pattern 1 and Pattern 2 is moving. As more institutions ship on-chain-native products (purpose-bound money under MAS Project Orchid, programmable conditional payments under Project Ensemble in Hong Kong, smart-contract-level limit enforcement on tokenised-deposit rails), the question of whether the institution's signing model can be re-architected to give the customer chain-layer authority while preserving institutional risk controls becomes operationally pointed. The first regulated institution to ship a delegated-authority pattern on a tokenised-deposit rail will set a meaningful precedent.

The legal-counterparty question for Pattern 3 is unsettled in every major jurisdiction. Whether an agent can be the legal counterparty in any jurisdiction's contract law, whether the agent's developer is the de facto counterparty by default, and what insurance products underwrite the gap are the three open questions that will shape Pattern 3 viability over the next 24 months.

Cross-pattern interoperability has not been operationally tested at scale. An agent in Pattern 1 (signing via a bank's API for a customer-instructed transfer) transacting with an agent in Pattern 2 (presenting a delegated authority credential on-chain) across rails (the bank's tokenised-deposit chain settling against a public-chain stablecoin) is a flow the architecture supports in principle, but no published production deployment has stress-tested it. The first cross-pattern dispute will likely surface novel questions on how the two authority models compose in dispute resolution and audit.

How regulator-coordinated pilots will treat the boundary between API-layer and chain-layer enforcement is undisclosed. The HKMA EnsembleTX architecture, the MAS Project Orchid PBM construct, and comparable Singapore and Korean tokenised-deposit work all run today in something close to Pattern 1; whether any of them ship Pattern 2 elements over the next 12 to 24 months is one of the more interesting things to watch.

[Suit Up]

Principal-agent authority patterns for agentic commerce