Toolshed
Stripe’s central MCP proxy / tool registry. Internal product (not open source as of Unprompted March 2026). Disclosed publicly in Andrew Bullen’s “Breaking the Lethal Trifecta” talk.
What it does
Two functions on top of MCP:
- Third-party SaaS proxying. When Stripe wants to hook up an external SaaS app to internal agents, the MCP connection routes through Toolshed. The proxy is the policy-enforcement point — e.g. “don’t allow connections to non-Stripe tenants when writing to Google Docs / Figma.” This is Stripe’s answer to “MCP-as-data-exfiltration-vector”: the SaaS connection itself is fine, but it has to go through one chokepoint.
- Tool-annotation registration. Tools registered through Toolshed carry ToolAnnotations (
production_impacting_write,data_sensitivity,broadcasts_data_internally). The framework reads annotations and decides whether human review applies. Inline-tool definitions in agent frameworks carry the same annotations.
In the architecture
Toolshed is the most concrete published example of a PDP/PEP for MCP: PDP = the annotation policy (declarative; can be evaluated outside the agent loop), PEP = the proxy (intercepts the actual tool call). Maps directly onto the Oversight Layer (PDP + PEP for Agentic AI) / Guardian Agent vocabulary.
User-side benefit Bullen emphasizes (transcript): users connect to one MCP server (Toolshed) instead of N — the centralization is operationally easier, not just a security ceiling.
Limitations (per the speaker)
- Does not cover “deep agents” that bypass declared tools (Claude Code-style agents writing arbitrary code that hits arbitrary internal APIs). The work-in-progress answer is to additionally proxy raw network egress out of agent sandboxes and annotate the API endpoints themselves.
See also
- Smokescreen — the egress-network-side counterpart (open source).
- MCP Security — the broader category Toolshed sits inside.
- Oversight Layer (PDP + PEP for Agentic AI) — generic PDP/PEP language for what Toolshed implements.