Clawdbot and the Cost of Insecure Defaults: MCP’s Authentication Gap Hits Production

Model Context Protocol (MCP) was supposed to be the connective tissue for AI agents and tools. Instead, it has become a case study in how insecure defaults and “optional” controls can turn into full-blown production risk in a matter of months.

The core issue has not changed since it was first raised in late 2025: MCP shipped without mandatory authentication. Authorization guidance and frameworks appeared only after significant adoption, long after early deployments had already gone live. As deployments have scaled and popular agents like Clawdbot have gone viral, that architectural decision is now driving concrete, high-severity vulnerabilities and real enterprise exposure.

For CISOs, security engineers, and engineering leaders, MCP is no longer an abstract protocol concern. It is an active attack surface already embedded in developer stacks, CI/CD systems, and VPS instances that teams spun up with minimal review. The cleanup has started—and the costs are landing squarely in production environments.

The protocol problem: MCP’s insecure defaults

MCP was designed to let AI models talk to tools, data sources, and services through standardized servers and plug-ins. In theory, that abstraction should make it easier to standardize security controls as well. In practice, the opposite happened: authentication was left as an optional implementation detail, and a growing ecosystem treated “optional” as “unnecessary.”

Security voices were warning early. Merritt Baer, chief security officer at Enkrypt AI, captured the structural issue succinctly when MCP’s first wave of deployments rolled out: organizations were repeating the same pattern seen in previous major protocol rollouts—shipping with insecure defaults and bolting on security later. Her warning was blunt: if authentication and least privilege are not built in from day one, enterprises should expect to be cleaning up breaches for a decade.

Research from Pynt underscored how quickly that design choice turns into risk. Their analysis found that deploying just 10 MCP plug-ins creates a 92% probability of exploitation, with even a single plug-in introducing meaningful exposure. Those numbers are not based on edge cases; they reflect the reality that many MCP components are shipping without strong authentication, tight scoping, or hardened boundaries.

Despite this, broad usage preceded broad hardening. MCP spread through engineering organizations as a convenience layer for AI agents before anyone treated it as an infrastructure tier that required the same rigor as APIs or message buses. The result is a protocol whose architectural choices are now being replayed as concrete vulnerabilities across independent components and products.

Clawdbot’s viral spread turns theory into production risk

That latent protocol risk might have stayed mostly contained within experimental environments if not for Clawdbot. The personal AI assistant gained traction by promising to do what overworked teams desperately wanted: clear inboxes, write code overnight, and automate repetitive tasks. All of that automation runs on MCP.

Clawdbot’s popularity changed the threat model in two key ways. First, it dramatically increased the number of MCP servers running on commodity infrastructure like virtual private servers (VPSs), often managed by individual developers rather than security-conscious platform teams. Second, it normalized giving AI agents broad, persistent access to email, codebases, and systems without a matching maturity in governance or monitoring.

Itamar Golan, who previously sold Prompt Security to SentinelOne for an estimated $250 million, publicly warned about the trajectory as Clawdbot adoption surged. His assessment was stark: thousands of Clawdbots were already live on VPSs, with open ports to the internet and no authentication at all. In other words, there were thousands of unauthenticated MCP endpoints directly exposed to the public internet, each with whatever power its owner had wired up behind it.

Independent research quickly validated that this was not an exaggeration. Knostic scanned the internet and discovered 1,862 MCP servers accessible with no authentication. They tested 119 of them. Every single one responded without any credential checks. For defenders, that means an attacker does not need to break MCP; they only need to find implementations that never turned on the locks that were available.

The implications are straightforward and unsettling: anything Clawdbot—or any MCP-based agent—can automate, an attacker can attempt to weaponize. If an agent can read mail, trigger builds, or access internal APIs, unauthenticated MCP exposure effectively hands those capabilities to whoever finds the server first.

Three critical CVEs, one architectural root cause

Within six months, three separate critical vulnerabilities surfaced across different MCP-related components. They differ in their technical details and attack vectors but share a common weakness: insufficient authentication and trust boundaries in MCP workflows.

