In September 2025, an attacker published an npm package called postmark-mcp — a Model Context Protocol server impersonating the legitimate email vendor Postmark. It looked legitimate. It worked correctly for fifteen versions over several months. Then version 1.0.16 shipped a single new line of code: a BCC on every outbound email, silently forwarding correspondence to an attacker-controlled domain.
The package pulled 1,643 downloads before discovery, according to security firm Koi Security. The official MCP registry’s moderation policy explicitly states it will not remove servers with security vulnerabilities — only illegal content, malware, spam, and broken servers qualify.
This wasn’t an isolated incident. It was a preview of what happens when an ecosystem built for developer velocity meets enterprise-scale AI adoption with no security governance layer.
If your organization is building anything with AI agents, you are building with MCP. Anthropic, OpenAI, Google, Microsoft, AWS, and JetBrains have all adopted it. Thousands of servers are live across public registries. The security gaps in the protocol are not edge cases — they are structural, and they affect every implementation.
The Ten MCP Risks That Should Keep CISOs Up At Night
No Authentication Required — By Design
A July 2025 internet-wide scan by Knostic identified 1,862 MCP servers exposed to the public internet, all responding to unauthenticated tool-listing requests. From a manually verified sample of 119, every single one granted access to internal tool listings with no authentication. This is not exotic exploitation — it is the predictable consequence of a protocol where authentication is optional and most servers ship with no auth by default.
Trusted Today, Weaponized Tomorrow
The Postmark incident is the textbook example. An attacker builds trust across multiple clean releases, then weaponizes a single update. Because most MCP servers are pulled from public registries with no integrity verification, the supply chain reaches directly into your developer machines and runtime environments. The MCP registry’s policy of leaving vulnerable servers in place compounds the problem.
From a GitHub Issue to 4,000 Compromised Machines
In February 2026, security researcher Adnan Khan disclosed Clinejection — a prompt injection chain in the Cline AI coding assistant. An attacker filed a GitHub issue with a crafted title; Cline’s AI triage workflow read it and was tricked into running npm install from an attacker-controlled fork. Eight days later, an unknown actor exploited the same flaw to publish an unauthorized version of the Cline CLI to npm. Roughly 4,000 developers installed the compromised release during an eight-hour window before it was caught.
One Compromised Server Poisons Every Tool in the Session
Models read every installed server’s tool descriptions before responding. A malicious server can embed hidden instructions, and the calling agent will obey them. Researchers have demonstrated that one compromised server can corrupt the behavior of every other tool in the same session — exfiltrating credentials and SSH keys through a clean server acting as an unwitting proxy. Newer frontier models sometimes catch these injections, but relying on the model to enforce security is not a control.
AI Agents Can Expose Your Cloud Credentials
Microsoft patched CVE-2026-26118 earlier this year — an SSRF vulnerability in Azure MCP Server that allowed a manipulated server-side request to expose the host’s managed identity token. The same attack pattern applies to AWS: a malicious MCP server can redirect a client running on Lambda or ECS to the EC2 instance metadata service to steal IAM role credentials. The MCP spec recommends blocking private IP ranges, but treats most of these protections as should, not must.
No Logs. No Intent. No Investigation
The protocol has no mandatory logging. It does not record which tools were called, with what arguments, by which user, or what triggered the model to invoke them. Investigators are left with the what and never the why. Audit and observability are consistently cited as a top gap across independent MCP security analyses.
Grant Access to One Tool, Expose the Entire Server
OAuth scopes in MCP grant access to an entire server, not individual tools. Approve a GitHub MCP server and the agent can read repositories, create issues, and delete branches. The protocol exposes readOnlyHint and destructiveHint annotations, but these are explicitly hints, not enforcement. A malicious or buggy server can mark a destructive tool as readOnlyHint: true — and the underlying handler executes regardless.
88% of MCP Servers Handle Credentials Insecurely
According to Astrix Security’s State of MCP Server Security 2025, 88% of MCP servers require credentials, 79% pass API keys via plain environment variables, and 53% rely on static API keys or personal access tokens. Only 8.5% use OAuth. The protocol does nothing to prevent any of this.
No Way to Verify a Server Is Who It Claims to Be
There is no cryptographic mechanism in MCP to verify that a server is who it claims to be. Name-squatting attacks succeed precisely because there is no publisher attestation. Proposals for identity verification — including community proposals for both client-side (SEP-1289) and server-side (SEP-1959) verification — are still under discussion and have not been adopted into the spec.
Authorization Is Optional. 30+ CVEs Prove the Cost
Independent security analysis tracking MCP-related CVEs found more than 30 filed in just the first two months of 2026, with approximately 13% classified as authentication bypass vulnerabilities. The reason is structural: the MCP authorization specification defines an OAuth 2.1 framework, but explicitly states that authorization is OPTIONAL for implementations. Authentication in this ecosystem is a nice-to-have — and the CVE count reflects it.
What These Ten Issues Have in Common
None of these are bugs in individual servers. They are the predictable consequence of a protocol designed for openness and developer velocity, with security explicitly deferred on the official roadmap.
For a CISO, the practical implication is this: MCP gives your AI agents a path into every system that matters — source code, CRM, finance, identity, infrastructure. The protocol provides almost none of the controls you would require for software with that access: no conformance tests, no mandatory audit logging, no enforced authorization, no publisher verification.
Why Vendor MCPs Solve One Problem and Create Four More
The instinct to limit exposure — “we’ll only use MCP servers from trusted vendors like Salesforce, NetSuite, or ServiceNow” — is reasonable. It addresses supply chain risk. It doesn’t address the other nine.
Vendor MCP servers inherit every structural gap in the protocol. They still expose all-or-nothing tool access. They still lack audit logging that correlates model behavior with downstream API calls. They still rely on credentials your developers manage locally. And they cannot prevent prompt injection or cross-server contamination once you stack five or ten vendors together — at which point you’ve recreated, inside your enterprise, a smaller version of the same untrusted registry problem you were trying to avoid.
There’s also a ceiling on what any single vendor’s MCP server can do by design. A Salesforce MCP server talks to Salesforce. A NetSuite MCP server talks to NetSuite. Neither can deterministically orchestrate a workflow that spans both — one that begins with a CRM signal, validates against the ERP, updates a data warehouse, and notifies the right team in Slack. That cross-system logic either lives in the model’s runtime decisions (unauditable, non-deterministic) or it doesn’t exist. For most enterprises, that’s not an acceptable architecture.
What Enterprise AI Integration Actually Requires
The risks above point to a clear set of requirements. Enterprise AI integration needs governance that lives above the protocol, not inside it.
A Governed Supply Chain
Workato provides a catalog of pre-built MCP servers built and maintained by Workato — not pulled from a public registry. Customers extend them, adapt them to their own data models, layer policies on top, and chain them into composite workflows. Because they live inside Workato’s recipe and deployment infrastructure, they inherit the same versioning, environment promotion, and rollback controls as any other enterprise integration. That is a fundamentally different supply chain posture than an npm package with no integrity verification.
Bounded Blast Radius
When configured with per-user OAuth connections, tool calls execute under the identity of the actual user who initiated them — not a shared service account. An agent acting on behalf of an analyst can only do what that analyst is permitted to do in the underlying system. When an agent is compromised or a prompt injection succeeds, the blast radius is bound to what that user could have done anyway. For organizations running shared service account connections today, migrating to per-user auth is a prerequisite — but the enforcement mechanism exists at the platform level, not left to each server implementer.
Granular Access Control
Where MCP grants access to an entire server, Workato’s API collections let you scope exactly which actions are exposed as tools — “read invoices” without “delete invoices,” “create a Salesforce case” without “modify pricing.” Roles map to your existing identity provider. Enforcement lives at the recipe layer, centrally managed, not distributed across individual server configurations.
A Complete Audit Trail
Every tool invocation flows through Workato’s logging layer: tool name, arguments, caller identity, downstream API call, and response. That data is exportable to your SIEM and correlates recipe execution with the AWS, Salesforce, or internal API call it triggered. You won’t get the model’s internal reasoning — no platform can give you that — but you get a complete, structured record of every action taken and by whom, which is what investigations actually require.
Deterministic Execution
In agentic flows, the model still makes routing decisions about which tools to invoke. But once a Workato recipe fires, what it does is defined in code — not improvised by an LLM at runtime. The cross-system behavior is bounded, auditable, and repeatable. For the analyst reviewing an incident six weeks later, that difference is the entire ballgame.
The Bottom Line
The analyst whose outbound email was silently BCC’d to an attacker for months didn’t need a better protocol specification. They needed a governed platform between the AI and the systems it could reach.
MCP is the protocol underpinning modern AI integration. Its adoption is not slowing. The question for every CISO right now is not whether to engage with it — it’s whether the governance layer above it is real or theoretical.
A protocol spec will not give you that. A vendor MCP server will not give you that. Building it yourself means taking on supply chain security, audit infrastructure, secrets management, sandboxing, and identity enforcement as engineering problems your team now owns.
Workato Enterprise MCP is built to operate as that governance layer — with the observability, access controls, lifecycle management, and cross-system orchestration that the protocol leaves unaddressed.