Skip to main content
A runtime key is the authentication token your agent uses to call the Mandate API. It is issued during agent registration and must be stored securely. Compromised keys allow an attacker to submit transactions on behalf of your agent (though policy enforcement still applies).

​
How should you store runtime keys?

The recommended approach is an environment variable: 
export MANDATE_RUNTIME_KEY="mndt_live_abc123..."
For file-based storage, use a dedicated credentials file with restricted permissions: 
# ~/.mandate/credentials.json
chmod 600 ~/.mandate/credentials.json
Three rules to follow:
  1. Never commit keys to git. Add credentials.json and .env to your .gitignore.
  2. Never hardcode keys in source code. Even in private repositories, hardcoded keys end up in build artifacts, logs, and error reports.
  3. Never share keys across agents. Each agent gets its own runtime key. Sharing keys makes revocation impossible without disrupting multiple agents.

​
What do the key prefixes mean?

The prefix tells you the key’s environment and which chains it can access:
PrefixEnvironmentChains
mndt_test_*TestnetSepolia, Base Sepolia
mndt_live_*ProductionEthereum, Base
A testnet key cannot authorize transactions on production chains, and vice versa. Use testnet keys during development and switch to production keys only when deploying.

​
How do you rotate a runtime key?

Rotate keys through the dashboard or the API:
  • Dashboard: Navigate to Agents, select the agent, click “Regenerate Key.”
  • API: POST /api/agents/{agentId}/regenerate-key (requires dashboard auth, not runtime key auth).
When you regenerate a key, the old key is revoked immediately. The agent must be updated with the new key before it can make any further API calls. Plan for a brief downtime window or implement hot-swapping in your agent’s configuration.

​
What should you do if a key is compromised?

Regenerate the key immediately. The old key becomes invalid the moment the new one is issued. Any in-flight intents (transactions already validated but not yet confirmed) continue to their terminal state. New validation requests with the old key are rejected. After regeneration:
  1. Update the key in your agent’s environment.
  2. Review the audit log for unauthorized transactions made with the compromised key.
  3. Check whether the circuit breaker should be tripped while you investigate.
Even with a compromised runtime key, the attacker cannot bypass policy enforcement. Spend limits, allowlists, and approval workflows still apply. The non-custodial model means the attacker also cannot sign transactions without the agent’s private key.

Register an Agent

Get your first runtime key

Chain Reference

Supported chains and contract addresses

Agent Management

Manage agents from the dashboard