{"id":16195,"date":"2026-05-08T10:07:00","date_gmt":"2026-05-08T10:07:00","guid":{"rendered":"https:\/\/newestek.com\/?p=16195"},"modified":"2026-05-08T10:07:00","modified_gmt":"2026-05-08T10:07:00","slug":"your-ctem-program-is-probably-ignoring-mcp-heres-how-to-fix-it","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=16195","title":{"rendered":"Your CTEM program is probably ignoring MCP. Here\u2019s how to fix it"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

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 \u2014 especially as it relates to MCP risk \u2014 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.<\/p>\n

Security has always been a race between how fast the attack surface grows and how fast defenders can see it. Vulnerability Management <\/a>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<\/a> 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\u2019t whether CTEM applies. It\u2019s whether the scope has been extended to include it.<\/p>\n

Introduced by Anthropic in late 2024<\/a>, MCP acts as the plugin architecture for agentic AI. If your team isn\u2019t 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 \u201cold\u201d risks such as supply chain attacks, hardcoded credentials, privilege escalation, remote code execution and makes them new again.<\/p>\n

Here\u2019s how:<\/p>\n

Shadow AI: You can\u2019t secure what you can\u2019t see<\/h2>\n

In 2025, researchers documented<\/a> 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\u2019d every single outgoing email to an external address.<\/p>\n

Around 300 organizations were affected before anyone noticed. Password resets, invoices, internal memos, confidential documents \u2014 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.<\/p>\n

Enterprises have accumulated layers of governance to manage third-party software risk \u2014 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\u2019s not a criticism; it\u2019s a visibility problem. Visibility problems don\u2019t get solved by policy. They get solved by knowing what\u2019s in your environment.<\/p>\n

Keys under the doormat: Hardcoded credentials in AI configurations<\/h2>\n

In 2023, information-stealing malware<\/a> harvested more than 225,000 ChatGPT credentials. Many came bundled with API keys developers had hardcoded directly into configuration files \u2014 not out of negligence, but out of the same logic that has always driven security shortcuts: It\u2019s faster, it works and the consequences feel abstract until they aren\u2019t.<\/p>\n

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 \u2014 just a mistake that sat in a repository long enough for a scanner to find it.<\/p>\n

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\u2019t 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\u2019t been.<\/p>\n

\u2018God mode\u2019: When over-privileged AI agents get compromised<\/h2>\n

Running AI agents with elevated privileges is common. In 2025, researchers needed two CVEs just to start making the case. CVE-2025-6514<\/a>, 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 \u2014 triggered simply by connecting to an untrusted server. CVE-2025-49596<\/a>, affecting Anthropic\u2019s own MCP Inspector, scored 9.4 and achieved the same outcome through a chained browser exploit, giving attackers complete access to developer machines.<\/p>\n

Beyond the CVEs, researchers found MCP servers configured with elevated privilege commands \u2014 sudo, doas, runas \u2014 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<\/a> 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 \u2014 existing features were treated as safe because they\u2019d been there for years, until an autonomous agent arrived that could invoke them without asking.<\/p>\n

If an agent in your network gets compromised, the question isn\u2019t whether it can exfiltrate data \u2014 it\u2019s whether it has permission to wipe a server or install ransomware. That\u2019s a configuration question, and most organizations don\u2019t know the answer.<\/p>\n

How CTEM addresses this \u2014 and what it takes to get there<\/h2>\n

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:<\/p>\n