What to do when MCP credentials leak
The order of operations matters more than the technique. Rotating the wrong thing first wastes the only window you have.
Assume a credential from your agent config is in someone else’s hands. The scanner above tells you which ones are still literal strings — those are the exposed set. Work through this in order.
First hour: rotate, do not investigate
The instinct is to look at logs and figure out what was used before you cancel anything. Resist it. Every minute the credential is live is another minute of possible use, and the log analysis is worth nothing if the key is still valid while you read it.
1. Revoke at the provider, not in your config
Edit your config file first and you have accomplished nothing — the attacker is not using your file. Go to each provider’s console and revoke the credential there.
Order matters if credentials are nested. If a model key appears in a provider that bills through a cloud account, revoke the cloud key first, because a live model key can regenerate access.
2. Issue replacements with the narrowest scope that works
This is the moment to fix the scope problem, not just refill the bucket. A GitHub token that only needs to read one repository should not be able to write to your org. A database credential for a read-only agent should be read-only.
If you later find that the narrow scope breaks the agent, widen it deliberately, knowing what you gave up. Do not start wide “to avoid another rotation cycle” — that is how you end up back here.
3. Write the new values to your shell, not to the file
Move them into your shell profile or a secret store, and reference them as ${TOKEN} in the config. The config should have no literal secret in it, which means the next time you paste it for debugging, you are safe by default.
Within a day: establish what happened
Now, with the bleeding stopped, look at what the credential did while it was live.
Check usage, not just totals
Aggregate spend tells you whether you are being billed, which is the question most people ask. It is the wrong question. A leaked key can do serious damage at near-zero marginal cost: reading your repositories, querying your database, sending email as you, reading your issue tracker.
Look at the request log, not the invoice. What was called, from where, and at what time.
Check for things that leave traces
- Git — unexpected pushes, branches, or releases under your identity.
- Cloud — new access keys, new IAM bindings, new service accounts.
- Mail / chat — sent messages that you did not send. This one often gets missed because it does not cost money.
- CI — new pipelines, changed secrets in existing ones, or workflow runs from unfamiliar locations.
Clean the history, but treat it as cleanup
If a credential reached a git repository, rewrite the history and force-push. Then assume it is compromised anyway, because clones and forks exist that you cannot reach. Rotation is the fix; history rewriting is hygiene.
Then close the path it came through
A rotation without a fix guarantees a second incident. You now know which of the four paths it was, so the fix is specific:
- Support channel — put a redaction step in your runbook. Template configs with placeholder values that you can copy, so the path of least resistance is already safe.
- Git — add the config filenames to
.gitignore, and add a pre-commit secret scan so the next one is caught at commit time rather than audit time. - Third-party skill or package — pin the version, and re-read what that package was granted. Removing it does not revoke what it already read.
- Prompt injection — split tokens per agent and narrow their scope, so the ceiling on a successful injection is one credential rather than all of them.
The one thing worth doing anyway
Nothing above gives you a way to be certain. You cannot prove the credential was unused, only that you did not observe use. For the credentials with real blast radius — anything that can deploy, sign, or administer — the honest answer is to rotate on a schedule rather than waiting for an incident, and to keep the scope small enough that a leak is an inconvenience rather than an event.