The first, CVE-2025-49596 (CVSS 9.4), affected Anthropic’s MCP Inspector. The tool exposed unauthenticated access between its web UI and proxy server. A malicious webpage could exploit this gap, leading to full system compromise. The critical issue was not an obscure corner case; it was an unauthenticated control path between a browser-accessible UI and a powerful backend component.

The second, CVE-2025-6514 (CVSS 9.6), hit mcp-remote, an OAuth proxy with 437,000 downloads. Here, command injection allowed attackers to take over systems by connecting to a malicious MCP server. A component intended to mediate secure remote access became a pivot point: by trusting remote MCP endpoints and failing to rigorously validate commands, it provided a route to remote code execution.

The third, CVE-2025-52882 (CVSS 8.8), affected popular Claude Code extensions that exposed unauthenticated WebSocket servers. The result was broad: arbitrary file access and code execution were possible for anyone who could reach those endpoints. Once again, developers had deployed powerful capabilities without enforcing identity or access control on the front door.

Together, these three CVEs illustrate a pattern rather than isolated failures. Different vendors, components, and usage patterns—but the same architectural weakness: MCP’s authentication and authorization model was effectively optional, and many implementations behaved as though optional meant unnecessary. For CISOs and security engineers, that pattern is more important than the specifics of any single advisory because it signals that similar vulnerabilities are likely to exist in other MCP-based tooling.

An expanding attack surface: from command injection to file exfiltration

The picture becomes more concerning when looking beyond named CVEs at broader ecosystem characteristics. Equixly’s analysis of popular MCP implementations found that:

• 43% contained command injection vulnerabilities,
• 30% permitted unrestricted URL fetching, and
• 22% leaked files outside intended directories.

Those are not niche tools; they are representative samples of how MCP is being used in practice. For attackers, MCP servers with shell access or file system hooks are attractive targets. Once compromised, they offer a direct path to lateral movement, credential theft, and ransomware deployment. Critically, these actions can be triggered by something as simple as a prompt injection hidden in a document or message the AI agent is asked to process.

As Forrester analyst Jeff Pollard put it, from a security perspective MCP can look like “a very effective way to drop a new and very powerful actor into your environment with zero guardrails.” That description aligns with what many security teams are now confronting: AI agents that can read corporate data, run code, and touch production systems, but that were added into environments without being modeled as privileged infrastructure components.

Prompt injection and file exfiltration risks are already concrete. Security researcher Johann Rehberger disclosed a file exfiltration vulnerability in October 2025 in which prompt injection could trick MCP-based agents into sending sensitive files to attacker-controlled destinations. The underlying issue was not patched out of existence; it persisted into new products.

When Anthropic launched Cowork, expanding MCP-based agents to a broader and likely less security-aware audience, the same class of vulnerability remained exploitable. PromptArmor demonstrated that a malicious document could manipulate the agent into uploading sensitive financial data. Anthropic’s own mitigation guidance effectively shifted the burden to end users, advising them to watch for “suspicious actions that may indicate prompt injection” rather than fundamentally constraining what agents could do by default.

This highlights a broader problem: the protocol’s capabilities and integrations are moving faster than the industry’s ability to enforce strong boundaries, and the current mitigations lean heavily on user vigilance rather than enforceable controls.

Why “optional” authentication became no authentication

From a design standpoint, MCP did not forbid strong authentication. The specification recommends OAuth 2.1, and in theory an implementation can be locked down appropriately. However, the SDK ships without built-in authentication, and no requirement forced developers to implement or enable it before going live.

In busy engineering organizations, that combination is predictable. Under pressure to ship features and experiment with AI automation, teams adopt the easiest path: spin up servers, connect them to agents, and handle security later. When later never comes, those test instances become long-lived infrastructure. In the case of Clawdbot and similar agents, “test” quickly blurred into “production” as real work and real data began flowing through them.

