MCP permissions are now the control plane for AI agent access

At a glance

What this is: This is an analysis of why MCP turns AI agents into tool-using identities and why fine-grained authorization is the difference between safe delegation and over-privileged access.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent tool use with the same discipline they apply to human and machine identities, or risk privilege escalation through the AI channel.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Cerbos's analysis of MCP permissions for AI agent tool access

Context

MCP permissions are the policy layer that determines what an AI agent can do through tools and APIs, and the article argues that this layer is now central to secure agent deployment. The problem is not connectivity. It is that standardized tool access can quickly turn into over-broad delegation if authorization is left as static code, a single token, or a vague trust assumption.

For identity teams, the key question is how delegated access is enforced when the actor is software that can choose actions at runtime. That pushes MCP into the same governance conversation as NHI, IAM, PAM, and workload identity, because the same access decisions now shape whether an agent can read data, write data, or execute real-world transactions.

The article’s core point is that AI agents become materially more risky when tool access is unconstrained, especially in prompt-injection and confused-deputy scenarios. Fine-grained authorization is presented as the control boundary that prevents agent behaviour from outrunning the user’s actual rights.

Key questions

Q: How should security teams implement least privilege for MCP-based AI agents?

A: Start by assigning permissions to individual tools and actions, not to the entire agent session. Then enforce runtime checks against the user’s actual rights, resource attributes, and the request context. If a user cannot perform an action directly, the agent should not inherit that privilege through delegation.

Q: Why do MCP-based agents create new access control risks for IAM teams?

A: Because they turn a model from a text generator into a delegated actor that can reach real systems. Once the agent can send mail, query data, or execute commands, a broad token or static rule can expose far more access than the originating task requires.

Q: What do security teams get wrong about authorization for AI agents?

A: They often assume the initial login or API key is enough. In practice, the risky part is not authentication alone but deciding, on each request, whether the agent should be allowed to use a specific tool under the current user, task, and resource conditions.

Q: How should organisations respond when an MCP tool could trigger destructive actions?

A: Isolate high-impact tools, require explicit policy approval for write or delete operations, and block them by default until the task context justifies access. The safest pattern is to make destructive capability exceptional, visible, and revocable rather than broadly available to every agent.

Technical breakdown

How MCP client-server architecture exposes AI agent privilege

MCP standardizes how an LLM discovers and invokes tools, but the security implication is that the model no longer just generates text. It can request actions through a client-server chain, where the host application brokers calls to servers that expose files, databases, email, or administrative functions. That means the effective identity path is no longer the model alone, but the model plus the delegated tool context. If the server trusts the client broadly, the model inherits access that may be far beyond what the user intended. Practical implication: treat every MCP server as a privilege boundary, not just an integration point.

Practical implication: Map each MCP tool to a distinct entitlement and refuse broad tool bundles that hide write or admin actions behind one shared connection.

Static tokens and hardcoded roles create over-privileged MCP access

The article shows how many early MCP deployments lean on static API keys, coarse scopes, or hardcoded if/else authorization logic. That pattern is brittle because it turns policy changes into code changes and makes tool access all-or-nothing. In practice, that means an agent often receives a single credential that unlocks the full server, even when only one read-only action is needed. Once credentials or scopes are broad, any prompt injection, accidental misuse, or malicious server behaviour inherits that blast radius. Practical implication: replace static access assumptions with runtime authorization decisions tied to user, role, resource, and context.

Practical implication: Move authorization out of application logic and into centrally managed policy so tool access can be narrowed without redeploying the MCP server.

Why dynamic authorization is the right control for AI agent tool use

Dynamic authorization checks every action at runtime and evaluates whether the specific user, task, and resource combination should be allowed. That matters for MCP because agent sessions are not one stable intent. They can shift across tools, data sources, and actions within a single workflow. The article’s central security idea is least privilege applied per tool and per action, with deny-by-default as the safe baseline. OAuth 2.1 and scoped, short-lived tokens help, but only policy evaluation can make those scopes meaningful in context. Practical implication: each tool invocation should be individually authorised, logged, and revocable.

Practical implication: Require per-request policy evaluation so the same agent can read one resource while being blocked from adjacent actions that exceed the user’s rights.

Threat narrative

Attacker objective: The attacker wants to turn delegated AI tool access into unauthorized data exposure, service misuse, or destructive execution through the agent's own permissions.

