MCP auth vs agent authorization: why OAuth alone falls short

At a glance

What this is: This is an analysis of why authentication and authorization diverge in MCP agent systems, with the key finding that OAuth proves connection, not runtime control.

Why it matters: IAM, NHI, and agent governance teams need to separate session admission from delegated action control, or they will overtrust authenticated agents that can still act outside intended scope.

👉 Read PermitIO's analysis of MCP auth vs agent authorization

Context

Model Context Protocol creates a new identity problem when a delegated agent can keep acting after a successful login. The issue is not whether the human or client can authenticate, but whether the agent should be allowed to perform each action in context, right now.

That distinction matters because agents do not behave like bounded user sessions. Once tool discovery, chained actions, and downstream calls enter the picture, traditional OAuth and SSO assumptions stop answering the governance question that identity teams actually need to control.

Key questions

Q: How should security teams govern delegated MCP agents beyond OAuth?

A: Security teams should treat OAuth as the entry mechanism, not the full control model. They need explicit runtime authorisation that checks delegated scope, tool sensitivity, consent context, and current risk before each meaningful action. Without that second layer, authenticated agents can still operate outside intended authority.

Q: Why do authenticated agents still create security risk in MCP environments?

A: Authenticated agents still create risk because authentication only proves that a subject entered the system. It does not prove that the next tool call, data access, or transaction is still allowed under the original delegation. That gap becomes dangerous when agent behaviour changes across tools or sessions.

Q: What breaks when teams rely on OAuth as their only agent control?

A: What breaks is the assumption that a valid token equals safe behaviour. OAuth can establish delegated access, but it does not by itself enforce consent scope, action sensitivity, or runtime policy. Teams then lose the ability to stop an agent after login but before a risky downstream action.

Q: How can organisations tell whether MCP authorisation is actually working?

A: They should look for evidence that policy decisions happen after authentication and before high-risk actions. If the organisation cannot explain who delegated the agent, which tools were in scope, and why each action was allowed, authorisation is incomplete even if login telemetry looks clean.

Technical breakdown

MCP auth establishes entry, not delegated authority

MCP authentication verifies that a human, client, or session is trusted enough to enter the gateway or server boundary. OAuth, SSO, and API keys can prove identity and establish a valid session, but they do not express the continuing business meaning of each downstream action. In agent systems, that omission matters because the actor is not only connected, it is delegated. The same authenticated session may touch tools with very different risk, intent, and blast radius. Authentication therefore answers a narrow question: who got in under what trust mechanism.

Practical implication: separate session admission controls from action-level policy enforcement at the MCP boundary.

Why runtime authorisation has to understand delegation

Agent authorisation asks a different question from login. It asks what this agent may do for this human, against this tool, in this context, at this moment. That requires consent scope, tool metadata, trust tier, and action sensitivity to be evaluated together. A human may be allowed to read data, while the delegated agent should only read a subset or avoid destructive actions entirely. Runtime policy is what preserves that distinction when session state, context, or intent changes mid-flow.

Practical implication: evaluate delegated scope on every high-risk tool call instead of treating the initial token as sufficient.

Why OAuth alone cannot govern agent behaviour

OAuth is useful for delegated access, but it was not designed to encode every security and governance decision that arises after the token exists. It can show that access was granted, yet it cannot by itself tell you whether the current action still fits approved intent, current trust conditions, or operational risk. That is why agent systems expose a governance gap that looks familiar but behaves differently from classic application auth. The control failure is not missing identity proof. It is missing authority proof for each action.

Practical implication: add policy evaluation, auditability, and revocation paths that operate after authentication has already succeeded.

NHI Mgmt Group analysis

Authority without runtime policy is not agent governance. MCP deployments that stop at OAuth or SSO confuse connection legitimacy with delegated authority. The actor can be authenticated and still be under-governed if the system cannot decide what it may do after entry. The practitioner conclusion is simple: the control boundary must move from login to action.

