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

1. Generate a new API key in the Cryptohopper account interface.
2. Deploy the new key to all consumers (MCP clients, CI secrets, agent configs).
3. Verify each consumer is using the new key by issuing a test query.
4. 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:

1. 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.
2. Check usage. Query the usage endpoint to look for anomalous patterns in the current cycle. Document anything suspicious.
3. Review the source of exposure. Understand how the key was exposed. A leaked key is often a symptom of a broader control gap.
4. Rotate adjacent credentials. If the same environment held Trading API credentials, rotate those as well.
5. Generate a new key and redeploy to consumers.