MCP security still depends on identity controls beyond OAuth 2.1

At a glance

What this is: This analysis argues that MCP’s OAuth 2.1 support improves authentication, but does not by itself solve identity, privilege, or zero-standing-access problems in agentic workflows.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an access-governance problem, because agent behaviour can expand privilege use beyond what the protocol can safely constrain.

Context

MCP, or Model Context Protocol, is a standard for connecting AI agents and LLMs to tools and data sources. In practice, that means the security question is not just whether the protocol authenticates requests, but whether the identity behind those requests is governed with the same discipline as any other non-human identity.

The article’s core point is that OAuth 2.1 improves the base protocol, but implementation choices still determine whether an agent gets static credentials, broad tokens, or short-lived access with task-scoped limits. For IAM and PAM teams, this moves MCP into the same governance conversation as workload identity, secrets, and privileged access control.

Key questions

Q: What breaks when AI agents rely on static OAuth scopes for MCP access?

A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action. In MCP, the agent can chain tool calls, change context, and trigger downstream effects that were never visible when the scope was granted. Security teams need per-action authorization, not just valid authentication.

Q: Why do static credentials increase risk for service accounts and automation workflows?

A: Static credentials raise risk because they can be hardcoded, copied across systems, or left unrotated for long periods. Once exposed, they give attackers a durable path into cloud workloads, often with permissions broader than the task requires. That combination makes lateral movement, unauthorized access, and data exfiltration easier, especially when credentials are spread across pipelines, microservices, and hybrid environments.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: What is the difference between OAuth 2.1 authentication and least privilege for AI agents?

A: OAuth 2.1 answers the question of how the client proves it is allowed to talk to the resource server. Least privilege answers a different question: how much that client should be allowed to do once it is inside. An MCP deployment can satisfy OAuth 2.1 and still fail badly if the issued token is broad, static, or tied to a powerful human identity.

Technical breakdown

Why OAuth 2.1 is only the first control layer

OAuth 2.1 gives MCP a standard authentication and resource-server pattern, which removes one of the early design gaps in the protocol. But authentication only proves that a client can present a token. It does not determine whether that token is over-scoped, whether the client should be allowed to reuse human credentials, or whether access can shrink dynamically as the task changes. In MCP deployments, those decisions sit in the integration layer, the identity platform, and the target resource, not in the protocol itself.

Practical implication: treat OAuth 2.1 as the entry point, then validate where authorization and privilege boundaries are actually enforced.

Why static credentials remain the easiest path to abuse

The article’s most immediate risk is the continued use of hard-coded secrets and embedded tokens in configuration files and experimental workflows. That pattern turns MCP access into a durable credential problem rather than a governed session problem. If a secret is copied into a client config, it can persist long after the workflow changes, and if the same human account is reused for an agent, the agent inherits whatever privilege the user already holds. This is a classic NHI exposure pattern dressed in new protocol language.

Practical implication: remove embedded secrets from MCP client setups before scaling agent usage beyond isolated testing.

Why agentic access needs just-in-time privilege, not fixed scopes

Agentic workflows do not behave like deterministic service accounts. The article notes that an agent may use one small tool set most of the time, then request a different action that needs higher privilege. A fixed token therefore has to represent the worst-case permission set rather than the typical one, which defeats least privilege. That is why JIT access and zero standing privilege matter here: the privilege model has to follow the task, not the identity label. Without that, MCP becomes a broad access wrapper around a non-deterministic actor.

Practical implication: design MCP access around task-scoped issuance and revocation, not persistent agent entitlements.

Threat narrative

Attacker objective: The attacker objective is to turn agentic access into broad, reusable privilege that can be abused for unauthorized data access or destructive change.

1. Entry occurs when an MCP client connects with embedded credentials, reused human credentials, or a broadly scoped OAuth token.
2. Escalation follows when the agent requests tools or actions that exceed the intended read-only or task-scoped boundary, but the issued privilege already permits them.
3. Impact occurs when that privilege is used for destructive updates, unintended data exposure, or other actions the operator never meant the agent to perform.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

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

NHI Mgmt Group analysis

OAuth 2.1 does not collapse the identity problem inside MCP, it only normalises the transport. The protocol now has a better authentication backbone, but the real governance question is still who can act, with what privilege, and for how long. That means the security programme has to move from protocol approval to identity control enforcement across clients, servers, and target resources.

Static credential reuse is now a governance smell, not a deployment shortcut. When an MCP workflow depends on embedded tokens or human credentials, the organisation has already accepted persistent NHI exposure. That creates a control gap that survives protocol upgrades, because the risk sits in how access is issued and stored, not in whether the protocol supports OAuth. Practitioners should treat this as a secrets governance problem first and an MCP problem second.

Task-scoped access is the only defensible privilege model for agentic workflows. MCP agents can shift behaviour mid-session, which means a fixed entitlement model assumes a stable access pattern that does not exist. Least privilege at provisioning time is no longer enough when the actor can ask for more access after context changes. The implication is that identity governance for agents must be designed around issuance, elevation, and revocation as runtime controls, not annual policy assumptions.

Zero standing privilege becomes the practical boundary for agentic access control. If a workflow can keep credentials alive beyond the task, the control surface has already drifted away from the intended use case. That is why MCP is forcing identity teams to connect PAM, NHI governance, and workflow design into one operating model. The practitioner conclusion is straightforward: if the access outlives the task, the model has failed.

Agentic access is exposing a runtime governance gap that traditional access reviews cannot close. Access reviews were designed for identities whose privilege persists long enough to be certified and recertified. Agent-driven access can be created, expanded, and retired inside a single workflow, which means the old review cadence arrives after the decision point. Practitioners need to recognise that this is not just a faster version of IAM, but a different control problem.

From our research library:

• Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
• Read next: Agentic AI Identity Guide

What this signals

Access reviews were built for privilege that lasts long enough to be observed. In agentic workflows, that assumption can disappear, which is why teams need to move governance closer to token issuance and runtime revocation than most IAM programmes are used to.

Ephemeral credential trust debt: MCP reduces friction for agentic workflows, but every shortcut that leaves a static token behind adds trust debt that later shows up as overbroad access, poor auditability, or revocation gaps. The practical response is to make temporary access the default state, not a special exception.

For practitioners

• Replace embedded MCP secrets Inventory client configurations, scripts, and local dev setups for hard-coded credentials or tokens, then move those secrets into controlled dynamic retrieval so the agent never holds static access.
• Issue task-scoped access for agents Map each MCP tool to the minimum resource profile it needs, and require runtime checkout of that profile instead of pre-assigning a broad token for every possible action.
• Separate human accounts from agent identities Stop letting agents inherit a user’s full personal privilege set, especially where administrators or power users are experimenting with MCP-connected workflows.
• Build revocation into the workflow end state Ensure every agentic task includes automatic check-in or removal of temporary permissions so no standing access remains after completion.
• Review OAuth scopes against actual tool use Compare the permissions granted at token creation with the narrow set of tools the agent actually used, then tighten any scope that exists only to satisfy a hypothetical future action.

Key takeaways

• MCP’s protocol-level improvements do not remove the need for identity governance, because authentication alone does not control privilege scope or access duration.
• Static credentials and reused human accounts remain the easiest way for agentic workflows to accumulate unnecessary blast radius.
• The control that changes the risk profile is task-scoped, zero-standing privilege with runtime revocation, not broader token issuance.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.

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 building or maturing an IAM programme, it is worth exploring.