What this prototype shows

An AI agent can be correctly identified and still act beyond what its principal allowed. Identity is not authority. The Agent Passport is a machine-verifiable record of who assured the provider, which agent key is acting, and what the customer permits, checked by the bank at the moment the agent tries to move money, and revocable at that moment.

Five parties, one path

1. Apply. PayRail Ltd submits its evidence pack. The model reads it into structured facts, each with a source and a quote; the provider corrects them; the agent signs a one-off challenge to prove it holds its key; the provider signs the agent's identity claim.
2. Review & issue. Eight automated checks run over the reviewed facts and the authority's records, each citing a rule and its source. A named officer approves with a condition, requests information or rejects, with a written reason. On approval the authority signs the assurance and mirrors the mandate on the vouch rail.
3. Sign mandate. Northgate Joinery Ltd's finance director signs the supplier allowlist, the limits and the expiry with the company's own key. Only then is the envelope complete.
4. Act & check. The agent signs each instruction. The bank checks, in order: assurance signature, registry status, provider signature and binding, agent signature, customer signature, payee and action, per-payment cap, 30-day cap from its own ledger, supervisor condition. ALLOW, ESCALATE or DENY, with a reason code and a signed receipt.
5. Maintain. Suspend, reinstate, revoke, each with a reason. The bank reads the registry in real time, so revocation bites on the very next instruction and the vouch rail refuses too. Three refusals raise an incident to the supervisor. Everything is hash-chained and replayable.

Why an envelope of three signatures

A single authority-signed token would have to carry claims the authority cannot stand behind: which supplier accounts a private company wants to pay, or which key a provider's agent holds today. So each party signs only what it is entitled to say. The assurance is bound to the exact agent_identity it was issued for, and the mandate names the passport it belongs to. Remove any one signature and the bank refuses.

Where the model sits, and where it does not

Gemini is used twice, both at the edges: reading documents into a fixed schema, and phrasing the check results as a draft file note. It never checks, scores, approves or verifies. If the API is unavailable the system falls back to a deterministic fixture and says so. The consequential middle is plain rules in a versioned pack (payments-2026.09), each labelled CURRENT, PROTOTYPE or FUTURE with its source, so the same inputs always give the same decision.

Rules in this pack

At application

• A.1 Provider licence reference resolves and is active CURRENT — Payment-institution register (analogue of the FCA Financial Services Register)
• A.2 Companies House number resolves to the provider CURRENT — Companies House register
• A.3 Accountable person named, with role and signed declaration PROTOTYPE — SM&CR-style accountability (prototype condition)
• A.4 Professional indemnity insurance evidenced and in force PROTOTYPE — Rule pack policy: minimum cover (prototype condition)
• A.5 Agent controls the submitted public key (signed challenge) CURRENT — RFC 7800 proof-of-possession pattern
• A.6 Customer service agreement evidenced (customer, officer, suppliers) PROTOTYPE — Signed service agreement; Companies House for the customer
• A.7 Requested limits within policy ceilings PROTOTYPE — Rule pack policy table
• A.8 Software and configuration declared; config hash matches the deployed file PROTOTYPE — Recognised-software list; SHA-256 of the declared configuration

At the bank, in this order

• R.1 Assurance signature genuine (authority key) → DENY PROTOTYPE — EdDSA / Ed25519 (RFC 8037)
• R.2 Assurance active and unexpired (registry lookup) → DENY PROTOTYPE — Authority status registry (real-time lookup)
• R.3 Agent identity signature genuine (provider key) → DENY PROTOTYPE — EdDSA / Ed25519 (RFC 8037)
• R.4 Instruction signed by the agent key inside agent_identity → DENY PROTOTYPE — RFC 7800 cnf / DPoP-style proof-of-possession
• R.5 Mandate signed by the customer and unexpired → DENY PROTOTYPE — EdDSA / Ed25519 (RFC 8037); mandate validity
• R.6 Action permitted and payee account on the customer-signed allowlist → DENY PROTOTYPE — authorization_details (RFC 9396 shape); Confirmation-of-Payee analogue
• R.7 Amount within the per-payment limit → DENY PROTOTYPE — Mandate per_payment_limit
• R.8 Amount plus 30-day total for this payee account within the monthly limit → DENY PROTOTYPE — Mandate monthly_limit_per_account; bank-held ledger (limit in the mandate, total in the bank)
• R.9 Supervisor condition: amount above human_confirm_above is held for a named human → ESCALATE PROTOTYPE — Assurance condition set by the authority officer

Unknown action types are refused at R.6. The limit lives in the mandate; the running 30-day total lives at the bank, because a signed credential cannot carry a running balance.

The vouch rail

On approval the mandate is mirrored as an AI Voucher on the vouch.finance sandbox: the passport id goes into the voucher's metadata and the voucher id into the envelope. On revocation the voucher is deleted, so one supervisory action makes two rails refuse. VOUCH_MODE=fixture (the default) records deterministic voucher ids without a network call; VOUCH_MODE=live calls the sandbox and falls back visibly on any failure; PAYMENT_RAIL=vouch additionally settles each allowed instruction there. The field mapping is a proposed compatibility profile in docs/KYA_extension_for_purpose_bound_value.md. This deployment runs vouch in live mode on the vouch rail.

What is real

• Ed25519 signatures by three separate keys on the three claims, on every agent instruction and on every receipt (RFC 8037; keys generated on this server).
• Proof of possession: the agent signs the authority's nonce at application and every instruction afterwards (RFC 7800 pattern, cnf inside agent_identity).
• Scope as structured authorization_details (RFC 9396 shape) inside the customer-signed mandate.
• Registry-based status checked at action time; a bank-held ledger for the cumulative limit; hash-chained audit with exact replay; status-list-style revocation by registry flag.
• Live document extraction with per-fact provenance; a live vouch.finance sandbox adapter with a fixture fallback.

What is not

• The registers, the firms, the bank and the accounts are synthetic. The authority is "the national payments supervisor (demo)"; no FCA process is implied.
• The agent and the customer's signing ceremony are simulated inside this server so the demo can show a copied passport and an unsigned mandate failing.
• Sub-agent delegation, multi-bank cumulative totals, an incident workflow beyond the log row, and attestation of the running software are roadmap. The verifiable-credentials pattern is used in its JWT profile; there is no JSON-LD wrapper.

What we do not claim

That any supervisor issues agent passports today; that the passport replaces the provider's licence, the customer's contract or the bank's own mandate; that a signature proves an agent is safe or correct; that a valid passport compels a bank to execute; that this is production cryptographic infrastructure.

Lexis Labs · C:\>DIR Global 'Agentic Regulator' Hackathon · Know Your Agent problem space · synthetic data only. The same engine runs the UK Self Assessment vertical with a different rule pack.