# The Keys to Your Kingdom Are Sitting in an AI Config File
The attacker didn't need a zero-day. They needed a text editor and access to a directory where someone had dumped an MCP server configuration six weeks ago. Inside: a service account token with read access to the company's internal documentation, write access to its cloud storage buckets, and full permissions on the Slack API that the AI agent used to surface answers to employees.
This isn't a hypothetical. It's the logical endpoint of where enterprise AI deployment is right now — and the security implications are only beginning to register.
## What MCP Actually Is (And Why It Changes the Threat Model)
The Model Context Protocol is an open standard, originally designed by Anthropic, that lets AI assistants connect to live systems instead of being limited to whatever the model already knows. Want your AI agent to pull a support ticket, query a database, or push a configuration change? MCP is the bridge.
The MCP *server* is where it gets interesting for attackers. That small middleware program — sitting between the AI and whatever enterprise system it's reaching into — needs credentials to do anything useful. So it holds them. API keys, OAuth tokens, service account credentials, database passwords: everything the agent needs to act is sitting inside the MCP server, usually in a configuration file, often in plaintext.
This is the part that isn't getting enough attention in the breathless AI adoption coverage: we've taken the credential problem that plagued cloud deployments for years and handed it to a new layer of infrastructure that most security teams have zero visibility into.
## The Plaintext Problem Is Worse Than It Sounds
Configuration files with embedded secrets are not a new failure mode. Every security team has lived through at least one incident involving a .env file committed to a public GitHub repo or an AWS access key baked into a Docker image. The industry learned — slowly, painfully — to treat those patterns as unacceptable.
MCP servers are relitigating that lesson from scratch.
The setup experience for most MCP servers involves pasting a JSON configuration block that contains the credentials inline. It's the easiest way to get something working, so it's what developers do. That config file then lives on a development machine, gets copied to staging, gets checked into a repository alongside the code, or ends up on a shared server where the AI agent runs continuously. Security teams — if they're even aware the MCP server exists — are rarely auditing these files.
The sprawl compounds quickly. Because there's no central credential store for most MCP deployments, every agent manages its own secrets. The same API token appears in three different config files across dev, staging, and production. Nobody rotates them because nobody has a complete inventory of where they live.
Long-lived, static, widely-copied credentials are exactly what attackers want.
## Prompt Injection: A Different Class of Problem
The credential exposure risk is bad. Prompt injection is philosophically different and potentially more dangerous.
Traditional attacks require reaching the system. Prompt injection lets attackers reach into the system by poisoning the data the AI agent reads.
Here's the mechanic: an AI agent with MCP access reads a support ticket, a document, a webpage. An attacker has hidden instructions in that content — carefully worded text that the model treats as legitimate commands. The agent, unable to reliably distinguish between data and instructions, follows them. It might exfiltrate the API keys it holds. It might use its tool access to modify records. It might use the Slack integration to send messages under legitimate employee identities.
The attacker never touched the MCP server. They just put text somewhere the AI would eventually read.
This is not a theoretical attack. Prompt injection against LLM-based systems has been demonstrated repeatedly over the past two years. As AI agents gain real tool access through MCP — as they go from answering questions to *taking actions* — the blast radius of a successful prompt injection escalates dramatically. A prompt injection that tricks a chatbot into saying something wrong is embarrassing. One that tricks an agent with cloud infrastructure access is an incident.
## When AI Agents Become Non-Human Identities
The security community has been grappling with Non-Human Identities — the service accounts, API keys, and tokens that proliferate across modern infrastructure — for years. MCP accelerates the problem.
An AI agent operating through MCP isn't just a tool that produces text. It's an identity. It authenticates to systems, it makes API calls, it creates and modifies data. Every action it takes leaves a trail attributable to whatever service account it's using. If an attacker compromises the credentials the MCP server holds, they don't just read data — they *become* the agent, inheriting its access to every connected system.
This is why the over-permissioning problem matters so much here. AI developers, trying to make their agents capable, grant them broad access. The agent needs to read documents, so it gets access to the entire document store. It needs to call one API, so it gets an API key that works across all endpoints. Least-privilege is an afterthought when the primary goal is making the demo impressive.
The result is agents operating as highly-privileged identities, holding credentials for multiple systems, with no human monitoring what they're actually doing.
---
## HackWire Analysis
The MCP security story is getting covered as a credential management problem. That framing is correct but incomplete — and the incomplete part is where defenders are most likely to get burned.
The deeper issue is governance velocity. MCP servers are being deployed by individual developers, data teams, and product engineers who don't route through security review. They spin up in an afternoon. They connect to production systems the same week. Security teams find out about them during an audit, or after an incident. This is the exact dynamic that created shadow IT in the cloud era, and the enterprise is making the same mistake, faster.
The prompt injection risk also tends to get classified as an "AI problem" rather than a security problem, which means it lands on ML teams who don't have threat modeling experience, rather than on security teams who do. That ownership gap is exploitable.
For defenders, the practical priority list should look like this: inventory first. You cannot protect MCP servers you don't know exist. Build a discovery process — scan for MCP server patterns in codebases, query your cloud environments for the service accounts typically used by AI tooling, and make MCP deployment a trackable event the same way new cloud accounts are.
Secrets scanning second: integrate MCP config files into whatever secrets scanning pipeline you already run. Most organizations have this capability; they just haven't extended it to AI infrastructure.
Privilege auditing third: treat MCP service accounts as the high-value targets they are. Audit their permissions quarterly at minimum. Rotate their credentials on a schedule. Assume breach and ask what an attacker would do with that access.
The broader pattern here mirrors early cloud credential incidents, early container security failures, and early OAuth token sprawl — all cases where a genuinely useful new capability was adopted faster than the security model could catch up. MCP will produce the same class of incidents unless teams get ahead of it now. Most won't.
— HackWire Editorial
---
## Related Coverage