In short
Many MCP configuration files contain hand-written keys that scanners don't see, with broad permissions and no expiry. We explain what the data says, why the file is sensitive even without keys and how to connect your AI safely.
In this article
In short
Writing the key as-is into your MCP server's configuration file is the riskiest option, and it is common: in around 82,000 public files, 1 in 8 credential slots had the key written in. The safe approach is to take it out of the file, give it just the right permissions and be able to revoke it.
What is that file and why does it have keys?
When you connect Claude, Cursor or Codex to other tools through MCP, a configuration file tells it which servers to connect to and how to identify itself. That's usually where an API key or token goes: the key to your GitHub, your database or your Notion.
Unlike a .env, these files are meant to be shared and uploaded to the repository. If the key is inside, it travels with it.
What does the data say?
Hush Security reviewed around 82,000 public MCP configuration files on GitHub (press release of 17 September 2026). These are its findings, which Help Net Security also reports:
- 12% of credential slots had the key written directly into them.
- 55% of those keys have no recognisable format, so secret scanners don't detect them.
- 53% of those with an identifiable scope open up a whole organisation, account, workspace or database, and 80% of those with an expiry policy don't expire by default.
- Of 7,681 configurations with credentials whose history they reviewed, 243 had deleted the key from the file, but it was still readable in the Git history.
Hush clarifies that these are minimum figures.
What if the key isn't in the file?
Better, but not enough. Flare analysed real leaks (7 October 2026) and found 2,327 MCP configurations; only 96 contained a usable secret. Even so, the file works like a map: it says which services your agent reaches and which variable holds each key. Credential-stealing malware also takes those variables from the computer, so it gets both halves.
How do you make it safe?
- Don't write the key into the file. Use environment variables or a secret manager.
- If a key ever got uploaded, rotate it. Deleting the line doesn't remove it from the history.
- Ask for just the right permissions. The official MCP security guide recommends starting with a minimum scope: a stolen token with broad permissions opens everything.
- Prefer access that expires. If the server supports OAuth instead of a fixed key, use it: access can be revoked without touching the file.
- Treat the file as sensitive, even without keys, and review which local servers you install: the official guide reminds you that they run with the same privileges as your assistant.
How do we see it at Traiker?
At Traiker we worry about the same thing from the other side: what happens to your data when an assistant connects to it. Each person or company has their own encrypted database, and your data is yours: we don't train models on it or process it. The idea is for your assistants to query your data without spreading copies or lifetime keys.
If you're thinking about what to share with your AI, review how to give your data to an AI without losing control and who owns your agent's memory.
Frequently asked questions
Is it safe to use MCP?
Yes, if you control which servers you install, what permissions you give them and where you store the keys. The risk usually lies in keys with too much scope that never expire.
Is making the repository private enough?
It helps, but the key is still in the history and in every copy. The safe thing is not to store it there.
What do I do if I have already uploaded a key?
Revoke it on the service and create a new one. Then replace it with an environment variable in the file.
If you want your assistants to work with your data in a safe place of your own, sign up for the Traiker beta.
