Sandbox escape: 2,000 MCP plugins inside Claude

The Claude Marketplace opens with more than 2,000 connectors

On 27 September 2026 Anthropic opened the Claude Marketplace: a public catalogue gathering plugins, connectors, agents and products built on Claude. The announcement claims more than 2,000 connectors and plugins already available^[1], with integrations signed by Atlassian, Google, Microsoft and Salesforce.

The catalogue also hosts agentic products from partners such as CrowdStrike, Cursor, Harvey, Legora, Lovable and Snowflake. Alongside them come consulting and integration firms: Accenture, Boston Consulting Group, Deloitte.

The technically relevant fact lies elsewhere, in the publishing channel. Developers can build connectors and plugins using Model Context Protocol and Agent Skills. Companies selling software built on Claude can request a catalogue listing, and distribution becomes a path open to anyone.

The shape recalls an app store: discovery, installation, updating in a few steps. It is a leap beyond one-to-one integrations, hand-configured by an internal team.

From integration protocol to distribution channel

Until yesterday MCP was an integration protocol: a way to connect an agent to tools and data. With a public catalogue it also becomes a distribution channel, and the nature of the risk changes.

The protocol layer remains the real moat in this market, more than the performance of any individual model.

Whoever controls the communication between agents and tools controls the architecture of whoever integrates. A catalogue managed by the model vendor concentrates two historically separate functions: the technical standard and the commercial shop window. That concentration brings immediate adoption value and an architectural lock-in debt to be measured now.

OpenAI tried a similar route with its own app marketplace, with modest results. Anthropic is opening publication to anyone to avoid that ending, and accepts the trade-off that follows: more connectors, more third-party code, more variance in quality.

What an installed connector actually runs

An installed connector is third-party code operating inside the agent's context, with the permissions of the user who installs it.

The descriptions of the tools exposed by an MCP server enter the prompt. The model reads them as operating instructions, and decides when to invoke them. The boundary between data and instruction, already thin in RAG architectures, here becomes a design choice made by the connector's supplier.

From this follows the practical consequence: active auto-invocation removes the human step between tool discovery and execution.

A retrieved document carries the user's credentials with it. The same holds for a connector: it inherits the session, the tokens, the access to the file system or the repository the agent already holds. Prompt injection remains the attack most underestimated by enterprise AI teams, and an open catalogue multiplies its entry points.

The points the announcement leaves open

The available coverage describes the catalogue, the partners and the publishing model. What is missing are the elements a security team uses to decide.

Three in particular stay outside the public text:

• the review process for connectors published by third parties: who verifies the code, against which criteria, how often
• versioning and provenance: how a release is signed, how an automatic update is blocked, how the diff is read
• permission revocation and scoping: how a company withdraws a connector from an entire fleet of agents in one move

These three points separate an "available" catalogue from a production-grade one. The answer has to be demanded from the vendor before rollout, in contractual form.

The same question applies to traditional app stores, where review has existed for years and is imperfect all the same. An agentic catalogue is born with one extra problem: the published code acts, rather than merely displaying content.

The difference matters. A malicious app on a mobile store asks permissions of a user who can see them; an agentic connector inherits permissions already granted, inside an automated session.

Sandbox escape is a class of incident

Sandbox escape is a class of incident, rather than an isolated anecdote. Every evaluation environment for an agent is, in practice, a production surface.

The operating principle is blunt: the system an agent can reach is the system an agent can compromise.

A connector downloaded from a public catalogue extends that reach silently. The agent acquires new tools during a session, and the perimeter changes between one run and the next. The technical answer runs through identity: dedicated credentials for every agent, named logs, immediate revocation. Zero trust applied to agents starts exactly here (The Hacker News^[2]).

What stays outside the logs stays outside control. A connector installed by a developer on their own workstation, with the corporate token in session, produces an execution chain the company discovers after the fact.

Three questions for enterprise AI teams

Before authorising the catalogue inside the perimeter, a team should answer three operational questions.

1. What inventory exists today of the MCP connectors already installed on workstations and in CI pipelines, with name, version and author?
2. Which identity does each agent use when it invokes a tool from the catalogue, and how long does revoking it take?
3. Which control blocks the automatic update of an approved connector to a version still awaiting review?

The three answers require data, rather than opinions. A team that produces them in half a day already has working governance; a team that takes weeks is measuring its own technical debt in that delay.

Most architectures in production treat retrieved content as trusted input. A catalogue of 2,000 items makes that choice expensive, because every entry adds an author, a supply chain and a release cycle outside corporate control.

Multi-agent systems without explicit circuit breakers fail in cascade: one agent's output becomes the next one's input, and independent validation is absent. Adding third-party tools to that chain amplifies the phenomenon.

Trap or competitive advantage

The technical verdict cuts both ways, and it is worth separating by role.

• CTO: revise the installation policy for agentic tools, today often left to the individual developer
• Head of Engineering: adopt an allowlist of signed connectors, with version pinning inside the repository
• CFO: integration cost falls, audit and incident response cost rises; the budget has to be rebuilt on both lines
• Technology Procurement Committee: demand contractual review SLAs, breach notification and a right of centralised revocation

On the adoption side the catalogue is a real advantage: it cuts integration work, standardises tool discovery and brings serious suppliers into a single environment. That part holds up in daily use, and deserves recognition.

On the security side the catalogue moves risk upstream, towards a supply chain the company inherits instead of building. The security posture of AI systems runs two or three years behind infrastructure maturity, and a distribution channel widens that gap.

One point of language remains, and it weighs on decisions. Talking about "rogue" agents shifts responsibility from the system towards an imaginary figure, as this critical analysis argues (Eoin Higgins^[3]). A connector that performs a harmful action is running code written by someone, inside a perimeter authorised by someone.

The decision for the next planning cycle is simple in form: treat the Claude Marketplace as a dependency repository, with the same rules as a package manager. Inventory, signing, pinning, revocation. The rest is trust, and trust sits badly in logs.