A Mandate is an AI agent’s spending rulebook. It defines the limits within which the agent can act autonomously — anything outside those limits is denied at the protocol level.

Think of a Mandate as a corporate spending policy that the network enforces, not the agent’s own code.

Three limit types

Every Mandate carries three limit fields:

Each is independently optional. A mandate with only a monthly limit allows any single transaction up to the monthly cap.

Authorization flow

When an agent wants to perform an action, it calls Authorize first. The mandate decides yes or no.

On success, the agent receives a one-time authorization JWT — a token proving the mandate consented to this specific amount at this specific moment. The jti (JWT ID) is recorded in every subsequent audit event so the on-chain authorization trail is observable.

Why on-chain

The mandate ID, agent binding, and limit values are also written to Solana via the MandateRegistry program. Like AgentID anchoring, this is for tamper-evidence:

• An auditor can confirm the mandate’s limits at the time of any disputed action
• A compromised Regent database cannot retroactively widen limits
• A regulator can verify the mandate existed and was bound to the right agent

Atomic enforcement

Daily and monthly counters use Redis INCRBYFLOAT with rollback on rejection, ensuring no race conditions under concurrent authorization calls. Two simultaneous authorizes that would each fit alone but exceed the limit together are correctly handled — only one succeeds.

Lifecycle

Standard rejection codes

The full error format is documented in REST API → Errors.

Related