> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mandate.md/llms.txt
> Use this file to discover all available pages before exploring further.

# Credential Management

> Best practices for storing, rotating, and revoking Mandate runtime keys.

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:

```bash theme={null}
export MANDATE_RUNTIME_KEY="mndt_live_abc123..."
```

For file-based storage, use a dedicated credentials file with restricted permissions:

```bash theme={null}
# ~/.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:

| Prefix        | Environment | Chains                |
| ------------- | ----------- | --------------------- |
| `mndt_test_*` | Testnet     | Sepolia, Base Sepolia |
| `mndt_live_*` | Production  | Ethereum, 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.

<CardGroup cols={3}>
  <Card title="Register an Agent" icon="user-plus" href="/guides/register-agent">
    Get your first runtime key
  </Card>

  <Card title="Chain Reference" icon="link" href="/reference/chain-reference">
    Supported chains and contract addresses
  </Card>

  <Card title="Agent Management" icon="robot" href="/dashboard/agents">
    Manage agents from the dashboard
  </Card>
</CardGroup>