TwinMCP, a hosting platform for Model Context Protocol (MCP) servers, has published a detailed breakdown of its safety architecture, arguing that AI agent security must be enforced at the infrastructure layer rather than relying on model behavior. The post, dated November 2, 2026, highlights how the platform prevents agents from executing unauthorized actions by implementing strict tool access policies via a proxy system. This approach addresses the growing risk that MCP-enabled clients like ChatGPT, Claude, and Cursor can now directly interact with critical services such as Slack, Notion, databases, and Stripe invoices.

Least Privilege Enforced at the Proxy

The core of TwinMCP’s strategy is the rejection of the idea that a model can simply "be careful." Instead, every MCP installed on the platform is subject to a tool access policy enforced by the TwinMCP proxy. This system supports all-tools, read-only, or explicit allow-list configurations, with a deny list that always takes precedence. Crucially, hidden tools are stripped from the tools/list response, ensuring the model never sees them, and any attempt to call a disallowed tool is refused before it reaches the MCP server. The platform also implements a "fail closed" logic for read-only modes, treating any tool that does not explicitly declare itself as read-only as potentially destructive.

Containing the Blast Radius

To prevent cross-contamination, each server runs in its own isolated micro-VM sandbox, separated from other servers and users. TwinMCP restricts general-purpose computer capabilities—such as shell access, code interpreters, or scripted browsers—on free accounts, requiring a funded account to enable these higher-risk features. Credential management is equally rigorous, with secrets encrypted using AES-256-GCM and keys stored outside the database. The platform supports OAuth 2.1 for major connectors, allowing users to revoke access instantly without managing API keys, while access tokens expire after one hour and refresh tokens rotate on every use to prevent replay attacks.

Supply Chain and Visibility

TwinMCP mitigates supply chain risks by pinning every MCP version in its catalogue, preventing compromised or broken npm releases from automatically rolling into user sandboxes. Safer modes, such as Supabase’s --read-only flag or Postgres restricted access, are enabled by default. For visibility, the platform maintains an activity log that records metadata for every tool call—including time, status, latency, and the initiating key—but deliberately avoids storing arguments or results to minimize data retention. This ensures accountability without compromising user privacy, a critical distinction for teams handling sensitive business data.

Unsolved Challenges and Honest Limitations

The authors acknowledge significant unresolved issues, particularly prompt injection, where malicious instructions in web pages or emails can hijack agent behavior. While TwinMCP’s policies limit the damage a hijacked agent can do, the platform admits it cannot guarantee the model won’t follow malicious instructions, recommending human approval for destructive actions. Furthermore, the platform lacks SOC 2 or ISO 27001 compliance, offers no uptime SLA, and does not yet support data region selection. These admissions highlight the early-stage nature of the MCP ecosystem and the trade-offs involved in current infrastructure solutions.

Key Takeaways

  • TwinMCP enforces tool access policies via a proxy, stripping hidden tools from the model's view to prevent unauthorized calls.
  • Each MCP server runs in an isolated micro-VM sandbox, with general-purpose capabilities restricted to paid accounts.
  • Credentials are managed via OAuth 2.1 with rotating refresh tokens and one-hour access token expiration to limit blast radius.
  • Supply chain security is handled by pinning MCP versions, preventing automatic updates from compromised npm packages.
  • Activity logs store metadata only, excluding arguments and results to balance accountability with data privacy.
  • The platform openly admits that prompt injection remains unsolved and that compliance certifications are not yet in place.

The Bottom Line

TwinMCP’s approach validates a growing consensus among infrastructure builders: AI safety is an engineering problem, not a philosophical one. By moving guardrails outside the model and into the proxy, they create a deterministic layer that models can’t hallucinate their way past. This is how we should build the agentic web—assume the model is compromised, and make the infrastructure robust enough to handle it.