Access control · least privilege
MCP Access Control and Least Privilege
Granting an agent access to a server grants it every tool on that server, including the mutating ones nobody was thinking about when they said yes.
The short answer
MCP access control operates at four levels: server, tool, parameter and tenant. Most estates enforce only the first two, which leaves the largest gap — a permitted tool with an unbounded parameter approves its entire range. Least privilege for agents means entitlement granted per tool, bounded per parameter, filtered at discovery, defaulting to nobody, and reviewed against a 30-day usage window rather than against intent. Plus a de-entitlement routine that costs an hour a month and closes more risk than most quarterly reviews.
Four levels, and where estates stop
Access control for MCP is not one decision. It is four, and they are usually implemented in descending order of how many people implement them.
| Level | The decision | Commonly enforced? | What it misses alone |
|---|---|---|---|
| Server | May this agent connect to this server at all? | Almost always | Everything. Connecting grants every tool the server exposes. |
| Tool | May this agent invoke this specific tool? | Sometimes | Magnitude. Permitting transfer permits every amount. |
| Parameter | May this agent invoke it with these values? | Rarely | Nothing — this is where the gap closes. Also the level policy engines exist for. |
| Tenant | May this agent reach this tenant’s records through it? | Rarely, and usually assumed | Cross-tenant exposure through a shared credential, which is a breach rather than a bug. |
The pattern is consistent: enforcement decreases exactly as consequence increases. Server-level access is easy to reason about and nearly worthless as a control; parameter-level access is where the incidents are and it requires a policy layer to express.
RBAC at the tool layer: useful, and not the answer
Roles work for what roles are for. A finance-agent role naming eleven finance tools is legible, reviewable and cheap to evaluate, and it refuses obvious cases before any expensive policy check runs. Keep it.
Two failure modes are worth naming, because both are predictable. The first is role inflation: agents acquire tools continuously, nobody removes them because removal risks breaking something, and within a quarter the finance-agent role names forty tools of which eleven are used. Human role sprawl takes years; agent role sprawl takes weeks.
The second is the composition problem. Roles are reviewed tool by tool, and the risk is in the pairs. Read-customer-records is fine. Send-external-email is fine. Together they are an exfiltration path that no per-tool review has ever flagged, because no per-tool review is looking at pairs.
So review roles as sets. For every role, ask one question: what can an agent holding all of this do that no individual grant would have permitted? The answer is usually one or two combinations, and they are usually worth splitting into separate roles.
The pairs worth checking explicitly: read-sensitive plus write-external, read-any-tenant plus write-any-tenant, and any read tool alongside a tool that can create a share link or a public URL.
Least privilege, made concrete
Least privilege is universally endorsed and rarely operationalised, because the minimum necessary is unfalsifiable in advance. Six rules make it testable.
Default entitlement is nobody
Not the team, not authenticated agents, not everyone-except. A new tool is reachable by no identity until somebody grants it. Every other rule depends on this one, and it is the only one that is free.
Grant at tool level, never server level
Server-level grants hand over the mutating tools along with the read-only ones, which is almost never what the approver had in mind — and they silently extend to tools added later.
Bound the parameters on every mutating tool
Ceilings, allow-lists, row caps, enumerations, date ranges. Reject out-of-range values rather than clamping them, because the attempt is the signal you want in the record.
If a schema permits an unbounded amount, the tool is as dangerous as its maximum. Sort your mutating tools by whether they have a ceiling, then work that list.
Filter discovery by identity
A tool absent from the list is a tool the model cannot be talked into attempting. Enforce at invocation as well — filtering is a surface reduction, not an enforcement point.
Verify against observed usage, not intent
Compare entitlements granted against calls made in the last 30 days. The difference is over-entitlement, and it is the cheapest least-privilege work available because nothing depends on it.
Expire every grant
A grant with no end date is permanent. Set 90 days for anything mutating; renewal is a two-minute conversation, and the renewals nobody can justify are the finding.
Multi-tenant isolation: the failure that is a breach
If an agent serves several customers, or one internal tool spans business units with separate data boundaries, tenant isolation stops being an architectural preference. A cross-tenant read is not a bug report; it is a disclosure with notification obligations attached.
The dangerous pattern is specific and common: one tool, one credential broad enough to see every tenant, and the tenant filter applied inside the tool implementation from a parameter the model supplies. That works until a model supplies the wrong tenant id — which it will, because it is inferring the id from context that may itself contain another tenant’s identifier.
Three ways out, in descending order of strength.
Credential per tenant
The strongest and the most operationally involved. The credential itself cannot see other tenants, so no parameter error can cross the boundary. Correct wherever the backing system supports it.
Tenant bound to identity, not parameter
The calling agent’s token carries the tenant claim; the enforcement point injects it and refuses any request whose parameter disagrees. The model never gets to choose which tenant it is acting for.
Enforced at the enforcement point, not in the tool
If the filter lives in the tool implementation, every tool re-implements it and the weakest implementation sets your posture. Move it outward, once.
Whichever you choose, the test is the same and it takes ten minutes: authenticate as tenant A, pass tenant B’s identifier, and confirm the call is refused and the attempt recorded.
A 30-day de-entitlement routine
Quarterly access reviews are the standard answer and they are ineffective here, because they ask owners to confirm intent and owners confirm intent. A monthly usage diff asks a different question and answers itself.
- 01Pull entitlements granted from the enforcement point. Per identity, per tool.
- 02Pull calls made in the last 30 days from the call record. Per identity, per tool.
- 03Diff them. Entitled-and-unused is the working list. In estates over a year old this is typically 30–50% of grants.
- 04Revoke the unused mutating grants first. Nothing has used them for a month, so the conversation is short and the risk reduction is real.
- 05Alert on used-but-not-entitled. This should be empty. Anything in it means something is bypassing the enforcement point, which outranks every other finding on this page.
An hour a month, and it closes more real exposure than most quarterly review cycles — because it is grounded in what happened rather than in what somebody believes should happen. The capability graph makes the same diff visible as structure.
Built on this thinking
All four levels in one enforcement point
Barzel Central Gateway holds per-tool entitlement, filtered discovery and per-user OAuth/OIDC so tenant is bound to identity rather than to a parameter. BarzelVault evaluates the parameter level with four deterministic outcomes and records every refusal.
Five mistakes worth naming
Server-level grants
The most common and the most expensive: one yes covering every tool the server has now and every tool it gains later.
Reviewing roles tool by tool
The risk is in the pairs, and per-tool review is structurally unable to see them.
Tenant id as a model-supplied parameter
The model infers it from context that may contain another tenant’s identifier. Bind tenant to identity instead.
Access review by attestation
Asking an owner whether a grant is still needed reliably returns yes. Ask the call log instead.
Discovery filtering treated as enforcement
A filtered list reduces the surface. Only a call-time refusal is a control.
Frequently asked questions
What is MCP access control?
The mechanisms determining which agent identities may discover and invoke which MCP tools, with which parameter values, against which tenant’s data. It operates at four levels — server, tool, parameter and tenant — and most estates enforce only the first two.
Should MCP access be granted per server or per tool?
Per tool. A server-level grant hands over the mutating tools along with the read-only ones, and it silently extends to tools the server gains later. Tool-level grants are the minimum granularity at which a yes means something specific.
Is RBAC enough for MCP access control?
No, though it is worth keeping as the cheap coarse filter. Roles name operations but not magnitudes, agent roles inflate within weeks because tools are added and never removed, and roles reviewed tool by tool cannot see the composition risk that lives in the pairs.
What is the composition problem in agent entitlement?
Read-customer-records is fine and send-external-email is fine, but an agent holding both has an exfiltration path that no per-tool review flagged. Review every role as a set and ask what an agent holding all of it can do that no individual grant would have permitted.
How do you apply least privilege to MCP tools?
Six rules: default entitlement to nobody, grant at tool level never server level, bound parameters on every mutating tool and reject rather than clamp out-of-range values, filter discovery by identity while still enforcing at invocation, verify entitlements against 30 days of observed usage rather than against stated intent, and expire every mutating grant after 90 days.
How do you prevent cross-tenant access through an MCP tool?
Bind tenant to identity rather than to a model-supplied parameter — the token carries the tenant claim and the enforcement point refuses any request whose parameter disagrees. A credential per tenant is stronger still where the backing system supports it. Test it by authenticating as tenant A and passing tenant B’s identifier.
Why do quarterly access reviews fail for AI agents?
Because they ask owners to confirm intent, and owners confirm intent. A monthly diff of entitlements granted against calls made in the last 30 days asks a different question and answers itself — in estates over a year old, 30–50% of grants turn out to be unused.
What does used-but-not-entitled in a usage diff mean?
That something is reaching tools without passing the enforcement point. It should be an empty set, and anything in it outranks every other access-control finding you have.
Sources and further reading
Least privilege and RBAC are long-established; the sources below state them in general terms, and OWASP’s API Security work covers the object-level and function-level authorization failures that reappear at the tool layer. The four levels and the 30-day routine are our own.
- 01 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 02 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 03 · OWASPOWASP API Security Top 10 ↗Broken object-level and function-level authorization, which reappear unchanged at the tool layer.
- 04 · OWASPOWASP Application Security Verification Standard ↗Input-validation, authorization and logging requirements restated here in MCP terms.
- 05 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
- 06 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 07 · IETFRFC 8693 — OAuth 2.0 Token Exchange ↗The mechanism for preserving caller authority across a gateway hop.
- 08 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
Last reviewed 24 August 2026. External links open in a new tab; we do not control their content.
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so the evaluation costs an afternoon rather than a purchase order.
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.