RBAC for AI Agents: How to Control Who Accesses Which MCP Tools
Role-based access control (RBAC) for AI agents works by routing every AI client through a gateway, provisioning that gateway to specific teams, and allowlisting the individual tools each server exposes on it. A role decides what a person is allowed to do, a team decides which gateways they can reach, and the per-server allowlist decides which tools exist at all. Without that chain, every agent inherits whatever its user’s credential can reach, and nothing in the protocol records what happened.
This guide walks through how to set up RBAC for MCP servers, apply least privilege to AI agents, and provision tool-level permissions using an MCP gateway. It is written for platform engineering and security teams evaluating how to govern MCP access across their organization.
Key Takeaways
- RBAC for AI agents rests on two independent controls. A role grants capabilities workspace-wide, a team grants access to gateways, and effective access is the intersection of the two.
- Least privilege for agents means scoping below the human user’s permission level, because an agent enumerates everything in scope at machine speed rather than opening a handful of records.
- Tool-level provisioning is allowlist-only and fail-closed. It is enforced at the gateway, so it works even when the upstream vendor offers no tool-level controls.
- Guardrails in MCP Manager are configured per gateway, not per user, which makes the gateway the smallest unit of governance.
- Per-user identity through SSO is what turns a log line into evidence. Okta’s Global CISO Insights 2026 found that 21% of organizations still use shared credentials or broad-permission service accounts to govern AI agent access.
Why Standard Permissions Don’t Work for AI Agents
A person with access to your CRM opens a few records, reads what they need, and moves on. An agent with the same credentials enumerates everything in scope and passes it into a model context. The access is technically identical. The exposure is not.
The gap is already operational rather than theoretical. The 2026 CISO AI Risk Report, based on 235 large-enterprise security leaders, found that 71% say AI tools already reach core business systems while only 16% govern that access effectively, and that 86% do not enforce access policies for AI identities at all.
The Machine-Speed Problem
The mechanism is mundane. When a remote MCP server is connected with a long-lived token, every tool call runs with that token’s full scope. GitHub’s remote MCP server, for example, authenticates with a Personal Access Token, so an agent holding it can list and read every repository the token permits. A model issues those calls in sequence without pausing, so the practical read volume is bounded by rate limits rather than by attention.
The same pattern holds for CRM servers, analytics tools, and internal APIs. Human permissions were sized for human throughput. That is why AI agent access control has to be more restrictive than the underlying user’s permissions rather than equivalent to them.
What “Least Privilege” Actually Means for Agents
Least privilege for AI agents means the agent reaches only the servers, tools, and data categories its user’s role requires. Not everything the user could theoretically access, and not everything the MCP server exposes.
In practice this breaks into three layers:
- Server-level access: Which MCP servers is this team’s gateway wired to at all?
- Tool-level access: Within a given server, which tools pass the gateway’s allowlist?
- Data-level filtering: What content gets blocked or rewritten before it reaches the model?
All three are enforced at the MCP gateway. The MCP spec governs the connection, not the policy. The 2026-07-28 revision hardened authorization with RFC 9207 issuer validation and formally deprecated Dynamic Client Registration in favor of Client ID Metadata Documents. The Enterprise-Managed Authorization extension lets an IdP decide centrally which servers an employee may connect to. Both settle whether a connection happens. Neither decides whether an individual tool call should proceed, inspects what it returns, or records it.
How to Set Role-Based Access for MCP Servers
MCP Manager handles MCP access control through capability-based roles and team-scoped gateways. Here is how the pieces fit.
Step 1: Define Teams Based on Job Function
Create teams that map to how your organization actually works. Sales does not need the GitHub server. Engineering does not need the HubSpot server.
Teams in MCP Manager sync from your identity provider over SCIM 2.0. Your IdP pushes groups, and you map each pushed group to a team once. Two details matter operationally:
Mapping is a manual confirmation step, so a newly pushed group grants nothing until it is mapped. And SCIM syncs team membership, not roles, so a provisioned user always lands on the workspace default role until an administrator changes it. Deactivation in the IdP is a soft deactivation: workspace membership ends, but the user record is retained so existing log entries still point at the real person.
Step 2: Provision Gateways, Not Servers, to Each Team
This is where most RBAC designs for MCP go wrong. A team does not receive servers. A team receives gateways, and a gateway aggregates the servers an administrator assigned to it behind one governed URL.
The consequence is architectural. The gateway is the smallest unit of governance: rules, tool provisioning, and identity scheme all live there, and there is no setting below it that applies a different policy to some users on the same gateway. When one group needs a stricter rule or a narrower tool set, you stand up another gateway and provision it to that team. A user’s access is the union of their teams, and their permitted actions are the intersection of that access with their single role.
Step 3: Set Tool-Level Permissions Within Each Server
A single MCP server usually exposes many tools. A Jira server might offer reading tickets, creating them, updating fields, and deleting issues. QA may need read access, project leads read and write, and nobody outside administration should hold delete.
Feature provisioning controls this per server, per gateway, and independently for tools, prompts, and resources. Three properties are worth knowing before you design around it:
- It is allowlist-only. There is no “allow everything except these” mode. Switching a type from “allowing all” to “allow if conditions are met” exposes zero capabilities until you add entries, including any tool the vendor adds or renames later.
- It is enforced by the gateway. A vendor that offers no tool-level enable or disable controls is governed exactly like one that does. A filtered tool is invisible and uncallable, and a direct call to it is blocked and logged.
- Tools can be pinned by metadata. Each allowed tool is admitted only if its name, title, or description still matches what you approved. Pinning on the description is the control that stops a rug pull, because rewritten metadata no longer matches and is dropped instead of reaching the model.
MCP tool annotations such as readOnlyHint and destructiveHint are surfaced for filtering, but the spec is explicit that they are hints rather than guarantees. Treat them as triage, not as a security boundary.
Step 4: Apply Guardrails per Gateway
Each gateway carries its own rules, which inspect tool calls on the request leg and tool results on the response leg. Three classes of detection are available: JavaScript regular expressions running in-process with five actions (block, redact, replace, mask, hash), Microsoft Presidio for contextual PII such as names and addresses, and custom rule engines including AWS Bedrock Guardrails, Google Model Armor, Lakera Guard, or your own webhook.
Two limits belong in any design review. Rules run on tools/call traffic only, so prompts and resources are governed by provisioning rather than by inspection. And the failure modes differ by method: custom engines default to blocking on failure, Presidio defaults to allowing the original message through, and regex has no failure mode because there is no external call to fail. Set this deliberately on the rules that protect regulated data.
Step 5: Enforce Per-User Identity Through SSO
Shared service accounts destroy attribution. If several engineers share one credential, no log can say which of them triggered a call that read customer data.
MCP Manager sets an identity scheme per server: either every user authenticates as themselves, so the downstream system enforces their own permissions, or everyone shares one service account. With per-user identity, each log entry records the user, the gateway, the server, the tool, the identity used upstream, the request and response, latency, and any rule verdict. One exchange is written as four correlated legs, and logs export to any OpenTelemetry collector, including Datadog, Splunk, Grafana Cloud, New Relic, and Honeycomb. Default retention starts at 14 days, which is the argument for forwarding rather than relying on in-product storage.
RBAC for MCP in Regulated Environments
Governance requirements differ by sector, but they converge on the same underlying demand: prove that access was scoped, that sensitive data was controlled in flight, and that every action can be traced to a real identity. The same gateway configuration that implements RBAC also produces the evidence these frameworks ask for.
Financial Services Under DORA
Article 9(4)(c) of Regulation (EU) 2022/2554 states the least privilege duty as a legal obligation, limiting access to information and ICT assets to what legitimate and approved functions require. The supplementing technical standards in Commission Delegated Regulation (EU) 2024/1774 specify the identity management, access control, and logging requirements behind it. An agent operating on a shared token satisfies none of this, because the access is neither uniquely identified nor reviewable.
Healthcare Under HIPAA
The Security Rule requires access controls and audit controls over systems holding electronic PHI. Two gateway-level controls map onto it directly: per-user identity so each call is attributable, and response-leg rules that replace detected entities before a result reaches the model.
Mixed-Sensitivity Estates
Because rules are scoped to a gateway, a CRM server carrying customer PII and an internal ticketing server can sit under different postures without splitting your identity model. That is the intended use of multiple gateways rather than a workaround.
Best Practices for AI Agent Access Control
Effective access control for AI agents combines four things: visibility into what is connected, access scoped below human permission levels, identity centralized through the organization’s existing provider, and enforcement that spans both the gateway and the endpoint. Skipping any one leaves a gap the others cannot cover.
1. Start With an Inventory
You cannot govern what you cannot see, and the visibility gap is the dominant finding across current research: 92% of the CISOs surveyed in the 2026 CISO AI Risk Report lack full visibility into their AI identities. Map what is connected before setting policy.
2. Scope Below Human Permissions
“They already have access” does not transfer to agents. Set agent access to the minimum the task requires, then widen it on evidence.
3. Use Your Existing Identity Provider
Do not build a parallel identity system. Sign-in is federated OIDC and provisioning is SCIM 2.0, so Okta, Entra ID, and other conformant IdPs carry over.
4. Pair the Gateway With Endpoint Controls
An MCP gateway governs what passes through it and nothing else. Restrict connectors in your AI clients’ admin settings to the gateway URL, and reinforce with MDM on managed devices. A gateway alone cannot stop a client from connecting directly to a server outside it, which is why this is treated as defense in depth rather than a single control.
5. Do Not Forget Local Servers
Servers running on developer laptops are invisible to most gateways. MCP Manager connects them as workstation servers through a Docker-based tunnel agent over WireGuard, outbound only, so a local server gets the same provisioning, rules, and audit trail as a remote one.
Conclusion: RBAC Is What Makes MCP Access Governable
RBAC for AI agents is not about restricting what people can do. It is the mechanism that lets you approve MCP access broadly without accepting uncontrolled risk. Teams get the servers and tools they need, administrators get the visibility and control they need, and compliance gets an audit trail that names a person.
If your team is evaluating how to roll out MCP access without the “Wild West” problem, see MCP Manager in action and request a walkthrough of the RBAC and tool-provisioning model described above.
FAQ
How do I control who can access which MCP tools?
Assign servers to an MCP gateway, allowlist the specific tools each server exposes there, and provision that gateway to the teams that should reach it. Enforcement happens at the gateway, with each call attributed to a user through SSO.
How do I apply least privilege to AI agents?
Scope agent access below the human user’s permission level. Restrict which gateway a team can reach, which tools pass the per-server allowlist, and what data categories are filtered before a result reaches the model.
How do I set role-based access for MCP servers?
Sync teams from your IdP groups over SCIM, build a gateway with the servers that group needs, set each server’s tools to “allow if conditions are met,” and provision the gateway to the team. Roles are assigned separately inside MCP Manager, since SCIM syncs teams rather than roles.
Can RBAC policies differ between teams using the same MCP server?
Yes, by giving each team its own gateway. Rules, tool allowlists, and identity schemes are all configured per gateway, so the same upstream server can appear on two gateways under different policies.
Does MCP Manager support local MCP servers for RBAC?
Yes. A workstation server runs locally and connects through an outbound WireGuard tunnel started by a Docker agent, so it is never exposed to the internet and still receives the same provisioning, rules, and audit logging as a remote server.
How are agent actions attributed to individual users?
Every call is logged with the authenticated user, the gateway, the server, the tool, the identity used upstream, and any rule verdict, correlated across the four legs of one exchange. Logs export over OpenTelemetry to Splunk, Datadog, Grafana Cloud, New Relic, or Honeycomb.
Is tool-level permission the same as read versus write access?
Read versus write is the most common split, but the allowlist covers any tool a server exposes, and entries can also gate on the tool annotations a server reports. Those annotations are hints from the upstream server, so pair them with name and description pinning rather than relying on them alone.
