Why agent credentials leak

Agent credentials leak through four distinct paths, and only one of them is an attacker. Knowing which path you are exposed to tells you which fix matters.

Most advice about leaked keys assumes a hostile actor got past your perimeter. For agent configurations, that is often the fourth most likely cause. Here is the honest ordering.

1. You put it in a support channel

By a wide margin this is the most common. It happens when something does not work, and the fastest path to an answer is to paste the config somewhere a competent stranger can read it.

It works fine right up until the moment it doesn’t, because by then the credential is in someone else’s training data, someone’s issue tracker, someone’s chat history, and possibly a public archive. No amount of revocation later undoes the copy that already happened somewhere you cannot see.

2. Git, at a moment you will not remember

Less dramatic, far more persistent. .mcp.json and claude_desktop_config.json are exactly the filenames that people add to a project directory “temporarily”, then forget, then commit three weeks later along with a feature.

The nasty property of git is that deleting the file in a later commit does not remove it. The object is still in history, still reachable by anyone who cloned the repo, and still present on any fork. Removing a secret from git is not a deletion, it is an announcement that you had one.

The rule

Add the config filename to .gitignore before you ever create it, not after the first accidental commit. And if you have already committed one, treat the credential as compromised and rotate it — do not rely on history rewriting as a fix.

3. A published skill, package, or template

This is the path that catches other people. The audit that found 7.1% of published skills storing plaintext credentials was measuring a supply chain, not individual mistakes.

When you install a skill or an MCP server from a registry, that package can ship a config file, an env block with your values already filled in, or a setup script that reads your existing config and posts it somewhere. The npx-based distribution model makes this worse, because the code that runs is not pinned to a version you reviewed.

What is actually being installed

Ask three questions of any agent extension before you trust it:

• Does it need credentials that are not already in my config? If it needs a new token, that token is probably scoped too broadly.
• Is the version pinned? npx -y package with no version means whatever the registry serves today runs with my permissions.
• Does its setup script read my existing config file? If yes, it has everything, regardless of what the README claims it uses.

4. The agent itself, told to hand it over

The genuinely new one, and the one people are not ready for.

An agent reads untrusted text as part of doing its job: web pages, issue threads, documentation, code comments. It is very good at following instructions found in those places, because that is what makes it useful. It cannot reliably tell the difference between an instruction from you and an instruction from a blog post it fetched.

So a single paragraph in a README can ask your agent to include its environment in the answer. Depending on the client’s permission model and how the server is scoped, that request may simply succeed.

Which one is likely to hit you

If you write agent configs and have ever posted in a forum, it is path 1. If you work in a team that shares configs, it is path 2, and you will not find out which commit it was in. If you install third-party servers or skills, it is path 3, and the blast radius is other people’s setups. If you point an agent at untrusted content — which is most of the useful things agents do — it is path 4, and it is a matter of when.

All four are addressable, but they are addressed by different things. The next page covers the one that matters most once it has already happened.

What to do when MCP credentials leak →