Security Risks of Model Context Protocol Integrations in SaaS
Agents can be tricked into misusing credentials across connected servers.
Model Context Protocol integrations create security risks that ordinary API and perimeter controls do not cover [1][2][3]. An AI agent has runtime authority to read untrusted instructions, choose tools, and use credentials held across the servers it connects to. For SaaS teams, closing that gap requires testing and controlling the whole chain of decisions.
What MCP actually is and why its trust model differs from conventional API integration
MCP connects an AI application to operational systems. The host is the AI application, the client manages server connections, and the server exposes tools, resources, and prompts backed by credentials such as OAuth tokens or database access. Veeam’s MCP security overview makes the distinction clear. MCP provides the connection layer through which the model reads tool descriptions and decides what to call.
That decision changes the trust model. A conventional API caller runs deterministic code with declared intent, while an MCP agent infers what a competent operator would do next. The server can then act using its own credentials. This gives the agent ambient authority, which is power it has through its surroundings. Validation and role-based access controls can check a requested action without establishing whether the agent was steered into requesting it.
Why MCP's authorization model leaves enterprises with a gap they did not inherit from their existing controls
The Cloud Security Alliance’s May 2026 research note says that MCP’s authorization specification sets out an OAuth 2.1 framework but does not require authorization. Where deployments lack an additional policy layer, the service account behind a tool can become the effective permission boundary. The same research finds that the protocol has no built-in defenses against tool poisoning, rug pull attacks, or cross-server tool shadowing. Authentication alone cannot close those gaps.
An identity system can identify a requester without knowing which MCP servers the request passed through or which descriptions shaped the agent’s choice. Agent identity is dynamic, session-based, and inherited, unlike the human and deterministic service identities existing controls assume. The July 2026 specification update tightened authorization checks and removed the Mcp-Session-Id mechanism, reducing session-fixation and hijacking exposure through a stateless architecture. Older servers still need checking. Yet developers and non-developers can add servers through local client configurations without a security review, so many enterprises cannot even name the servers they need to check.
The STDIO design flaw embedded in every official MCP SDK
OX Security’s April 2026 disclosure, “The Mother of All AI Supply Chains,” described a design default. STDIO configuration parameters go straight to the host operating system shell without sanitization or validation. A command can execute whether or not it starts a valid MCP server. The affected official SDKs span Python, TypeScript, Java, and Rust. Anthropic classified the behavior as intentional and declined to change it.
The disclosure showed how attackers could exploit the flaw through direct unauthenticated configuration, compromised repositories, malicious registry packages, and social engineering that got users to change configuration files. The CSA estimates that hundreds of thousands of instances are exposed in a supply chain with more than 150 million package downloads. Downstream developers inherit the remediation work. STDIO helped spread that work to more developers because its documented default needs no network infrastructure, which made it appealing. Using remote Streamable HTTP avoids this launch path, but developer machines that still run local integrations remain at risk, and the remote transport has separate risks of its own.
The vulnerability classes specific to MCP's runtime trust model
Tool poisoning uses tool metadata to send instructions to the model. The model consumes descriptions that users rarely see during execution, allowing a malicious server to redirect behavior without visible approval. Simon Willison’s April 2025 documentation identified this asymmetry as a design risk. Approval also need not freeze the instructions. A rug pull exploits that opening by behaving legitimately during review and changing instructions afterward, as the Deadbugz campaign illustrates.
Cross-server tool shadowing extends the attack across connections. Invariant Labs demonstrated that one compromised server could use tool descriptions to redefine the agent’s understanding of adjacent trusted servers. Indirect prompt injection instead places instructions in documents, emails, or web pages the agent reads through tools. The dangerous combination is straightforward and common in SaaS deployments. Untrusted content meets sensitive data and outbound network access.
Classical flaws also gain reach through MCP. Tool connectors become server-side request forgery vectors when supplied URLs can reach internal services without egress restrictions or scheme validation. Grafana’s MCP vulnerability illustrates that route. Credential aggregation adds risk because the tokens and keys that servers hold can leak through debug output, injected instructions, or model responses. Shared transport state can also cross tenant boundaries. TypeScript SDK versions 1.10.0 through 1.25.3 could route responses to the wrong client when a transport object was reused, with a fix published in version 1.26.0 on February 4, 2026.
What confirmed incidents reveal about how these vulnerabilities behave in production
The Postmark MCP supply chain incident in September 2025 showed why installation review is not enough. An update to a widely installed email server package silently sent copies of email sent by the agent to an attacker-controlled domain. Its earlier behavior had passed standard review. Pillar Security’s August 2026 Deadbugz disclosure showed a related delay tactic through a malicious server called “productivity-suite.” It stayed harmless for its first three tool calls before instructing the agent to collect SSH keys, AWS credentials, shell history, and Kubernetes configuration while hiding the activity from the user.
Other disclosures show that legitimate integrations can become the route in. Tenet Security researchers Ron Bobrov, Barak Sternberg, and Nevo Poran disclosed an agentjacking technique against Sentry’s MCP integration in June 2026 that bypassed explicit anti-injection instructions in a large majority of tested cases. Pillar Security also disclosed unauthenticated tool execution combined with SSRF in Grafana’s MCP integration. The entry points differ, but that distinction does not bound the damage. Credential scope determines how far a compromised server can reach.
How widespread unauthenticated MCP exposure actually is across cloud environments
Wiz Research’s State of AI in the Cloud 2026 report found MCP servers in a large majority of observed cloud environments. A meaningful share had at least one internet-facing server. Independent scans found a substantial share of MCP servers without authentication, while only a small fraction used OAuth. Knostic’s July 2025 internet scan had already identified well over a thousand publicly accessible instances responding to unauthenticated requests. That exposure preceded the rapid adoption growth of late that year and the next.
This is not merely an outlier deployment problem. Developers used integration paths presented as standard, while the review processes already in place did not always account for the new trust boundary. Internal-only deployment limits direct internet access, but it does not remove malicious package updates or instructions delivered through connected content. Deadbugz demonstrates why package provenance remains relevant behind a perimeter. SaaS teams should therefore establish their actual posture through inventory and testing.
Why compliance frameworks do not cover the MCP threat model and what that gap costs in an audit
SOC 2, ISO 27001, and HIPAA contain no MCP-specific controls. Their broader requirements still apply, but the evidence usually collected does not by itself show the trust chains that agents use. SOC 2 Logical Access controls assume identity verification at the human or service level. That is not a direct match for inherited, session-based agent authority. A compliant organization can therefore still have an unauthenticated MCP server holding database credentials and production cloud access.
The audit gap is also an evidence gap. Unless the audit scope explicitly includes MCP, auditors may get nothing that shows which servers agents reach, what instructions they read, or what actions their credentials allow. An audit letter can then create confidence unsupported by the integration’s actual controls. For enterprise customers in fintech and financial services, that leaves an undisclosed source of risk behind otherwise familiar assurance.
What conventional penetration testing misses when scoped to APIs and network perimeters
A conventional API penetration test checks authentication, authorization, input validation, and error handling for a deterministic caller. Those checks remain useful, but they do not test whether a tool description can redirect a model. Nor do they test whether calls that are each authorized can together lead to an unauthorized outcome. A server that changes behavior after review also defeats the assumption that the tested interface stays fixed.
For security buyers, the scope must make that difference explicit. Server enumeration, tool-description integrity review, agentic red teaming, and blast-radius assessment belong in an MCP engagement. Without them, the test checks only the surrounding perimeter. Warning signs include an API-only scope, scanner output without reproduced exploits, and no treatment of tool definitions as untrusted input.
What a genuine MCP security assessment covers and how to evaluate whether a vendor can deliver one
A genuine assessment has seven phases. Inventory and attack surface discovery find every server that can be reached, including those in local configurations that the security team never reviewed. An AI bill of materials maps servers, tools, models, credentials, and provenance. Protocol conformance and authentication testing examine the connection boundary, followed by tool poisoning and rug pull analysis. Implementation exploitation covers path traversal, injection, SSRF, unsafe deserialization, and secret exposure. Agentic red teaming and blast-radius assessment complete the scope.
The red team must test the agent’s decisions. That includes goal hijack through content the agent reads, unauthorized outcomes assembled from permitted calls, cross-server interference, and attacker instructions persisting into future sessions. Meaningful review needs whitebox access to tool schemas and server configuration, with tools/list enumeration supporting description inspection. Findings need working exploits against an authorized live target. A buyer should ask vendors to show that they can do these tests, make clear which findings they have reproduced and which are alerts, and explain how they find unknown servers. Pull-request scanning and on-demand retests address changes that a closed engagement cannot catch.
The technical controls that reduce MCP attack surface at the protocol, server, and runtime layers
Pillar Security and the Coalition for Secure AI identify a complete inventory as the prerequisite for other controls. Teams should record the client, launch command or URL, version, and source package for each server found across developer machines and repositories. Remote servers should require authentication, and tests should prove that processing stops when a request is rejected. The Dolt flaw returned 401 while continuing to process, showing why the status code alone is insufficient.
Approval should apply to both tools and servers. Teams should allow specific read tools and deny write or destructive tools unless justified, then pin versions and review updates for changed tools, destinations, and instructions. Each server needs its own scoped credential rather than a shared personal token with broad access. Secrets belong in environment variables or a secret manager, with configuration scanning for hardcoded tokens. URL and host validation must also prevent connectors from reaching unintended internal services or cloud metadata endpoints.
Tool descriptions, calls, and results can all deliver malicious instructions, so inspecting only the user’s prompt leaves gaps. Veeam recommends an MCP gateway that validates calls before execution and maintains immutable audit logs. Write and destructive calls should need human approval, with managed settings that enforce this rule and that users cannot override. Logs should record the user, agent, server, tool, arguments, and result, providing evidence for SOC 2 CC.7.4 and ISO 27001 A.14.2 review. These controls must examine whether inferred intent is reasonable.
How to treat MCP security as an ongoing program rather than a one-time deployment review
Servers can change instructions, packages can change ownership, and new vulnerabilities can appear between annual tests. The CSA recommends treating every MCP server as an untrusted third party and establishing ongoing governance. That means continuous version monitoring against the approved allowlist, automated scanning when configurations add or update servers, and retest rights after significant updates. New tool additions also need a defined review process that does not require restarting a full engagement.
Ongoing oversight produces evidence as well as protection. SOC 2 continuous monitoring requirements and ISO 27001 operational control reviews both need records of continuing control. For SaaS teams in fintech, anti-fraud, and financial services, that evidence can support enterprise sales as customers examine supply chain risk more closely. Teams that build MCP governance now will have a defensible account of their controls when customer and compliance scrutiny catches up.
