Mandatum (delegated authority): Agent Wallets Without Your Keys

In May 2026, an X user drained 3 billion DRB tokens from a wallet linked to Grok. The OECD AI incident record values the loss at roughly $150,000 to $200,000. The method was not a smart contract exploit. According to Giskard’s analysis, the attacker first sent an NFT that gave the agent “Executive” permissions and let it bypass standard transfer limits. Then the attacker asked Grok to translate a Morse code message. The decoded text was a transfer instruction, and the Bankr trading bot executed it. Giskard reports that about 80% of the funds came back only after the community identified the attacker.

The agent held broad authority, and a prompt was enough to use it. This post is about the alternative: authority that is narrow, checked on chain, and revocable.

The problem: keys or clicks

Today a builder has two bad options.

Give the agent a key. It can do anything the key can do. A successful prompt injection inherits all of it.
Approve every transaction. The human stays in the loop for a $3 purchase. The agent is no longer autonomous.

Security guidance names the failure. OWASP’s LLM Top 10 lists Excessive Agency with three root causes: excessive functionality, excessive permissions, and excessive autonomy. Its mitigations include a rule to “require a human to approve high-impact actions before they are taken” and “complete mediation”, meaning authorization is enforced downstream, not left to the model. The OWASP Top 10 for Agentic Applications, published in December 2025, adds ASI03, Identity and Privilege Abuse: exploitation of delegated credentials and authority.

Regulators see the same gap. The UK FCA’s 2026 payments priorities commit to considering “whether change or development of regulation is needed to support agentic AI payments”.

The answer the industry is converging on is a third option: the agent holds its own key, and that key carries a bounded, revocable grant.

How it works: the standards

Ethereum now has a stack for this.

Standard or product	What it does	Status
ERC-7579	Modular smart accounts. Four module types: validation (1), execution (2), fallback (3), hooks (4). An executor is “a module that can execute transactions on behalf of the smart account via a callback”. Hooks run `preCheck` before and `postCheck` after execution.	Draft
ERC-7710	Interfaces for “delegating capabilities to other contracts or EOAs”. A delegate calls `redeemDelegations` on a Delegation Manager, which checks the grant and executes.	Draft
ERC-7715	A wallet RPC, `wallet_requestExecutionPermissions`, for apps to request scoped permissions. Includes an `ExpiryRule` and `wallet_revokeExecutionPermission`.	Draft
MetaMask Advanced Permissions	Implements ERC-7715 requests redeemed through ERC-7710. A dedicated session account acts for the user, for example spending up to 10 USDC per day for a month.	Shipping in the Smart Accounts Kit
Coinbase Agentic Wallets	Launched February 2026. Session and per-transaction spending limits. Keys stay in Coinbase infrastructure, not in the agent’s prompt or model.	Shipping
AP2	Google’s Agent Payments Protocol, announced September 2025 with more than 60 partners. Mandates are signed as verifiable credentials.	Published protocol

AP2 separates three mandates, per its specification:

Intent Mandate. Signed by the user for purchases made while the user is not present. It carries shopping parameters, authorized payment method categories, and an expiry.
Cart Mandate. Signed by the user when present. Google describes it as “a secure, unchangeable record of the exact items” and the amount.
Payment Mandate. Shared with networks and issuers. It signals that an agent is involved and whether the human was present.

The pattern across all of these is the same. The agent gets its own key. The grant is scoped by target, asset, amount, and time. Enforcement happens in code the agent cannot rewrite. The human can revoke.

What Revolution V2 does

Revolution names this layer with two terms that sit side by side.

Nomen (name) tells the network what you’re called. Sigillum (verified identity) proves who you are. Potestas (permissions) determines what you’re permitted to do. Mandatum (delegated authority) defines the authority you delegate. Agens (agent) acts within it.

Built versus specified

Component	Status
ERC-4337 EntryPoint v0.8 at its canonical address	Built on the devnet
ERC-7579 Nexus smart accounts	Built on the devnet
Cornerstone Paymaster for free cornerstone calls	Built on the devnet
Identity gate	Built as an allowlist, pending the registry
Session executor and policy hook modules	Phase 2
ERC-7710 policy adapter	Phase 2
Agent Identity Registry	Phase 2
Mandate Anchor and proof of intent	Phase 3

Virtus (V2 testnet) is not live. Nothing below has users yet.

The boundary: Potestas (permissions) versus Mandatum (delegated authority)

The whitepaper fixes the line between the two.

Potestas (permissions) is what a principal may do. It comes from the Sigillum (verified identity) level and the account class. The policy hook enforces it.
Mandatum (delegated authority) is what a principal delegates to one Agens (agent). It comes in two forms: standing and transaction.

