API Key security
This page documents recommended practices for storing, rotating, and revoking Cryptohopper MCP API keys. The advice applies to any environment where the MCP is used — local workstations, CI systems, agent deployments, and third-party MCP clients.
What an MCP key grants
A Cryptohopper MCP API key is a bearer token that authenticates requests against a single Cryptohopper account.
| What the key can do | What the key cannot do |
|---|---|
| Read market data (tickers, orderbooks, candles) at the tier's permitted level | Access Cryptohopper bots |
| Query usage and quota for the account | Place trades or modify positions |
| List supported exchanges and pairs | Access the account interface |
| — | Authorise Cryptohopper Trading API calls |
Keys are read-only. A compromised MCP key does not allow an attacker to trade. It does, however, allow quota consumption, which can disrupt legitimate workflows.
See account overview for the relationship between keys, account, and subscription.
Storage
Keys should be treated as secrets. Standard secret-handling practices apply.
Recommended
- Store keys in a dedicated secrets manager (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault, or equivalent).
- Read keys from environment variables at runtime. Prefer environment variables over config files committed to source control.
- Scope file permissions: client config files containing keys should be readable only by the owning user.
- Use per-client config files (~/.config/...) rather than system-wide locations.
Not recommended
- Committing keys to git repositories, even in private repositories.
- Pasting keys into chat messages, issue trackers, or support conversations.
- Sharing keys across developers or machines. Create a key per consumer instead.
- Storing keys in plain-text files in cloud-synced folders (e.g. Dropbox, iCloud Drive) without additional encryption.
If a key is accidentally committed to git, revoke it immediately and generate a new one. Git history is durable and assumed compromised.
Rotation
Rotating keys — revoking an old key and issuing a new one — is the defensive mechanism that limits the blast radius of a compromise.
Suggested cadence
| Context | Rotation cadence |
|---|---|
| Personal workstation, local MCP client | Every 90 days |
| Scheduled workflow in CI / cloud | Every 60 days |
| Shared across multiple environments | Every 30 days |
| Key with any history of exposure (committed to repo, pasted in chat, etc.) | Immediately, then every 30 days |
The tier's key allowance determines how many keys can exist simultaneously. See subscription tiers.
Rotation procedure
- Generate a new API key in the Cryptohopper account interface.
- Deploy the new key to all consumers (MCP clients, CI secrets, agent configs).
- Verify each consumer is using the new key by issuing a test query.
- Revoke the old key from the Cryptohopper account interface.
Keys are independent. Revoking one does not affect others.
Key segmentation
Where the tier allows more than one key (Adventurer: 3 keys; Hero: 10 keys), use them to segment usage.
Suggested segmentation patterns
- One key per agent. Each distinct AI agent gets its own key. If one agent misbehaves and consumes excessive quota, it can be identified and throttled without affecting the others.
- One key per environment. Separate keys for production, staging, and development. Revoking or rotating the development key leaves production untouched.
- One key per user. On a small team, one key per team member provides attribution for quota usage and enables individual revocation when a team member leaves.
Remember that all keys share the account's single weekly quota. Segmentation is for attribution, revocation, and throttling — not for quota expansion.
Revocation
Revoke a key when:
- The key has been exposed (committed to a repository, sent via an unencrypted channel, present on a lost or stolen device).
- A consumer no longer needs access (decommissioned workflow, departed team member).
- As part of scheduled rotation.
Revocation through the Cryptohopper account interface takes effect immediately. Subsequent requests using the revoked key return UNAUTHORIZED. See error reference.
Defence in depth
Beyond basic hygiene:
- Network restrictions. If your MCP client runs in a fixed environment (CI runner, production server), consider restricting outbound traffic to mcp-data.cryptohopper.com specifically.
- Audit logs. Maintain local logs of which key performed which action. Matching MCP usage patterns against Cryptohopper's per-account usage telemetry helps detect anomalies.
- Monitor usage. A sudden spike in call volume is often the first sign of a compromised key. See usage and limits.
- Separate from Trading API credentials. The Cryptohopper REST Trading API uses separate credentials. Do not co-locate MCP keys and Trading API credentials in a single unencrypted file — a compromise of one should not implicate the other.
Incident response
If a key is suspected of being compromised:
- Revoke immediately. Do not wait to confirm. The cost of an unnecessary revocation is minor; the cost of a delayed revocation is quota consumption, and — if the key is paired with Trading API credentials in the same compromise — potentially more.
- Check usage. Query the usage endpoint to look for anomalous patterns in the current cycle. Document anything suspicious.
- Review the source of exposure. Understand how the key was exposed. A leaked key is often a symptom of a broader control gap.
- Rotate adjacent credentials. If the same environment held Trading API credentials, rotate those as well.
- Generate a new key and redeploy to consumers.
