SKIP TO CONTENT
AI AGENTS6 minStandards That Ship / Ep. 4 · Stage 4-3

Agent Mandate Checks: Where to Enforce, What to Test

Three places can check an AI agent’s mandate. Combine two and you may check the wrong agent.

XIN

IN 30 SECONDS

An enforcement venue is the one place that checks the mandate: the token, a delegated account or an executor, per the ERC-8226 Draft. Pick one that sees the real caller, pin the draft revision, name owners and write your failure tests first.

KEY TAKEAWAYS · 3

  • The current ERC-8226 draft describes three places to check a mandate: in the token, in a delegated account or in an executor. An earlier version of this article understated those integration options.
  • ERC-8226 is still a Draft: write down the exact revision you build on and the deployed contract version.
  • A mandate and an ERC-20 allowance are separate checks. Recipient policy, custody, compliance-provider governance and audit records still need an explicit design.
On this page

Choose where to enforce the mandate

IN SHORT Pick one place to check the mandate, because the draft’s three options see different callers.

WORDS TO KNOW

Executor
A contract the agent must go through. It checks the mandate, then forwards the call.
Delegated account
An investor wallet that runs the contract code it points to, which EIP-7702 allows.
Reentrancy
A called contract calling back into yours before the first call ends.

ENFORCEMENT VENUE

Decide: Can you change the token contract?Decision tree: Can you change the token contract? If Yes: it is new or upgradeable, then Token gate. If No, and the investor’s account delegates to an executor (EIP-7702), then Delegated account. If No, and the investor approves an executor, then Executor.DECIDECan you change the tokencontract?If yes: it is new orupgradeableToken gateReview: is every supportedaction gated?If no, and the investor’saccount delegates to anexecutor (EIP-7702)Delegated accountReview: which code acts,and who can change it?If no, and the investorapproves an executorExecutorReview: can another spenderbypass it?

Step 1. First question. The first question: can you still change the token?

Pick a step to see it move
  1. First question The first question: can you still change the token?
  2. Token gate A new or upgradeable token can check the mandate itself.
  3. Delegated account The investor’s account runs the checking code itself.
  4. Executor The agent must go through a contract the investor approved.
The three venues described in the ERC-8226 Draft. The draft leaves the choice of venue outside its normative interface, the part every implementation must follow.

IN PLAIN WORDS

The token, a Delegated account An investor wallet that runs the contract code it points to, which EIP-7702 allows. See the glossary or an executor: the one you pick must see who really asked, the agent, not a contract that relays its call.

The draft says the venues “do not combine”: a gated token would check the executor, not the agent. An Executor A contract the agent must go through. It checks the mandate, then forwards the call. See the glossary forwards the call, so mixing venues can check the wrong mandate.

A view-only check before the transaction is not enforcement. Recheck inside the transaction that does the trade, and make the trade and the cap count succeed or fail together.

WATCH OUT

Then test the hard cases: a failed call further down, Reentrancy A called contract calling back into yours before the first call ends. See the glossary, a duplicate request and a revoked mandate.

Check each standard’s status and version

IN SHORT Two of these four standards are still Drafts, so code copied from them can go stale.

STATUS CHECK
ERC-3643
Final
Permissioned tokens: identity and compliance checks
ERC-7943
Final
A minimal interface for real-world asset tokens
ERC-8226
Draft
Agent mandates for regulated assets
ERC-8004
Draft
Agent discovery and trust signals, not mandates
Status on eips.ethereum.org, checked 12 October 2026. A merged proposal can still be a Draft, and Final does not certify an implementation.

ERC-8226 remains Draft at this revision. So in the delivery brief, write down the exact source revision and the deployed contract version. Read the draft again before you reuse an example: a newer version may have fixed a flaw an older article pointed out.

Coming up next: And who runs what the standard leaves open?

Owners and tests to settle before go-live

IN SHORT The interface leaves operations to whoever implements it, so each one needs a named owner.

OWNERS TO NAME
Layered stack diagram: 4 layers, top to bottomLayered stack diagram: 4 layers, top to bottom. Layer 1, COMPLIANCE PROVIDER: Who chooses it?, Who signs the result?, How fresh is it?, What if it’s down?. Layer 2, REVOCATION: Who responds, and how fast?. Layer 3, ADMIN AND UPGRADES: Who holds admin access?, Who approves upgrades?. Layer 4, INCIDENTS: Who handles an incident?.COMPLIANCE PROVIDERWho chooses it?Who signs the result?How fresh is it?What if it’s down?REVOCATIONWho responds, and how fast?ADMIN AND UPGRADESWho holds admin access?Who approves upgrades?INCIDENTSWho handles an incident?
What the mandate interface leaves open, layer by layer.

A mandate field can point to a legal document, but that field doesn’t execute the document’s terms.

Off-chain checks can feed an on-chain policy through a trusted attestation or adapter. Then ask the questions in the top layer, plus one more: how does that result get revoked?

FAILURE TESTS
Allowance present, mandate absent
Apply the chosen policy, strict or selective, every time.
Mandate expired or frozen
Reject the action and keep a useful failure reason.
Several actions in one transaction
No per-call or cumulative-cap bypass.
Recipient outside the approved policy
Reject even if the amount fits the mandate.
Provider status changes
Exercise the revocation and freeze sync, and measure the response time.
Write down the expected result of each failure case before you build.

ITEM GET

Six things to ask for

In the delivery brief, I’d ask for a caller map, a custody choice, a written policy, pinned contract versions, runnable failure tests and one operations owner. The handover should show the approved scope and the records of each action that works, fails or gets stopped.

Sources: ERC-3643, ERC-8226 (Draft), ERC-7943, ERC-8004 (Draft), ERC-8203 (Draft, PR #1614, not merged).

FAQ

A purpose-built integration can add mandate checks. The standard ICompliance call does not pass the original spender. So check the mandate in a venue that sees it, and test every path you support.

No. I am a named author of ERC-3643 and a co-author of ERC-8203, a Draft in open PR #1614 that is not merged, with a reference-implementation contribution. This is an integration analysis, not a production report.

STAGE CLEAR

What you now know

  • Which venue fits a token you can or can’t change, and why mixing venues can check the wrong mandate.
  • What to pin, who to name and which failure cases to test before go-live.

Check yourself

Tap or click a question to see the answer.

Your token is already deployed and can’t be changed. Where can you still check the mandate?

Outside the token: in a delegated account (EIP-7702) or an executor the investor approves. With an executor, check that no other spender can go around it.

Next episode:When a token hides balances, how does a freeze still work, and what can a failed transfer leak?6 min
Adam Boudjemaa
Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.