The Agent account class holds no Potestas (permissions) of its own. It acts only under a Mandatum (delegated authority).

The standing Mandatum (delegated authority)

The standing Mandatum (delegated authority) is the parent’s signed policy for one Agens (agent). It is stored off chain. Its hash sits in the agent’s identity record. It can never exceed the parent’s Potestas (permissions). Minimum fields:

Field	Purpose
Spend cap per transaction	Bounds any single payment
Spend cap per period	Bounds total spend over a window
Allowed categories	Limits what the Agens (agent) may buy
Counterparty allowlist (optional)	Limits whom it may pay
Human-approval threshold	Above this amount, a human signs
Expiry	The grant ends on its own
Kill switch	The parent stops it at once

The transaction Mandatum (delegated authority)

A transaction Mandatum (delegated authority) is the human’s signed authorization for one purchase. It must fall inside the standing Mandatum (delegated authority). V2 uses the AP2 structure of Intent, Cart, and Payment Mandates, held off chain as verifiable credentials. The Mandate Anchor records keccak256(mandate) with the agent identity and expiry. An auditor with the mandate can verify it. Anyone else learns only that an anchor exists. A zero-knowledge proof of purchase intent shows the merchant that the category, counterparty class, and amount fall inside the bounds. The merchant does not learn the budget.

Enforcement: session key, executor, policy hook

An Agens (agent) never holds the owner’s key. It holds a session key through an executor module. On every call, the policy hook checks:

target contract
selector (the function called)
asset
amount
rate
expiry

A call outside the Mandatum (delegated authority) fails. The same caveats map to ERC-7710 delegations, so compatible wallets can issue a Mandatum (delegated authority) without Revolution-specific tooling.

Four rules

A Mandatum (delegated authority) never exceeds the Potestas (permissions) of the principal who grants it.
A Mandatum (delegated authority) is always revocable.
An Agens (agent) has no authority of its own. Every action traces back to a Sigillum (verified identity).
Agents cannot create agents.

Threat model

Threat	Mitigation in the whitepaper
Compromised agent key	Policy caps, parent kill switch, key rotation, human-approval threshold
Compromised parent key	Smart account recovery; RNS suspension of the parent and all children
Prompt injection via offers	Offers are structured records with hashed terms; free text excluded
Module risk in accounts	Curated modules; audited account base; no delegatecall in sponsored paths
Sybil farming of free calls	Identity gate with verified parent; per-identity allowance; cost cap per operation

Read the Grok case against this table. Under this design, a per-transaction cap and a human-approval threshold would bound the loss. The standing Mandatum (delegated authority) is signed by the parent and its hash is on chain, so nothing the agent receives can raise its limits. The kill switch ends the grant in one call.

What it means for builders

The SDK uses the vocabulary with plain-English aliases: revo.agens is also revo.agents, and revo.mandatum is also revo.delegation. The snippet below is illustrative.

// Proposed SDK, subject to change.

// Create an Agens (agent) under your Nomen (name), e.g. shopping.rob.revo.
// The options form its standing Mandatum (delegated authority).
const shopper = await revo.agens.create(nomen, "shopping", {
  spendCapPerTx: "200 USDC",
  spendCapPerPeriod: "1000 USDC",
  period: "30d",
  categories: ["groceries"],
  humanApprovalAbove: "150 USDC",
});

// Revoke the Mandatum (delegated authority). Revocation is permanent.
await revo.mandatum.revoke(shopper.mandatum);

Three practical points.

Design for the cap, not the prompt. Assume the model will be manipulated. The policy hook is the control that holds.
Set the human-approval threshold low at first. In the snippet, anything above 150 USDC goes to the human even though the per-transaction cap is 200 USDC.
Treat revocation as normal. A revoked Agens (agent) keeps its history under the parent. Create a new one with a new Praenomen (agent name) when you need it.

For users, the model is simple. You keep your key. Each Agens (agent) gets a budget, a scope, an expiry, and an off switch.

What is next

Phase 2 delivers the session executor, the policy hook, the ERC-7710 policy adapter, passkey sign-in, and the Agent Identity Registry. The identity gate then moves from the allowlist to the registry. Phase 3 adds the Mandate Anchor, proof of intent, and settlement with escrow. ERC-7579, ERC-7710, and ERC-7715 are all still Draft, and the whitepaper commits to tracking changes against the audited Nexus implementation. Every contract receives an independent audit before mainnet.

The industry agrees that agents should not hold your keys. The work now is to make the grant precise, checkable on chain, and revocable by the person who signed it. That is what Mandatum (delegated authority) is for.