Skip to main content

​
What does non-custodial mean?

Mandate never holds, accesses, or stores private keys. All transaction signing happens locally on the agent’s machine. Mandate validates the intent (what the agent wants to do and why), not the execution (signing and broadcasting). The private key stays with the agent throughout the entire lifecycle of every transaction. This is not a theoretical claim. The Mandate API has no endpoint that accepts a private key. The validate endpoint receives action metadata, a reason string, and optionally a destination address and amount. The validate/raw endpoint receives unsigned transaction parameters and an intent hash. Neither endpoint requires or accepts key material.

​
How does Mandate compare to other models?

AspectCustodial WalletSession KeyMandate
Who holds the key?Service providerDelegated signerAgent (local)
What if service is compromised?Funds at risk, direct theft possibleLimited risk within delegation scopeNo key exposure, no fund access
What does the service check?N/A (provider controls funds)Signature validity + spend limitsIntent + reason + 14 policy checks
Can the service steal funds?YesLimited (within delegated permissions)No (no key access, ever)
Detects prompt injection?NoNoYes (18 patterns + LLM judge)
Audit trail includes “why”?NoNoYes (reason field on every transaction)
Custodial wallets give the service provider full control over funds. If the provider is compromised, the attacker has direct access to sign and broadcast transactions. Session keys limit the scope of delegation, but the delegated signer can still act within its permissions without explaining why. Mandate adds the intent layer: even within policy limits, the agent must state its reason, and that reason is scanned for manipulation.

​
What is the validation flow?

The non-custodial flow has four steps. The agent builds the transaction, asks Mandate for permission, signs locally, and reports the result.
  1. Validate: Agent sends transaction details to POST /api/validate. Mandate evaluates 14 policy checks and returns allowed, blocked, or approval_required.
  2. Sign locally: If allowed, the agent signs the transaction with its own private key. Mandate is not involved in this step.
  3. Broadcast: The agent sends the signed transaction to the blockchain. Mandate is not involved in this step.
  4. Post event: The agent reports the transaction hash to POST /api/intents/{id}/events. Mandate fetches the on-chain transaction and verifies it matches what was validated.
Step 4 is the envelope verification. If the on-chain transaction does not match the validated parameters (different recipient, different amount, different calldata), Mandate trips the agent’s circuit breaker and marks the intent as failed. This catches attempts to validate one transaction but broadcast a different one.

​
Why does this matter for AI agents?

AI agents are high-value attack targets. They hold private keys, execute transactions autonomously, and process untrusted inputs from users, tools, and web content. A compromised agent with a custodial wallet means total fund loss. With Mandate’s non-custodial model, a compromise of the Mandate API does not give the attacker signing capability. The attacker could at most disable validation (which the agent detects as an unreachable API and halts per fail-safe rules) or return false allowed responses. Even false positives from a compromised API cannot produce signed transactions: the agent still signs locally, and the envelope verifier catches parameter mismatches after broadcast. The attack surface is fundamentally different. Mandate validates intent. The agent controls execution. Neither party has the other’s capabilities.

​
Next Steps

Threat Model

Detailed analysis of attack vectors and how Mandate mitigates each one.

How It Works

End-to-end walkthrough of a validated transaction.

Architecture

System architecture and backend service overview.

Intent Hash

How the intent hash binds validation to execution.