Role-Based Access Control for APIs is familiar territory for most engineering teams. You define roles, assign permissions to roles, assign roles to users, and enforce the policy at the API gateway. The model maps cleanly to REST: a role either can or cannot call a given HTTP endpoint.
MCP introduces a richer access control problem. A single MCP server may expose dozens of tools, each with different risk profiles. The query_database tool and the delete_records tool live on the same server, but the consequences of unauthorised access are orders of magnitude different. MCP RBAC must operate at the tool level — and in mature implementations, at the parameter level — not just the server level.
The three layers of MCP access control
Layer 1: Server-level access
The coarsest control: which agent roles are allowed to connect to which MCP servers at all. This is analogous to traditional API gateway RBAC. A CustomerSupportAgent role might be allowed to connect to the CRM MCP server and the ticketing MCP server, but not the billing MCP server. Server-level access control is the baseline — necessary but not sufficient.
Layer 2: Tool-level access
Within a server, individual tools can have different access policies. On the CRM MCP server, the SupportAgent role might have access to get_customer, search_customers, and add_note, but not to update_credit_limit or delete_customer. Tool-level RBAC requires the gateway to parse the incoming tool call, identify which tool is being invoked, and check the caller's permissions against the policy for that specific tool before forwarding the request.
Layer 3: Parameter-level access
The most granular control constrains what values agents can pass to tool parameters. A reporting agent might be allowed to call the query_database tool, but only with read-only SQL statements — no INSERT, UPDATE, or DELETE. A customer agent might be allowed to call get_customer, but only for customers assigned to their team, not all customers. Parameter-level access control requires the gateway to inspect and validate tool call parameters against policy rules, not just the tool identity.
Practical note: Most teams start with server-level access control and add tool-level as they identify risk differences between tools on the same server. Parameter-level is the right approach for high-risk tools like database writes or financial transactions.
Designing your MCP role taxonomy
Before implementing RBAC, you need a role taxonomy that reflects your actual agent personas. A useful starting structure:
Read-only agents — agents that only retrieve information; should never have access to write, update, or delete tools
Workflow agents — agents that execute defined business processes; access to write tools is scoped to specific objects and actions within the workflow
Admin agents — agents that manage infrastructure or configuration; should be treated with the same scrutiny as human admin accounts
Privileged agents — agents that require elevated access for specific tasks; should use ephemeral credentials and be time-limited
These categories map to groups in your identity provider. When an engineer builds a new agent and assigns it to the Read-Only group, it inherits the read-only policy automatically — no individual permission configuration required.
Mapping roles to tool policies
For each MCP server, create an explicit policy matrix: which roles have access to which tools, with what parameter constraints. This is best maintained as code in your gateway configuration repository, subject to the same code review process as application code.
A practical policy matrix for a hypothetical billing MCP server might look like this: the BillingReadAgent role has access to get_invoice, list_invoices, and get_payment_status. The BillingWriteAgent role has those plus create_invoice and update_payment_status. The BillingAdminAgent role has full access including cancel_subscription and issue_refund, but requires a secondary approval workflow for refunds above a threshold.
Handling agent-to-agent access control
Multi-agent workflows — where one agent orchestrates others — introduce a delegation challenge. If Agent A has broad permissions and delegates a subtask to Agent B, should Agent B inherit Agent A's permissions for the duration of that subtask? The answer, in a properly secured system, is no. Agent B should operate under its own permissions, not a superset inherited through delegation.
This principle — that delegated agents do not inherit the delegator's permissions — is enforced by routing all agent-to-tool calls through the gateway and evaluating each call against the calling agent's own policy, regardless of how the workflow was initiated.
Auditing and policy iteration
RBAC policies should be treated as living documents. As your agent use cases evolve, over-permissioned roles accumulate. Quarterly access reviews — comparing which tools each agent actually invoked in the past period against what they are permitted to invoke — reveal permissions that can be tightened without breaking functionality. The gateway audit log is the data source for this review.
How TrueFoundry MCP Gateway Implements RBAC for MCP Tools
Implementing RBAC at the tool level across dozens of MCP servers, multiple agent roles, and different environments is operationally complex when done manually. TrueFoundry's MCP Gateway is purpose-built to handle this complexity, providing a centralised control plane that enforces access policies consistently across your entire agent fleet.
Tool-level access control, configured centrally
TrueFoundry's MCP Gateway enforces RBAC at the tool level through access control settings configurable per server, per tool, and per environment. Rather than relying on individual development teams to implement their own access checks, TrueFoundry applies policies at the gateway layer — ensuring every agent, regardless of which framework it was built with, is subject to the same access rules. This eliminates the inconsistency that arises when access control is distributed across teams.
Native identity provider integration
TrueFoundry's MCP Gateway integrates directly with enterprise identity providers — Okta, Azure AD, and custom OIDC IdPs — so agent roles stay synchronised with your organisational structure. When roles change in your IdP, those changes propagate to tool-level permissions automatically. There is no separate permission system to maintain; your existing identity infrastructure becomes the source of truth for MCP access control.
Federated authentication with Auth 2.0
TrueFoundry supports federated login and OAuth 2.0 with dynamic discovery to secure tokens across all MCP server connections. Agents authenticate once with the gateway and receive scoped access to exactly the tools their role permits — no credential sprawl, no embedded secrets. On-Behalf-Of flows ensure agents act with the initiating user's identity and permissions, not a broad service account.
Environment-aware RBAC
TrueFoundry's MCP Gateway supports environment grouping — dev, staging, and production MCP servers each carry separate RBAC rules. A developer can freely access dev-environment tools while building and testing agents, but promoting to staging or production requires satisfying stricter access policies. This mirrors the environment promotion workflows platform teams already use for application code.
Complete audit trail for compliance and right-sizing
Every tool invocation that passes through TrueFoundry's MCP Gateway is logged against the calling agent's identity, the target tool, and the parameters used. This produces the audit trail needed for compliance reviews, incident investigation, and the quarterly access right-sizing reviews described earlier. When it's time to tighten over-permissioned roles, the data is already there — no instrumentation required.
Out-of-the-box integrations and custom MCP servers
TrueFoundry ships with prebuilt MCP server integrations for Slack, Confluence, Sentry, Datadog, and other enterprise tools — ready to enable with RBAC policies applied from day one. For internal or proprietary APIs, TrueFoundry's bring-your-own MCP server capability lets teams register any service as an MCP server in minutes, making it discoverable and governed through the same centralised gateway.
Enterprise-grade deployment options
TrueFoundry's MCP Gateway is deployable across VPC, on-prem, air-gapped, and multi-cloud environments. It meets SOC 2, HIPAA, and GDPR compliance standards, with 24/7 enterprise support and SLA-backed response times. No data leaves your domain — access control enforcement and audit logging happen entirely within your infrastructure.
Common RBAC mistakes in MCP deployments
The most frequent access control failure in MCP deployments is the service account antipattern: running all agents under a single, broadly privileged service account that has access to everything. This feels convenient in development — no permission errors, no access denied — and is a serious risk in production, because any agent compromise becomes a full-system compromise.
The second most common failure is role proliferation: creating a new bespoke role for every new agent, resulting in hundreds of roles that nobody can reason about. A small, well-defined role taxonomy applied consistently is easier to maintain and audit than a large collection of single-agent roles.
Top comments (0)