Investors and technology leaders are starting to notice this disconnect from a business perspective as well. a16z partner Olivia Moore, after spending a weekend using Clawdbot, summarized the gap: users are giving AI agents access to their accounts, messages, files, and even code execution on their machines without truly understanding what they are authorizing.

That lack of understanding is not limited to end users. Many developers integrating MCP servers into their stacks are not deeply versed in security design; MCP’s design and documentation did not force them to become so. Absent hard requirements or defaults that demand authentication and least privilege, the path of least resistance was always going to dominate.

Five immediate actions for security leaders

For organizations already experimenting with or deploying MCP-based agents, the priority now is containment and control. The following actions, drawn directly from current research and field experience, provide a pragmatic starting point.

1. Inventory your MCP exposure now. Traditional endpoint and EDR tooling will see MCP processes as ordinary node or Python workloads started by legitimate applications. They are unlikely to be flagged as suspicious by default. Security teams need explicit visibility into MCP servers and plug-ins: where they run, what they connect to, and which agents or tools invoke them. Without this baseline, it is impossible to prioritize or even understand the current blast radius.

2. Treat authentication as mandatory, not optional. Regardless of how the MCP specification phrases it, every MCP server that touches production data or systems must be fronted by strong authentication. That means enforcing OAuth 2.1 or equivalent mechanisms at deployment time and ensuring tokens, scopes, and identities are tightly controlled. Waiting to add authentication until after a security incident is an invitation to join the growing list of exploited MCP implementations.

3. Restrict network exposure aggressively. By default, MCP servers should be bound to localhost or otherwise isolated from the public internet. Remote access should be enabled only when explicitly required and only with authentication in place. Knostic’s finding of 1,862 exposed servers—with 119/119 responding unauthenticated—suggests that many exposures are accidental side effects of default network settings and loose deployment practices. Basic perimeter hygiene will significantly reduce the easy wins for opportunistic attackers.

4. Design for prompt injection success, not failure. Security teams should assume prompt injection attacks will bypass content filters and reach agents. From there, the question becomes: what can the attacker do? MCP servers inherit the full blast radius of the tools they wrap. If an MCP server front-ends cloud credentials, file systems, or deployment pipelines, access controls and guardrails must be designed on the assumption that the agent will, at some point, be tricked into doing something harmful. That means limiting capabilities, segmenting environments, and using fine-grained permissions rather than broad “god mode” integrations.

5. Insert human checkpoints for high-risk actions. For sensitive operations—sending external email, deleting data, accessing highly confidential information—agents should not have unilateral authority. Require explicit human approval for these actions and make the review step obvious and unavoidable. A useful mental model is to treat the agent like a very fast, very literal junior employee: it will follow instructions precisely, including those that were not fully intended. Policies and workflows should reflect that reality.

These measures will not eliminate MCP risk, but they materially reduce the probability that an unauthenticated endpoint or a single prompt injection will lead to a catastrophic breach.

The widening governance gap

While security vendors moved quickly to build products around MCP and AI agent risk, most enterprises did not move as fast in updating their internal governance and controls. The result is a widening gap between rapidly expanding AI agent usage and the security frameworks meant to oversee it.

Clawdbot’s adoption curve in the fourth quarter of 2025 illustrates this divide. As usage exploded, most 2026 security roadmaps still contained little to no specific planning for AI agent controls, MCP server management, or prompt injection resilience. Developers raced ahead to take advantage of automation, while security and governance functions were still treating MCP as an emerging, future concern.

From an attacker’s perspective, this is an ideal window. There are thousands of MCP endpoints in the wild, many running powerful automations with minimal authentication, network exposure by default, and no unified enterprise policy governing what agents are allowed to do. The vulnerability disclosures and internet scans seen so far are likely early indicators, not the peak.

The industry now faces a familiar inflection point: whether to normalize these patterns and accept them as the cost of AI-enabled productivity, or to enforce a higher standard of default security before further incidents force the issue. The underlying message from researchers and practitioners is consistent. The situation is already “ugly” in terms of exposed attack surface. The only open question is whether organizations will close their MCP gaps before someone else does it for them.