Model Context Protocol (MCP) is the connective tissue of modern AI tooling and has quietly become one of the most significant blind spots in modern security programs. Like shadow IT before it, shadow AI — especially as it relates to MCP risk — introduces a new class of exposures that security teams lack adequate tooling to see and address. Integrating MCP risks into a Continuous Threat Exposure Management (CTEM) program can help security teams keep up by providing a structured methodology and the operational agility needed to surface MCP exposures before attackers do.

Security has always been a race between how fast the attack surface grows and how fast defenders can see it. Vulnerability Management was the first serious attempt to run that race systematically. It worked until the environment got too complex and security teams found themselves prioritizing what was loudest over what was most dangerous. CTEM is built on the same core instinct to find exposures before attackers do but better reflects the business and technical realities of modern IT environments. Most mature security programs already have the bones of it. The question with MCP isn’t whether CTEM applies. It’s whether the scope has been extended to include it.

Introduced by Anthropic in late 2024, MCP acts as the plugin architecture for agentic AI. If your team isn’t scanning for, mapping or monitoring for MCP risks, you have a blind spot that grows every time a developer installs a new tool. MCP takes “old” risks such as supply chain attacks, hardcoded credentials, privilege escalation, remote code execution and makes them new again.

Here’s how:

Shadow AI: You can’t secure what you can’t see

In 2025, researchers documented the first confirmed malicious MCP server in the wild. The vehicle was a npm package called postmark-mcp, a tool that helped developers integrate AI assistants with the Postmark email service. The attacker was patient. They published fifteen legitimate versions over time, built up roughly 1,500 weekly downloads and earned genuine trust in the developer community. Then a version shipped with a single injected line of code that BCC’d every single outgoing email to an external address.

Around 300 organizations were affected before anyone noticed. Password resets, invoices, internal memos, confidential documents — exfiltrated for weeks without tripping a single alert. The tactic mirrors the SolarWinds playbook: Establish legitimacy first, corrupt later and count on the fact that once something is trusted, it stops being scrutinized.

Enterprises have accumulated layers of governance to manage third-party software risk — procurement reviews, vendor assessments, security signoffs. The MCP ecosystem has none of that yet. Developers are pulling servers from npm the same way they pull any open-source dependency: Fast, on faith, without much thought about what happens when the tool connects to their AI agent and, through it, to internal data. That’s not a criticism; it’s a visibility problem. Visibility problems don’t get solved by policy. They get solved by knowing what’s in your environment.

Keys under the doormat: Hardcoded credentials in AI configurations

In 2023, information-stealing malware harvested more than 225,000 ChatGPT credentials. Many came bundled with API keys developers had hardcoded directly into configuration files — not out of negligence, but out of the same logic that has always driven security shortcuts: It’s faster, it works and the consequences feel abstract until they aren’t.

The more instructive scenario is simpler: A developer accidentally commits a production .env file containing API keys for OpenAI, Stripe, AWS and SendGrid. Automated bots find it within hours. Fraudulent cloud charges follow. No sophisticated attacker required — just a mistake that sat in a repository long enough for a scanner to find it.

MCP makes this structurally worse because AI agents require credentials to function. They need keys for the LLM, keys for cloud services and keys for third-party integrations. Those keys have to go somewhere the agent can reach them: Environment variables in config files, plain text in markdown instruction files or hardcoded into the server definition itself. All of it is a static plaintext target. Hackers don’t need to break in if they can just log in. The question is whether your scanning programs have been pointed at MCP server configurations, the markdown context files AI agents consume and the environment variable blocks where credentials live. Most haven’t been.

‘God mode’: When over-privileged AI agents get compromised

Running AI agents with elevated privileges is common. In 2025, researchers needed two CVEs just to start making the case. CVE-2025-6514, a remote code execution flaw in mcp-remote scoring 9.6 on the CVSS scale, was the first demonstrated full RCE on a client system through an MCP connection — triggered simply by connecting to an untrusted server. CVE-2025-49596, affecting Anthropic’s own MCP Inspector, scored 9.4 and achieved the same outcome through a chained browser exploit, giving attackers complete access to developer machines.

Beyond the CVEs, researchers found MCP servers configured with elevated privilege commands — sudo, doas, runas — baked in from the start because admin rights made development easier and nobody tightened them afterward. This pattern was documented as part of the IDEsaster research by security researcher Ari Marzouk, which catalogued over 30 vulnerabilities across Cursor, GitHub Copilot, Windsurf and others. AI IDEs had effectively removed the base software from their own threat model — existing features were treated as safe because they’d been there for years, until an autonomous agent arrived that could invoke them without asking.

If an agent in your network gets compromised, the question isn’t whether it can exfiltrate data — it’s whether it has permission to wipe a server or install ransomware. That’s a configuration question, and most organizations don’t know the answer.

How CTEM addresses this — and what it takes to get there

CTEM is the right framework not because it was designed with MCP in mind, but because it was designed for attack surfaces that expand faster than security teams can track, the five phases each have direct application here:

• Scoping requires an honest admission: The AI toolchain isn’t in scope yet, and it needs to be. That means explicitly defining developer workstations, AI coding environments and MCP configurations as assets worth protecting. It also requires early alignment with engineering leadership, because the remediation work lands on development teams and they need to understand the risk before they’ll engage.
• Discovery follows. MCP servers don’t appear in traditional asset inventories. They live in developer workstations, AI tool configurations and npm packages installed in twenty seconds — without a change ticket. Finding them means actively enumerating configured MCP servers and detecting changes between scans. A server that updates silently is the postmark-mcp scenario replaying itself.
• Prioritization means resisting the urge to flag everything and work through it linearly. The better frame is attacker impact: What can someone actually do from this exposure, and where does it connect? Risk signals like network-based transports, API keys in environment variables or instruction files, and elevated privilege commands in server definitions help separate serious problems from lower-urgency ones.
• Validation tests whether flagged exposures are actually exploitable in context, using techniques like attack path mapping and breach and attack simulation to confirm what’s real risk versus theoretical.
• Mobilization is harder than the technical work. Developers experience MCP servers as infrastructure that makes their jobs faster, not as a security concern. Talking about security with developers goes better when they’re concrete: Here’s the tool, here’s what it can access, here’s the attack path. Specificity converts advice into a remediation ticket that actually gets closed.

None of this requires a new program, just an extension of an existing one. Security caught up with cloud. It’s catching up with AI now. The only question is whether your program gets there before an attacker does.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?