The authority layer for agentic finance

One delegation. Multiple agents.
Verifiable wherever it’s accepted.

Define what AI agents may do with money. Enforce the limits of that authority, and verify each decision across wallets, payment protocols and financial systems.

Today: sandbox preview, one mandate shared by several agents, a simulated wallet, one EVM testnet and AP2 behind a flag. mnd8t decides and proves; you and the providers holding the funds decide whether to act. What is built and what is gated.

Pay a supplierSettle an invoiceTop up a metered API
Status
Sandbox preview
LLMs in the decision path
0
Customer keys held
0
Receipts per decision
1signed

AI agents can increasingly discover, decide and transact. The missing infrastructure is a reliable way to establish whether they should.

mnd8t separates authority from access, so organisations can delegate safely without handing agents unrestricted control.

Delegate

Express exactly what an agent is authorised to do.

Enforce

Evaluate submitted payments and transfers against deterministic policy. Your protected executor must require a valid, claimed authorisation artifact before acting.

Prove

Maintain verifiable evidence connecting authority, decision and outcome.

The missing layer

Identity proves who an agent is. Payment infrastructure lets it transact. Neither decides what it is authorised to do.

Card networks, commerce protocols, agent identity standards and stablecoin rails are being built quickly and well. These systems carry or enforce parts of delegated authority. mnd8t's focus is a separate, versioned authority layer with stateful policy decisions and linked evidence — because whether this particular payment is within the authority a person granted depends on the budget already spent, this counterparty's history, and whether a human would have wanted to be asked.

That is the layer mnd8t is built for. We also maintain a public reference on the whole stack — the Agentic Authority Stack, a dated tracker, and analyses of AP2, ACP, Visa TAP and Mastercard Agent Pay.

Read the intelligence hub
GovernanceWho answers when it goes wrong?
CommerceHow do agent and merchant talk?
RailHow does value actually move?
CredentialWhat instrument does it present?
IdentityWho is this agent, and who is it acting for?
AuthorityWhat is this agent allowed to do?mnd8t is built for this layer
Access is not authority

A payment that was technically authorised does not prove the agent was authorised to make that decision.

An agent may hold credentials capable of performing an action while having no legitimate authority to perform that particular action. Identity proves who the agent is. Credentials enable execution. mnd8t expresses what the agent is allowed to do — and keeps those three concerns separable, so authority travels separately from credentials.

Agentic systems need a representation of delegated authority, not simply a spending limit. mnd8t makes that authority explicit, enforceable and provable.

The instruction

“Book me a hotel in New York for less than £2,000.”

may permit an agent to spend up to £2,000. It does not necessarily establish permission to:

  • select a non-refundable room
  • choose any hotel
  • book for any date
  • purchase additional services
  • accept particular contractual terms
  • make several transactions totalling £2,000

This illustrates the authority problem. Today's engine supports payment and transfer constraints; it does not evaluate room refundability, stay dates or contractual terms.

Five steps between an agent and the action it wants to take.

01

Delegate

A principal grants an agent specific authority in a mandate — approved counterparties, per-transaction limits, daily and monthly budgets, permitted purposes, operating hours. Versioned and immutable once published, and revocable at any time.

02

Request

The agent proposes an action and describes what it intends to do. Holding a payment method or an API key is not treated as permission.

03

Decide

mnd8t evaluates the request against the mandate and everything already spent under it. APPROVE, REJECT, or ESCALATE to a human — with the full reason set and a rule-by-rule trace. The model does not decide whether the action is acceptable. Policy does. Run it in shadow first; enforce when it has earned it.

04

Execute

An approved action receives a one-time signed authorisation artifact. Your executor verifies and claims the artifact, then executes with its own credentials. Today, supported execution is limited to a simulated wallet or EVM testnet; live-money support remains gated. mnd8t does not become the rail.

05

Prove

Every decision and every later state change produces a signed Authority Record, linking delegation, request, policy, decision and execution outcome.

Where mnd8t sits

Identity says who is acting. Payments say how. mnd8t decides whether it had the authority.

mnd8t occupies three stages of the chain — authority, the policy decision, and the evidence — and is built to sit across the systems that handle the rest. Change your model provider, agent framework, bank, wallet or payment rail without rebuilding the rules that define what your agents are authorised to do.

your stack
Identity
Who is acting?
Agent identity, workload identity, authentication
mnd8t
Authority
What has the agent been permitted to do?
mnd8t represents the delegation
your stack
Intent
What is it trying to do now?
The agent submits the proposed action
mnd8t
Policy decision
Is that within its authority?
mnd8t decides, deterministically
your stack
Execution
How is it performed?
Banks, wallets, networks, merchants, APIs
mnd8t
Evidence
Can we prove what was authorised, and link it to what was reported?
mnd8t preserves the decision chain
Proof of outcome · Authorise · Execute · Verify

An approved payment is not a fulfilled mandate.

mnd8t doesn't stop at permission. Link what was authorised to reported execution, then evaluate the mandate's objective against customer-supplied evidence. mnd8t does not independently verify those reports.

An agent authorised to buy 100 units for no more than £10,000 can pay £9,700, on time, to the right supplier, entirely within its mandate — and report delivery of 80. Every authority system stops one step before that report. A mandate that records only what was permitted cannot tell you whether delegating it worked.

authorise
Mandate
What you delegated, and what you delegated it for. Versioned and immutable.
authorise
Policy decision
Deterministic, stateful, before any money moves.
authorise
Authorisation
A one-time signed artifact your executor claims.
execute
Execution
Your rails, your keys. mnd8t never holds either.
verify
Evidence
What your systems report settled, was invoiced or arrived. Customer-supplied.
verify
Outcome
The objective evaluated against that evidence: fulfilled, or not.

Today that means fulfilled or not, against evidence you supply. The Authority Record is the foundation for more: where execution systems can provide trusted evidence, the same chain can extend from authorised to executed, accepted, fulfilled, refunded or disputed. That is an extensible evidence model, not a claim that mnd8t independently verifies delivery.

See approved ≠ fulfilled in the sandboxEvidence is customer-supplied · no carrier, merchant or ERP integrations
Authority Record

Every decision leaves an Authority Record you can verify without us.

Not a transaction log. It records why the agent was permitted — or not permitted — to act: the principal, the agent, the mandate and its policy hash, the requested action, the decision and its reasons, any human approval, and the execution reference. Ed25519-signed and hash-chained; change one timestamp and verification fails.

Evidence, not surveillance. The record holds enough to answer what was authorised, what was requested, which policy applied, what was decided and what happened next — not everything an agent thought or did.

Three possible outcomes
✓ APPROVE⚠ ESCALATE✕ REJECT
int_7bd910 · rule trace
✓mandate/published1.00
✓schedule/within-window1.00
✓budget/daily-limit0.88
!counterparty/first-seen0.79
✕approval/autonomous-limit0.62
verdict · escalate to a human£1,200.00
What mnd8t is not

Designed to sit across these systems, not to become one of them.

That independence is strategic. The rules that define what your agents may do should outlive any one model provider, agent framework, bank, wallet or payment rail.

  • an AI agent
  • a bank account for agents
  • a wallet
  • a card network
  • a payment processor
  • a fraud-detection model
  • an agent identity provider
  • a merchant marketplace

Start in shadow. Enforce when it's earned.

A sandbox key, an agent, and a mandate. Most teams reach their first decision in under 30 minutes.

Get a sandbox key
No custody · No keys · No order routing