MCP security still depends on identity controls beyond OAuth 2.1

At a glance

What this is: This analysis argues that MCP’s new OAuth 2.1 support improves baseline authentication, but it does not solve dynamic authorization, credential sprawl, or privilege overshoot for AI agents.

Why it matters: IAM and NHI teams still need separate controls for ephemeral access, because protocol-level auth alone will not stop agents from using more privilege than a task requires.

👉 Read the source analysis of MCP access control and agentic workflow security

Context

Model Context Protocol, or MCP, is becoming a common way to connect AI agents to tools and data sources, which makes it an identity problem as much as an integration problem. Once agents can call applications through shared tooling, the main question shifts from connectivity to who or what is allowed to act, for how long, and under what constraints. That is the core NHI governance gap here.

The article’s central point is that MCP’s June 2025 OAuth 2.1 support closes an early authentication gap, but the remaining risk sits in the layer above the protocol. AI agents do not behave like static service accounts, so access models that assume fixed roles or persistent credentials are already under strain. That starting position is typical for early agentic deployments, not an edge case.

Key questions

Q: How should security teams govern AI agents that use MCP tools?

A: Start by treating the agent as a non-human identity with its own lifecycle, not as an extension of a user account. Issue the minimum access needed for the task, monitor tool calls, and remove access automatically when the workflow ends. MCP connectivity does not replace identity governance; it increases the need for it.

Q: What is the difference between MCP authentication and authorization?

A: Authentication proves the agent or client is allowed to connect, while authorization determines which tools, data sets, and actions it can actually use. In MCP environments, both matter, because a correctly authenticated agent can still be over-privileged if its policy scope is too broad.

Q: When does JIT access reduce risk for AI agents?

A: JIT access reduces risk when the agent’s permissions are created for a single task, expire automatically, and are narrow enough that a mistaken tool call cannot reach unrelated systems. It is less effective when teams simply issue a temporary version of an already broad role.

Q: Should organisations replace static secrets before adopting more agentic workflows?

A: Yes. Static secrets create durable failure points that scale poorly once agents begin calling multiple tools and services. Organisations should remove embedded credentials first, then layer in runtime authorization, because rotating a secret is not the same as governing the access path behind it.

Technical breakdown

MCP authentication with OAuth 2.1: what it fixes and what it leaves open

MCP servers now use OAuth 2.1 to authenticate protected resource requests, which means the protocol can rely on access tokens and authorization server discovery instead of ad hoc connection patterns. That improves the base security posture, but it does not define task-level privilege, dynamic scope changes, or cleanup after use. In practice, OAuth 2.1 answers who can authenticate, not how much access an agent should retain once it is inside the workflow. The remaining risk is architectural: a valid token can still carry excessive permissions if the policy behind it is too broad or static.

Practical implication: Treat OAuth 2.1 as the foundation, then add task-scoped authorization and automatic access removal above it.

Why hardcoded secrets remain the fastest path to MCP exposure

Many MCP deployments still begin in development and experimentation modes, where teams embed credentials in configuration files or reuse human credentials for convenience. That is a familiar NHI failure pattern: the system is treated as temporary, but the credentials become durable. Because MCP clients and servers are evolving at different speeds, older deployments may continue to depend on static tokens even after newer auth support exists. The technical risk is not just credential theft. It is the creation of hidden, unmanaged access paths that bypass governance, audit, and revocation workflows.

Practical implication: Inventory MCP configs for embedded secrets and replace static tokens with short-lived retrieval and rotation patterns.

Least privilege for agentic workflows requires runtime scope changes

AI agents are non-deterministic, which means their tool use can change from one task to the next and even within the same workflow. That makes fixed role assignments brittle. A token issued at creation time often has to cover the maximum possible access path, which is the opposite of least privilege. The better pattern is just-in-time provisioning with zero standing privilege, where access is created for a narrow task, used, and then removed. For MCP, this matters because tool calls can expose many more backend capabilities than the agent actually needs.

Practical implication: Design access so the agent can request the minimum profile at runtime and lose it automatically when the task ends.

Threat narrative

Attacker objective: The attacker wants to turn agentic tool access into a low-friction path to data exposure, unauthorized change, or destructive action.

1. Entry occurs when an employee or developer connects an AI agent to an MCP server using embedded credentials or over-broad OAuth tokens.
2. Escalation follows when the agent inherits a human identity or broad role that grants more backend access than the immediate task requires.
3. Impact occurs when the agent executes unintended reads, updates, or deletions through exposed tools that were not scoped tightly enough.

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

