Toolshed
Stripe’s central MCP proxy / tool registry. Internal product (not open source as of [un]prompted 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.