MCP API Key Management: Issue, Scope, Rotate, Revoke

Manage MCP API keys by issuing one key per agent or machine, scoping each to the fewest tools it needs, storing it in a secrets manager, rotating on a schedule and after any exposure, and revoking at once when a caller is retired. A key is a credential for your workspace, so treat it like a database password.

Why keys deserve their own process

In many MCP setups the Bearer key is the perimeter. Whoever holds it can act as the workspace it belongs to. BusinessMCP’s documentation says this plainly: the key identifies the workspace the caller acts as, and anyone holding it can act as that workspace. That sentence applies to almost any key-based gateway.

Keys also tend to multiply. One for a laptop, one for a script, one for a demo, one for a contractor. Without a process, nobody can say which are still in use.

Key takeaway: a key you cannot attribute to a named owner and purpose is a key you should revoke.

The lifecycle

Stage	What to do	Common failure
Issue	Create one key per agent, machine or integration	One shared key “for convenience”
Scope	Attach a policy with only the needed tools	Full access by default
Store	Put it in a secrets manager or protected client config	Pasted into chat, wikis or repos
Use	Send it in the Authorization header over HTTPS	Passed in URLs, which end up in logs
Monitor	Watch usage per key	Nobody looks until something breaks
Rotate	Replace on schedule and after exposure	Keys that live for years
Revoke	Disable immediately when retired	Departed staff keep working keys

Issuing: one key, one owner, one purpose

Record three things for each key at creation: who owns it, what it is for and when it should be reviewed. BusinessMCP’s guidance for exposing an MCP endpoint says the key is shown only once, so copy it into your secrets store immediately, and recommends issuing a separate key for each agent or integration so they can be revoked independently.

A simple inventory table is enough:

Key name	Owner	Purpose	Tools	Review date
report-agent-prod	Growth team	Weekly summary	Read-only analytics	Next quarter
desktop-alice	Alice	Personal assistant use	Read plus drafts	Next quarter
ci-smoke-test	Platform	Endpoint health check	One read tool	Next quarter

Scoping: where most of the safety comes from

A leaked key with a narrow scope is an incident. A leaked key with full access is a disaster. Use your platform’s policy features to restrict each key. Access presets, per-connection allowlists and data classes, where offered, let you shrink the reachable set. BusinessMCP’s catalogue of MCP gateway tools shows how scoping can be presented: each tool scoped by the key, read-only keys unable to reach write tools, and approval-gated actions that wait for the owner. Whatever platform you use, build the allowlist before you hand out the key.

Storing: keep it out of the places keys leak

The most common leaks are mundane:

• A config file committed to a repository.
• A key pasted into a chat to ask for help.
• A screenshot of a terminal or settings page.
• A shared document of “useful setup steps.”
• A client config file in a synced folder anyone can read.

BusinessMCP’s documentation lists “do not commit mcph_ keys to source control” among your responsibilities. A recognisable prefix helps, because secret scanners can search for it. Enable secret scanning on your repositories and add the prefix pattern if your tool supports custom patterns.

Using: always over HTTPS, always in a header

Send keys in the Authorization header. Never put them in a URL query string, because URLs are logged by proxies, browsers and servers. Use HTTPS only. For desktop clients, the config file is the weak point, since it stores the key in plain text; protect the file and use a dedicated key per machine. Our Claude Desktop connection guide shows where the key goes and what to avoid.

Monitoring: usage per key

Per-key usage is a cheap early warning. Watch for:

1. A key that has not been used in months, which is a candidate for revocation.
2. A sudden spike in calls.
3. Calls to tools outside the key’s normal pattern.
4. Refused calls, which show attempts beyond scope.
5. Use at unusual times or from unusual places, where visible.

All of this depends on logging with caller identity, which we cover in MCP audit logging.

Rotating

Rotation reduces how long a stolen key is useful. A workable approach:

1. Create the new key with the same policy.
2. Deploy it to the caller.
3. Confirm the caller works with the new key.
4. Revoke the old key.
5. Update the inventory.

Do this on a schedule that fits your risk, and immediately when someone with access leaves or a key may have been exposed. Rotating upstream credentials, such as an API key for a connected system, is a separate task. If those are held in the gateway’s vault, rotate them there and never in client config.

Revoking and the leak drill

Practise the leak response before you need it.

Step	Action
1	Revoke the key. Verify the next call fails.
2	Pull the log for that key since it was issued.
3	List every tool it could reach and what data those touch.
4	Rotate upstream credentials if any could have been exposed.
5	Notify owners and, if personal data may be involved, your compliance contact.
6	Fix the cause: remove the key from the repo, change the process, add scanning.
7	Record what you learned and update the inventory template.

Run this once as a drill with a test key. If you cannot complete step 2 quickly, your logging is not good enough.

BusinessMCP also documents its access control model, which is worth reading if you want to see how presets and per-key policies can be described to administrators.

Mistakes to avoid

• Sharing a key between agents, which erases accountability.
• Relying on obscurity. A long random key is not a policy.
• Skipping revocation on offboarding. Add key review to your leaver checklist.
• Assuming OAuth removes the problem. Tokens still need scopes, expiry and revocation.
• Giving contractors your personal key.

Key hygiene works best alongside the wider baseline in MCP gateway security. Treat it as a routine job, not a one-off setup task.