OAuth 2.1 is necessary, but it is not an agent governance model. The protocol update improves baseline authentication, yet MCP still leaves the hard part to implementers: scope, context, and lifetime. NHI governance fails when teams mistake a transport control for an access policy. Practitioners should treat protocol support as a starting point, not as proof of control.

Ephemeral credential trust debt: the longer teams keep temporary agent access patterns in place without cleanup, the more those patterns behave like standing privilege. MCP makes rapid experimentation easy, and that is exactly how hidden access paths proliferate. The discipline required is not just issuance, but revocation and reuse control. Practitioners should measure how quickly agent access disappears after the task ends.

Agentic workflows collapse the old boundary between authentication and authorization. A tool-connected agent can authenticate correctly and still be unsafe if the policy layer cannot narrow access to the immediate task. That is why IAM, PAM, and NHI controls now have to operate together rather than in sequence. Practitioners should align agent access reviews to actual tool use, not to static job roles.

MCP adoption is accelerating the market’s shift from secret management to runtime identity governance. Static secrets and fixed roles cannot keep pace with tool-rich agent environments, especially where developers move faster than central security teams. This does not validate every vendor claim about agent security, but it does validate the problem space. Practitioners should prioritise controls that can scope, issue, and revoke access at runtime.

Least privilege for AI agents has to be observable, not assumed. If teams cannot see which tools an agent can call, which resources it touched, and when access expired, they do not have governance. That lack of visibility creates audit and incident response blind spots. Practitioners should demand policy evidence, not just protocol compliance.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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, according to AI Agents: The New Attack Surface report.
• For a broader control baseline, see Ultimate Guide to NHIs for lifecycle governance patterns that carry over into agentic access.

What this signals

Agentic identity governance will move from exception handling to default control design. Once organisations accept that AI agents can change their access needs mid-task, static role models stop being adequate. The practical shift is toward runtime issuance, expiry, and evidence of cleanup, especially for tool-connected workflows that cross multiple systems. Teams that still rely on persistent entitlements will find audit and containment more difficult as usage scales.

Identity blast radius becomes the useful metric for MCP programmes. The question is no longer whether an agent can authenticate, but how far one compromised credential or over-broad token can reach across tools and downstream applications. That framing aligns naturally with least privilege and Zero Standing Privilege. Security leaders should use it to prioritise which agent workflows require tighter policy, stronger logging, and more frequent review.

With 92% of organisations agreeing that governing AI agents is critical to enterprise security, yet only 44% reporting any policies in place, the gap is no longer awareness but operational maturity, according to AI Agents: The New Attack Surface report. The same pattern will show up in MCP programmes unless security teams insist on policy evidence, not just integration success. Practitioners should prepare for governance reviews that focus on actual access paths, not just protocol adoption.

For practitioners

• Remove static credentials from MCP paths Search MCP client configurations, scripts, and environment files for embedded tokens or reused human credentials, then replace them with short-lived retrieval and rotation controls.
• Enforce task-scoped agent access Map every agent to the minimum tool and resource set required for a specific workflow, then issue access only at runtime and remove it automatically after completion.
• Separate authentication from authorization reviews Review MCP token handling, tool permissions, and downstream resource entitlements as distinct controls so a valid login does not imply broad system access.
• Add agent access logging and expiry checks Log each tool invocation, granted profile, and access end time so security teams can confirm that no standing privilege remains after the workflow finishes.

Key takeaways

• MCP improves authentication, but agentic security still depends on runtime authorization, credential hygiene, and access expiry.
• AI agents already exceed intended scope in most organisations, which means over-privilege is a live governance problem rather than a future scenario.
• The control objective is shrinking identity blast radius for tools, data, and actions, not simply making agents able to connect.

Key terms

• Model Context Protocol: MCP is an open protocol that lets AI clients and agents connect to tools and data sources in a standard way. In security terms, it creates a new identity boundary because tool access, not just model output, now determines what an agent can reach and change.
• Non-Human Identity: A non-human identity is any machine-, service-, or agent-based account that can authenticate and act in an environment. These identities need their own lifecycle, policy, and review model because they often operate faster, more broadly, and with less direct oversight than human users.
• Zero Standing Privilege: Zero Standing Privilege means access is not permanently assigned. Credentials or roles are created only when needed, used for a specific task, and then removed, which reduces the chance that dormant access can be abused by a compromised system or autonomous agent.

Deepen your knowledge

MCP security, NHI lifecycle controls, and just-in-time access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from static automation to agentic workflows, it is worth exploring.

This post draws on content published by Britive: Securing MCP Workflows, Dynamic Agentic AI Access Control. Read the original.