Delegated agent identity creates an authority gap that human IAM models do not close. Human identity controls assume the subject and the acting intent are closely aligned. In MCP, the human, the token, and the agent can diverge in practice, which means identity proof alone cannot preserve governance. The practitioner conclusion is that delegated identity must be treated as its own control problem.

Runtime authorisation is the real policy surface for MCP systems. The meaningful decision is not whether the agent connected successfully, but whether the next tool call is still inside consent, context, and risk tolerance. That is why action-level policy, not authentication alone, becomes the operational control. The practitioner conclusion is to govern every agent action as a separate authority event.

Identity does not select or combine tools dynamically mid-session was designed for bounded session behaviour. That assumption fails when the actor is an agent that can chain tool calls, reuse context, and adapt execution order without a new login event. The implication is that access review cadences and static role assumptions no longer describe the real control problem. The practitioner conclusion is to rethink governance around runtime decisions, not session start.

Zero standing privilege is not enough if the authority model still collapses login and action. Even ephemeral credentials do not solve the governance problem when the system cannot distinguish authenticated presence from permitted behaviour. The issue is not only credential lifetime, but whether the delegation model can constrain what the agent does after it enters. The practitioner conclusion is that privilege must be evaluated at action time, not inferred from the login flow.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how weak confidence remains across machine identity governance.
• That same governance gap is why teams should review the Ultimate Guide to NHIs , Static vs Dynamic Secrets when moving from connection setup to runtime control.

What this signals

Delegated identity is becoming the control point that most IAM programmes still under-specify. Once agents can act through inherited credentials, the real programme question is no longer whether the session authenticated, but whether every tool call still matches approved authority. Teams should expect more demand for action-level policy, stronger audit evidence, and clearer consent boundaries across agent workflows.

Runtime control will increasingly sit above traditional SSO and OAuth layers. That means identity teams will need to evaluate gateway enforcement, delegated consent capture, and action revocation as first-class governance capabilities. The organisations that treat MCP as a pure authentication problem will keep discovering that authorised access is not the same thing as authorised behaviour.

For practitioners

• Separate admission from authorisation Define one control path for authenticating the human or client and a second path for approving each agent action against policy, consent scope, and tool risk.
• Bind delegation to specific tools and actions Record which human delegated authority, which tools were in scope, and whether the agent was read-only, transactional, or destructive for that session.
• Evaluate policy at runtime Require the gateway or control plane to re-check intent, context, and trust tier before high-risk downstream calls instead of trusting the initial token.
• Add audit trails that explain authority decisions Capture enough decision evidence to reconstruct why each tool call was allowed, denied, escalated, or revoked during the agent session.

Key takeaways

• MCP systems expose a governance gap when authentication and authorisation are treated as the same control.
• The evidence points to a broad visibility problem in delegated access, which makes runtime policy more important than login success.
• Teams need to govern agent actions after entry, or OAuth will continue to overstate how much security has actually been achieved.

Key terms

• Mcp Authentication: The control that proves a client, human, or session is allowed to enter an MCP environment. It establishes identity and trust at the boundary, but it does not define what the connected actor may do after entry. In agent systems, that distinction is foundational.
• Agent Authorisation: The policy layer that decides what a delegated agent may do on behalf of a human or workflow. It evaluates tools, consent scope, context, and action risk at runtime, rather than assuming that a valid login or token is enough to permit every downstream call.
• Delegated Identity: An identity relationship in which one actor, usually a human, grants another actor permission to act on its behalf. In MCP and AI systems, delegated identity must be constrained by explicit scope because the agent’s behaviour can diverge from the human’s intent during execution.
• Runtime Policy Evaluation: The process of checking whether a specific action should be allowed at the moment it is requested. It is more precise than static role assignment because it can account for tool sensitivity, consent window, current context, and changing trust conditions.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: MCP auth vs agent authorization and why OAuth alone does not solve agent security. Read the original.