Product overview

Mandate is the compliance layer for agentic commerce: the control and evidence layer an agent's payment needs before any regulated firm will execute it.

AI agents can already negotiate terms and decide what to pay. They cannot hold a licence, produce a consent record that satisfies UK payment law, verify who they are paying, or leave a receipt a regulator will accept. The platforms racing to build agent commerce, from Google and Stripe to Cloudflare, standardise the messages and settle what regulation does not touch, then stop, by design. And the firms that can execute a regulated payment, the UK's authorised payment initiation providers, have none of the controls an autonomous payer needs. Mandate's product, Agentry, is being built to close that gap: a consent record scoped, capped, expiring and revocable by design, counterparties verified before a payment order exists, and an evidence chain built to the standard a regulated firm requires before it will accept an agent's instruction. What is available today is the trust layer, which verifies businesses, registers them, and issues portable proof, and which moves no money. Execution under the mandate follows Mandate's own FCA authorisation, which we intend to apply for and do not hold.

Agentry is the API that platforms and businesses integrate. Today that means a UK limited company, or an agent acting for it, having the company checked and taking away a signed record of what was checked. Today an agent acts for a business by holding that business's key. Agentry does not yet record which agent holds it.

UK limited companies only. Sole traders are not supported yet.

Agentry's Trust API verifies a UK limited company, registers it, and issues a portable, signed record of what was verified. It moves no money.

The Trust API is in sandbox. Every key it issues is a sandbox key, and nothing in it issues a live one. It moves no money and makes no regulatory claim: nothing in it initiates, holds, receives or settles a payment, and no tool on it can.

1. Register. A business registers itself with its Companies House number and a contact email.
2. Verify. Agentry checks the company against the Companies House register, and the person controlling the account completes an identity check on the identity provider's hosted page. No tool can complete that step.
3. Hold a proof. When both checks hold, the business can read its own status and take away a signed proof. A proof issued today is a sandbox proof: it says so in its signed text and is not evidence about the company for anyone to rely on. A live proof, when there is one, is what a counterparty checks offline against Agentry's published key, without contacting us.

Status reads are self-only: a caller sees its own business and no other. There is no lookup by company number and no directory.

The 13 tools

A Trust API key lists exactly these 13 tools and can call nothing else. Nothing that moves money is visible to it or callable by it.

register_business

registers a business and binds your key to it, with its Companies House number, a contact email and, optionally, a contact name. One business per key.

check_company

runs the Companies House register check for that business. It takes no company number, because the company is the one your key is bound to.

get_my_verification_status

reads your own business's status and, once both checks hold, returns a freshly signed proof.

delete_my_business

deletes the account record and revokes every key issued to the business, including the one that made the call.

register_agent

records a software agent that belongs to the business. On its own it grants the agent nothing.

request_agent_binding

asks a person at the business to confirm what one of its agents may do on the business's behalf. The link goes to the account contact address and is never returned to the caller, so an agent cannot confirm itself.

list_my_agents

lists the business's own agents and where each one's confirmation stands.

revoke_agent_binding

ends what the business confirmed about one of its agents, at once. A person can also end it through a link, with no key at all.

request_agent_identity_challenge

starts recording an identity an agent already holds elsewhere, by returning a one-time challenge. Nothing is recorded until the agent returns it signed.

confirm_agent_identity_link

completes that recording. Agentry checks the signature against the key the identity names and keeps the key's thumbprint, never the key.

revoke_agent_identity_link

stops including one of an agent's recorded identities in what that agent presents.

list_agent_activity

lists, newest first, what Agentry has recorded about the business's own agents: the events on their records and the signed records issued to them, with the confirmation each was under and, where it was recorded, the key or emailed link it came through. It shows nothing about any other business.

get_my_audit_pack

exports the business's own audit pack for a period: what Agentry has recorded about the business and its agents, and a manifest, checkable by anyone who holds it. It shows nothing about any other business.

The transport is MCP over HTTP. The tools are native MCP tools, so any MCP client or agent framework that lets you set a bearer key can discover and call them, and with no agent at all a call is a JSON-RPC body sent with curl. Clients that require OAuth rather than a static key cannot connect yet; the platform connectors follow.

A proof is a compact JWS signed with ES256 and issued under the standard trust_v1. It carries everything needed to check it apart from Agentry's public key set, published at /.well-known/agentry-trust-jwks, which a reader fetches once and pins. Checking a proof needs no Agentry account and no key, and once the key set is pinned, no call to us.

What a proof states, in its own signed text:

This record states that, on the dates given, the company named was present on the Companies House register and its register status passed the issuer's check, and that the person controlling the Agentry account for this company passed an identity check. It does not establish that those are the same person, or that the person is an officer of the company. The checks were performed by the issuer for the subject's own use, are valid only until the expiry date carried in this record, and are not refreshed after issue. This record is:

• not a statement about creditworthiness or solvency (no financial information was collected)
• not an audit
• not a guarantee
• not evidence the issuer is authorised or regulated
• not customer due diligence under MLR 2017
• not confirmation that the person who passed the identity check is an officer of the company
• not a current statement
• not transferable
• This proof carries an `env` claim stating the environment that issued it. Where `env` is `sandbox` this is a test artefact: the checks it names may not have been performed against any register or any person, and it is not evidence of anything about the company it names.

A proof is not refreshed after issue, and there is no revocation service: it stops being good when it expires and at no other moment. A proof issued in the sandbox says that it is one. It carries the signed typ agentry-sandbox-proof+jwt where a live proof carries agentry-trust-proof+jwt, it expires 7 days after issue, and the shipped verifier refuses it by default; a reader who explicitly opts in to reading sandbox proofs gets it back as not valid for reliance, never as valid.

• Read the trust_v1 standard: what a proof issued under it states, how it is signed, and how long it lasts.
• Read how to check a proof: offline, without asking the issuer, and what each of the three results means.

• Not a payment service. Agentry does not move, hold, initiate or receive money, and no live money has moved through anything Mandate has built.
• Not enforcement. Nothing in the Trust API can refuse a payment, because nothing in it touches a payment.
• No FCA permissions. Mandate holds no FCA permissions and claims none. The Trust API moves no money.
• Not a reliance service. A proof is issued to the business named in it, for that business to present. Nobody can look a business up through Agentry: third-party lookups are a later phase, and they need reliance terms that have not been published.
• Not a credit check. Agentry holds no financial information about any third party. It is identity and registration.

Do not present a sandbox proof to a third party, and do not build a flow that shows one to anyone. A proof is built to travel without us. A sandbox proof says in its signed text that it is a test artefact, but that protects only a reader who reads it.

A mandate names one supplier, a maximum amount, one or more periodic limits and an expiry, and the payer can revoke it. Refusing a payment that falls outside the mandate happens at execution, and execution follows authorisation. Unless and until that authorisation is granted, Agentry executes no payment.

Mandate is never in the flow of funds and holds no balance for anyone, by design and by scope: payment initiation moves money between the payer's own account and the payee's.

Where a third party executed the payment and told us about it, the receipt says so in its own text: the evidence is attested, not witnessed.

Looking up a business that has not handed you a proof is a later phase, and the platform connectors follow. None of this carries a date, and none is given here.

The Trust API is not open for sign-up. It is in sandbox ahead of launch, and keys are not available to the public.