EnterpriseExplainerRegulation

One mandate, any agent, any service

Clients set what their AI agents may do. Why that mandate has to hold whichever AI they use and whichever service it touches, and how to enforce it.

CLIENT MANDATE ANY AGENT ANY SERVICE AGENT 01 AGENT 02 AGENT 03 ONE MANDATE SET BY THE CLIENT TRADING PAYMENTS LENDING ENFORCED BEFORE ANYTHING IS SIGNED · PROVABLE AFTER

In 2026, AI agents got access to money. Exchanges shipped MCP servers. Custodians and banks opened agent access to capital. Card networks and payment protocols built ways for agents to pay. Wallet platforms added agent wallets.

Every one of these came with a limits layer. And almost every one put those limits in one of two places: inside the agent, or inside a single service.

Neither is where they belong. The thing that needs protecting is the client's mandate: what the client has said their agent may do with their money. That mandate should hold whichever AI the client uses, and whichever financial service the agent touches. One mandate, any agent, any service: enforced before anything is signed, provable after.

The mandate belongs to the client

A mandate is the explicit set of things an agent may do with someone else's capital: which markets or payees, how much, at what leverage, with what collateral, within which time window, keeping what in reserve. It has to be:

  • Set by the client, and changed only by the client. Never by the agent.
  • Explicit: rules a machine can check, not intentions written in a prompt.
  • Bounded: every dimension that matters has a limit.
  • Revocable: it can be withdrawn at once.

Platforms that open their services to agents take on a new job: holding that mandate and enforcing it. A custodian already enforces its clients' instructions on transfers. With agents, the same duty extends to everything the agent does.

Today's controls live in the wrong places

A review of public documentation from 42 agent-money products and standards this autumn found two patterns.

Controls that live with the agent. Rules in the prompt. Spending caps passed to a command-line tool. Confirmation flags the agent supplies itself. Safety checks in an agent "skill". These are the weakest controls in the review: the agent's own process can skip them, a mistake or manipulated instruction can ignore them, and they change every time the client switches AI.

Controls that live with one service. Exchanges limit agents with API key permissions and isolated accounts. Payment products use budgets and payee lists. Wallet platforms check transaction fields. Each is sound on its own terms, and each stops at the edge of its service:

Where the agent actsHow it's limited todayWhat's missing
Exchanges and trading venuesAn isolated account or sub-account; API key permissions (trade, withdraw)Limits on size, leverage or exposure per agent
Payment products and standardsBudgets, payee lists, one-time spending allowancesAnything outside payments
Wallet infrastructureRules on any transaction, enforced before signing in the best casesRules read addresses, amounts and function calls, not what the action does to the account
Lending and borrowingNothing agent-specific foundEverything

Nobody in the review let a client cap an agent's leverage, exposure or lending health. And nobody governed trading, payments and lending with one mandate.

Any agent: the mandate can't depend on the AI

Clients will bring Claude, ChatGPT, open-source models and agents they built themselves, and they'll switch as models improve. A mandate that lives in one agent's prompt or tools has to be rebuilt for every one, and holds only as well as that agent behaves.

The public record shows why that matters. Safeguards inside agents have been skipped or lost: one agent platform says an older block on a partner agent's replies disappeared when the agent was rewritten, and an early shopping agent's confirmation step didn't fire. A mandate enforced outside the agent doesn't care which model is on the other side, or whether it's behaving.

Any service: the mandate can't stop at one platform's edge

Agents don't stay in one lane. A treasury agent sweeps idle stablecoins into yield, hedges with perps and pays vendors, all in one afternoon. A trading agent posts collateral, borrows against it and opens a position. If each of those runs through a different service's controls, the client's mandate is only as strong as the weakest one.

  • A limit in one service can't see the others. A payment budget can't see that the agent just opened a leveraged position. A trading key doesn't see the transfer that funded it.
  • Large losses can come through valid actions. Payee allowlists stop money leaving to the wrong address. They don't stop a bad trade. In 2022, leaked trading keys cost users of one trading-bot platform $22-27 million through trades on their own accounts. In a public benchmark last year, four of six AI models given $10,000 to trade lost money, every trade valid.
  • Transaction rules can't express a mandate. "Never above 3x leverage" or "keep collateral health above 1.5" isn't a rule about an address or an amount. A policy that only reads transaction fields can't enforce it, however securely it runs.
  • Separate systems mean separate everything. Separate approvals, revocation and logs. The client can't see the whole mandate in one place, and nor can an auditor.

Safe by default

Most agent tools start with no limits at all. Developer wallet kits describe a new agent signer as having "full control", or a delegation without restrictions as having "infinite and unbounded authority". Some platforms leave their strongest controls off unless the client turns them on.

A mandate should start from sensible defaults (small sizes, no leverage, no withdrawals) and loosen only when the client decides to. Most clients will never write a policy from scratch. The default is the policy most of them will run.

Enforcing a mandate

Successfully enforcing a client's instructions or mandate requires these six things in place:

  1. One mandate the client approves, covering every action the agent may take, on every service.
  2. Rules that understand each action: payees and budgets for payments; markets, size, leverage and exposure for trades; collateral health for lending.
  3. Checks against the whole account after the action, not the action on its own.
  4. Enforcement outside the agent, before signing. The agent proposes; it never holds a key that can sign on its own. Nothing that breaks the mandate gets a signature, whichever AI produced it.
  5. Sensible defaults, loosened only by the client.
  6. One place to change or revoke it, and only the client can.

Regulators are describing the same shape

  • FINRA warns that "Agents may act beyond the user's actual or intended scope and authority", and asks firms how they will "establish guardrails or control mechanisms to limit or restrict agent behaviors, actions or decisions."
  • Singapore's industry framework, published by MAS, says "An agent cannot extend the scope of a mandate through its own reasoning or inference", with a control that sits between the agent and the systems it acts on, "evaluating proposed actions before execution".
  • The Bank of England says "relying on a human in the loop for all agent actions is unlikely to be realistic."
  • The FSB asks firms to grant agents "the minimum permissions needed to achieve their goals ('least agency')."

All of them describe a bounded mandate, enforced outside the model, before execution, that the agent can't widen. None of them makes it depend on which AI or which service is involved.

Provable receipts

When one engine enforces the mandate, it can also prove each decision. Most platforms offer logs: a record the platform wrote, which clients and auditors have to trust. A few offer attestations from secure hardware. A zero-knowledge proof goes further: anyone can check that a specific action satisfied the client's exact rules, without access to the platform's systems.

That's useful for audits, for disputes, and for counterparties receiving agent actions from many platforms.

Pakt agentic guardrails

Pakt enforces client mandates for AI agents today. The same rules engine governs agents trading Hyperliquid perpetuals and agents swapping USDT to BTC through BOB Gateway, and it works with any MCP-compatible agent: Claude Code, Codex, Gemini and others.

New accounts start from a conservative default (a small per-trade cap, no leverage, and no moving collateral out), which the client loosens deliberately. The client approves rules with their own signer. The agent proposes actions. Each one is checked inside secure hardware (a TEE) against the rules and the account's projected state, and signed only if every rule passes, with a zero-knowledge proof generated in under two seconds. Refused actions get no signature and never reach the venue.

The same Pakt engine can be applied to each type of platform's use case:

  • Custodians: enforcing clients' mandates as their agents trade, stake or move assets.
  • Exchanges: per-agent mandates behind an agent API or MCP server.
  • Payments: agents paying within budgets, payee lists and time windows.

Sources