1. Entry occurs when an AI agent is connected to an MCP server through a broadly trusted client-server path or a static token that unlocks multiple tools.
2. Credential access or abuse follows when the agent receives coarse scopes, hardcoded API keys, or overly broad delegated rights that let one prompt reach many services.
3. Impact occurs when prompt injection, confused deputy behaviour, or a malicious tool endpoint pushes the agent into data leakage, destructive actions, or unauthorized transactions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Fine-grained MCP authorization is now an identity control, not just an application feature. MCP changes AI agents from passive responders into software that can transact, query, and execute. Once that happens, the access decision is no longer about a single API call, but about whether the delegate may use tools at all. The implication is that IAM and PAM teams have to treat tool permissioning as part of identity governance, not as an application-layer afterthought.

Over-broad token scope is the real failure mode in early MCP deployments. The article is describing a familiar security mistake in a new form: one credential or one role often stands in for many distinct actions. That creates an identity blast radius where one exposed or misused token can govern read, write, and admin behaviour together. The practitioner conclusion is that coarse delegation must be broken apart before agent adoption expands.

Prompt injection becomes materially more dangerous when an agent can act directly through tools. A hidden instruction that influences model output is annoying. A hidden instruction that can trigger email, data retrieval, or a transaction through MCP is an access-control event. That means the security issue is not the prompt alone, but the permission surface behind the prompt. Practitioners should read this as a policy enforcement problem first and a content problem second.

MCP permissions expose the confused deputy problem in a sharper form. The article shows that an agent can be tricked into using higher privileges than the initiating user should have had. That means delegated authority is only safe when the server checks who is asking, what resource is in play, and whether the requested action matches the user’s actual rights. The practitioner implication is that identity context must follow the call, not just the session.

Dynamic authorization is the right named concept for this category of risk. It describes the shift from static allowlists and static roles to runtime policy decisions that reflect user, resource, and context. That concept matters because MCP makes tool access fluid, not fixed. The field should expect agent governance to move toward per-action policy evaluation, because anything less leaves tool use broader than intended.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap is why teams should also review OWASP Agentic Applications Top 10 for tool misuse, prompt injection, and agent identity controls.

What this signals

MCP is accelerating the shift from authentication to delegated authority. For practitioners, that means the next governance problem is not whether an AI agent can connect, but whether it can be confined to a narrow task boundary once connected. The operational signal to watch is whether policy enforcement, logging, and revocation are handled centrally rather than inside each application implementation.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025, the control problem starts before the agent even acts. Secrets exposure and coarse authorization tend to travel together, so teams should assume the same deployment maturity gaps will affect both secret handling and tool governance.

As AI toolchains mature, identity programmes will need to distinguish between a user authorizing an outcome and an agent authorizing a sequence of actions. That distinction will shape how teams design approval gates, audit trails, and emergency kill switches for high-risk tools, especially where the agent can move from read access to real-world execution in one workflow.

For practitioners

• Define a per-tool permission model Break MCP capabilities into separate read, write, and administrative actions so no agent receives a bundled entitlement that hides higher-risk functions.
• Replace static access logic with central policy Move authorization out of code branches and into a policy engine that can evaluate user identity, resource attributes, and context at request time.
• Use short-lived delegated credentials Issue scoped credentials that expire quickly and map them to the user’s actual rights so the agent cannot continue acting after the task boundary ends.
• Log and alert on denied tool calls Treat repeated denials, unusual tool combinations, or cross-domain access attempts as investigation signals because they can indicate prompt injection or confused deputy behaviour.
• Review every MCP server as a privilege boundary Inventory which servers can execute commands, move data, or access sensitive systems, then apply approval gates to the highest-risk tools before broader rollout.

Key takeaways

• MCP turns AI agents into delegated actors, so identity governance now has to control tool use rather than just user login.
• Static tokens, coarse scopes, and hardcoded role checks create over-privileged agents that can be misled into data leakage or destructive actions.
• The practical answer is dynamic, per-action authorization with deny-by-default policy, short-lived scopes, and strong auditability.

Key terms

• Model Context Protocol: A standardized way for AI systems to discover and invoke external tools and services. In practice, MCP turns a model into a tool-using client that can request file, data, or workflow actions through a server, which makes access control part of the security design from the start.
• Delegated authorization: A permission model where an actor is allowed to act only within the rights of the user or principal it represents. For AI agents, this means the model should inherit a limited, contextual version of user access rather than broad or standing privileges.
• Confused deputy: A failure mode where a trusted system is tricked into using its own higher privilege on behalf of a lower-privilege requester. In agentic environments, this becomes a serious identity problem because the agent can unintentionally bridge access between users, tools, or services.
• Dynamic authorization: A runtime decision process that evaluates who is asking, what resource is being accessed, and what action is being attempted before allowing it. It matters for MCP because tool access changes with context, and static rules cannot safely cover that variability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: MCP permissions for AI agent tool access and dynamic authorization. Read the original.