An MCP server that anyone with the shared API key can call is fine right up until that server can also delete records, send messages, or push code. Access control for MCP isn't one setting - it's at least four separate questions: who can connect at all, which servers they can reach, which specific tools within those servers, and whether a given tool call needs a human to sign off before it runs.
TL;DR
- MCP access control has to answer four questions separately: who can connect (inbound auth), which servers and tools they can reach (RBAC), whether specific actions need conditional rules beyond allow/deny (policy), and whether destructive tool calls pause for human approval.
- TrueFoundry's MCP Gateway covers all four as configuration: RBAC scoped to teams and users, Cedar-based conditional policy, and approval gates on destructive tools, with every call traced.
- If you're a single developer connecting to a single MCP server, none of this is necessary yet - a plain transport proxy is the right amount of tooling until more than one person or more than one server is involved.
TrueFoundry MCP Gateway
TrueFoundry’s approach is simple: if organizations are already managing AI infrastructure for LLMs, there is little value in fragmenting operations across separate systems for MCP tools. Instead, TrueFoundry unifies LLM infrastructure and MCP management into a single control plane with shared security, observability, governance, and performance characteristics. This centralized approach simplifies AI operations while giving engineering teams a consolidated platform for monitoring, deployment, and cost management.
One of the platform’s standout advantages is its performance-focused architecture. TrueFoundry achieves sub-3ms latency under load by handling authentication and rate limiting in-memory instead of relying on database queries. For AI agents making hundreds of MCP tool calls per interaction, this reduction in latency compounds into significantly faster and more responsive systems.
The platform also emphasizes enterprise-grade operational simplicity. Teams can deploy containerized MCP servers, integrate them directly with the AI Gateway, and manage authentication, access control, custom configurations, guardrails, fallback mechanisms, load balancing, and rate limits from a unified interface. Interactive playgrounds further accelerate development by generating production-ready code snippets across multiple languages, helping teams move quickly from experimentation to deployment.
Most importantly, TrueFoundry delivers unified observability and billing. Organizations already tracking LLM performance and costs gain visibility into MCP tool usage and infrastructure metrics from the same dashboard, preventing operational blind spots and unexpected budget overruns.
Key Features of TrueFoundry
Unified infrastructure for both LLMs and MCP tools through a single control plane
Sub-3ms latency under load with in-memory authentication and rate limiting
MCP Server Groups for logical isolation across teams and environments
Containerized MCP server deployment with centralized orchestration
Integrated AI Gateway with authentication and access control
Custom configurations, guardrails, fallback mechanisms, and load balancing
Built-in rate limiting and cloud-based model deployment support
Interactive playground with production-ready code generation in multiple languages
Unified observability, monitoring, and billing across AI workloads and MCP tool usage
Integrations with platforms such as n8n, Slack, and Claude Code
The four questions access control actually has to answer
1. Who can connect to the gateway at all. Inbound authentication supports a TrueFoundry API key, an identity provider token, or TrueFoundry OAuth, and the gateway validates whichever one shows up before anything else happens.
2. Which servers and tools a given user or team can reach. This is RBAC in the ordinary sense: grant a team access to a server, and separately decide who can manage that server's configuration versus who can only call it.
3. Whether a specific action needs a rule beyond simple allow or deny. Plain RBAC answers "can this user reach this server." It doesn't answer "can this user's support-copilot agent write to Jira, given that the same user's engineering agent is allowed to." For that, TrueFoundry uses Cedar policy, evaluated as a principal/action/resource/context tuple on every request, default-deny:
// The support copilot may only READ Jira, even when acting for any user.
permit (
principal == AgentIdentity::"support-copilot",
action == Action::"mcp:callTool",
resource == Tool::"jira/issues.read"
);
// Block destructive tools for any agent more than two hops deep in a chain.
forbid (
principal,
action == Action::"mcp:callTool",
resource in ToolGroup::"destructive"
)
when { context.actor_chain.length > 2 };
Whether a destructive action needs a human to actually confirm it. Tools marked destructive can be configured to pause and wait for user confirmation instead of executing the moment they're called - the difference between an agent that can propose deleting a record and one that can just delete it.
4. Watching what actually gets called
Access control without visibility into what's happening is half the job. The MCP Metrics dashboard has a server-level view (request rate, latency percentiles, failure rate by error type, which JSON-RPC methods make up the traffic) and a tool-level view for drilling into individual tools across every server:
Both views can be sliced by user, team, or virtual account, which is what turns "a tool failed" into "this specific team's agent is failing this specific tool at this rate."
Where guardrails fit in alongside access control
Access control decides whether a call is allowed to happen at all. Guardrails inspect the content of a call that's already been permitted - catching a tool argument or response that looks like a secret, a prompt injection payload, or a policy violation the RBAC layer was never meant to catch. The same guardrail metrics dashboard tracks evaluated requests and blocked/mutated rates for these checks:
What's the access-control gap your team has actually hit first - RBAC across teams, a destructive tool that ran without anyone confirming it, or just not knowing which agents can reach which servers at all?
Top comments (0)