A developer on your team clicks "Always Allow" in Claude Code on a Tuesday morning. By Wednesday, a follow-up prompt from the same MCP server quietly reads a file it was never shown permission for - and nobody sees a confirmation dialog. That is not a hypothetical. It is one of the specific attack sequences OX Security documented in its October 2026 audit of the public MCP ecosystem.
That audit is the most concrete look yet at what enterprises are actually connecting to when they adopt MCP. The picture is not pretty - but it also points clearly toward what a safer path looks like.
What OX Security actually found inside 15,465 MCP servers
MCP server security for enterprise teams starts with a question most teams are not asking: who controls the infrastructure behind the tool you just approved?
OX Security analyzed 15,465 publicly listed MCP servers and found infrastructure spanning foreign jurisdictions, home networks, and abandoned domains - exposing a governance gap as enterprises connect AI agents to tools they may not fully control. The researchers called the result a new class of "shadow infrastructure." Here are the headline numbers:
MCP currently provides no native protocol mechanism to enforce where connected tools run or where data may be processed. That is not a bug in the spec - it is an architectural gap. Teams approving MCP servers through Claude Desktop, Cursor, or Windsurf are making a trust decision about both the tool and the infrastructure beneath it, usually without seeing the latter.
The registry side is equally bare. OX Security traced critical vulnerabilities in Anthropic's MCP source code, downloaded more than 150 million times - and when they looked at what people actually install, community-published servers across the most popular MCP marketplaces, they found no guardrails and no review. For comparison, Google launched its Bouncer automated scanner for Android apps back in 2012. The MCP marketplaces, fourteen years later, have nothing equivalent.
The permission-persistence finding is the one worth sitting with. In testing against Claude Code with Haiku 3.5, granting a single "Always-Allow" permission allowed a malicious MCP server to use subsequent prompt injection to execute privileged file access without another user confirmation. The same attack did not succeed against Opus 4.6 or 4.7. Model choice, it turns out, is part of your security posture - not just a quality decision.
Why vendor-controlled MCP servers look different from community servers
The Atlassian MCP server - the only GA item at Atlassian's Team '26 Europe conference - ships with 220+ tools, and in Atlassian's internal benchmarks on Claude models, the rebuilt server used up to 25% fewer tokens than the previous version on the same Jira and Confluence work. That efficiency claim is secondary. What matters for security-minded teams is the hosting and identity model.
The Atlassian MCP server is Atlassian-hosted and secured with OAuth 2.1 and PKCE by default. Every request strictly respects each user's existing permissions; using an agent will never grant access a user didn't already have. Atlassian Guard enforces Data Security Policies and Data Loss Prevention across MCP connections, ensuring agents only touch data appropriate for their role and environment.
The server separates read, write, and destructive actions into distinct risk tiers, letting clients require explicit confirmation on higher-risk steps.
Compare that to what OX found in the community ecosystem: no vetting, no hosting guarantees, no permission inheritance from the underlying system. The contrast is not subtle.
Atlassian MCP now handles more than 15 million calls a day , which means teams are using it at volume. A server handling that load with OAuth 2.1, permission inheritance, and audit trail support is a meaningfully different thing from a community server running on someone's home tunnel. Both speak MCP. That is where the similarity ends.
Beagle in action#eng-platform, 10:22amHow teams should triage their current MCP server list
MCP secure deployment is less about the protocol than about who is operating each server. A one-time audit of your connected servers takes about twenty minutes and surfaces most of the risk.
For each approved MCP server in your environment, check:
- Who hosts it. Atlassian-hosted, AWS-hosted, or a named cloud provider is a different risk tier from a domain you have never heard of.
- Domain registration health. 2.3% of analyzed hostnames failed to resolve, and the unregistered domains create potential takeover paths if MCP clients or workflows continue to trust and call them. A lapsed domain in your approved list is an open door.
- Permission scope. Does the server need write access, or only read? Most community servers request more than they need because it is easier to build that way.
- Model pairing. The OX finding on prompt injection resistance is specific: the attack that worked against Haiku 3.5 did not succeed against Opus 4.6 or 4.7. If you run a powerful MCP integration against a smaller model for cost reasons, budget for that tradeoff explicitly.
- Standing approvals. Audit any "Always Allow" grants. They are the attack surface the October report centers on.
The practical upshot is a tiered approach: use vendor-controlled, enterprise-hosted MCP servers (Atlassian, GitHub, AWS) for anything touching production data or internal systems; treat community-registry servers as untrusted third-party code and require explicit review before installing them, the same way you would a new npm dependency.
MCP server security: common questions
What makes an MCP server a security risk?
The main risks are infrastructure opacity, permission persistence, and supply-chain trust. An MCP server can route your agent's requests through infrastructure you do not control, in jurisdictions you did not approve, and a single broad permission grant can be exploited by prompt injection to access data without further confirmation. Checking who hosts the server matters as much as what it does.
Is the Atlassian MCP server safe for enterprise use?
The Atlassian MCP server is Atlassian-hosted and secured with OAuth 2.1 and PKCE by default, and every request strictly respects each user's existing permissions. It is a vendor-controlled server with a clear security model, which puts it in a different category from community-published servers. It is still software, and you should review the permission tiers before enabling write and delete toolsets.
How do I audit MCP servers my team has already approved?
Check the MCP config file in each client (Claude Desktop stores it at claude_desktop_config.json; Cursor at .cursor/mcp.json). List every server URL, verify domain registration with whois, confirm the hosting provider resolves to a corporate infrastructure block rather than a residential one, and revoke any "Always Allow" grants you cannot directly explain.
Does the model I use affect MCP security?
Yes, in one documented way: a prompt injection attack that exploited a standing "Always-Allow" permission succeeded against Claude Code with Haiku 3.5, but the same attack did not succeed against Opus 4.6 or 4.7. Model capability affects prompt-injection resistance. Teams pairing powerful MCP server access with cost-optimized smaller models should account for this gap.
Should I build my own MCP server or use a vendor one?
For internal tools and private data, building a controlled MCP server with a defined permission model is reasonable - and you own the hosting. For third-party systems like Jira, GitHub, or Salesforce, the vendor's own MCP server is almost always the safer starting point: you get their existing auth and audit infrastructure without replicating it. The OX findings apply specifically to community-published servers; a well-built internal server with proper OAuth and scoped permissions sidesteps most of them.