TL;DR: MCP auth verifies who connected, but agent authorization decides what that delegated agent may do at runtime, and OAuth alone does not express consent scope, tool risk, or session drift, according to PermitIO. The control gap is not login success but governed delegation, where entry checks are mistaken for operational authority.
At a glance
What this is: This article explains why MCP authentication and agent authorization are separate controls, with OAuth covering connection establishment but not runtime delegated behaviour.
Why it matters: IAM and security teams need separate controls for delegated agent actions because identity proof at login does not answer what an agent may do after entry, especially across risky tools and changing context.
Context
MCP creates a trust problem when teams assume that successful authentication is the same as governed access. In practice, the system can prove that a human or client connected, while still leaving the delegated agent free to act beyond the intended scope.
That gap is especially relevant for agentic AI identity and non-human identity governance because the acting subject is no longer just a session token or a logged-in user. The core question becomes what the agent may do on behalf of that identity, in that moment, across tools with different risk levels.
Key questions
Q: What breaks when teams treat MCP auth as the same thing as agent authorization?
A: They end up trusting connection setup as if it were governing behaviour. That creates a gap where the agent can remain authenticated while still being allowed to use tools, actions, or contexts that were never intended by the delegating human. The result is connected but under-governed agent activity.
Q: Why do OAuth flows not fully govern agent behaviour in MCP systems?
A: OAuth can establish delegated access, but it does not by itself encode tool risk, changing context, or the full business meaning of an action. In MCP, those missing details matter because the agent may continue acting after the initial token is issued. Runtime policy is still required.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.
Q: What happens when a delegated agent moves beyond its original consent scope?
A: The risk is not just policy drift, but uncontrolled action across tools that were never meant to be equally accessible. Once the session can expand beyond the original consent boundary, teams lose the ability to explain why a particular action was allowed. That weakens both containment and accountability.
Technical breakdown
Why MCP authentication stops at entry
MCP authentication verifies the connecting subject and the session boundary, often through OAuth, SSO, or API keys. That proves who entered the system and that the connection came through a recognised trust path. It does not express whether later tool calls remain within delegated intent, because the authentication event only establishes admission, not operational authority. In agent systems, that distinction matters more than in human-only workflows because the same session can expand across tools, context, and downstream actions. The control boundary therefore has to move from login success to runtime evaluation of each action.
Practical implication: treat MCP auth as admission control, not as the final decision on what the agent may do.
How agent authorization governs delegated actions
Agent authorization answers a different question from authentication: what may this agent do for this human, with which tool, under which consent scope, and in what context right now. That requires policy logic that can combine identity, delegated authority, tool sensitivity, and action type at runtime. It is the control that narrows a human’s broader entitlement into a smaller agent permission set when needed. Without that layer, the system cannot distinguish a harmless read action from a destructive one once the agent has a valid token. Authorization is therefore the governance layer that makes delegated identity safe enough to operate.
Practical implication: evaluate agent actions at runtime against policy, rather than trusting the initial token to carry the full decision.
Why OAuth alone leaves scope and session drift unresolved
OAuth is useful for delegated access, but it was never meant to carry the full semantics of agent behaviour. It can prove that a client obtained a token under a recognised flow, yet it does not by itself encode tool risk, evolving consent boundaries, or whether the session has drifted away from the original intent. That is why a valid token can still coexist with unsafe behaviour. In MCP, the hard part is not issuing the token but deciding whether each downstream action still fits the approved delegation. The missing control is governance over execution, not just authentication mechanics.
Practical implication: add policy and consent checks around token use, especially where agents can chain actions across multiple tools.
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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Auth and authorization collapse into different control problems in MCP. Authentication answers whether the agent or client may enter the system, while authorization answers what delegated behaviour is allowed after entry. In agentic workflows those are no longer adjacent questions, because runtime decisions can vary by tool, context, and risk. Practitioners should treat entry trust and operational authority as separate governance layers.
Runtime delegation is the real identity problem in agent systems. A human can authenticate cleanly and still leave behind an agent that has broader behavioural reach than the original consent intended. That is a non-human identity problem, not a classic login problem, because the subject acting is delegated, dynamic, and policy-sensitive. The practical conclusion is that the control point has to move from session establishment to per-action authorization.
OAuth is necessary infrastructure, but it is not an operating model for agent behaviour. It can support delegated access, but it cannot on its own express tool sensitivity, consent scope, or mid-session drift. That means teams that stop at OAuth are governing connection, not conduct. For identity programmes, this is a reminder that delegated authority needs its own policy vocabulary and audit trail.
The named concept here is governed delegation. It is the point where an allowed connection becomes an allowed action, and it is where many agent security programmes are still weak. MCP deployments need explicit separation between who connected and what the agent may do, because those are different questions with different control requirements. Practitioners should design for delegated authority as a runtime state, not a login outcome.
From our research library:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
- Read next: AI Agent Authorisation Guide
What this signals
Governed delegation is the missing control model for MCP. Teams that rely on OAuth alone are still making authorization decisions at the edge of the login flow, which is too early for agentic behaviour. The control has to move to runtime, where tool choice, consent scope, and action sensitivity can be evaluated together.
Agent authorization will become a required companion to authentication in identity programmes that support AI agents. That applies across NHI, autonomous, and human-delegated workflows because the issue is no longer just proving who connected. It is proving what that actor may do once connected, and under what context the answer changes.
Consent scope is the practical boundary practitioners should watch. Once an agent can reuse a valid session across multiple tools, the gap is no longer authentication failure but authority promotion inside an approved identity path. That is where governance teams should focus their policy design and audit evidence.
For practitioners
- Separate admission from authority Document MCP auth as the mechanism for identifying the connected subject, then assign a distinct control for agent authorization so runtime behaviour is governed separately from login success.
- Define consent scopes per tool Record which tools, action types, and trust windows each delegated agent may use, and make those scopes explicit in policy so the same token cannot silently overreach.
- Evaluate every downstream action Check whether each agent request still fits the original delegated intent, especially when the workflow can chain multiple tool calls or change context mid-session.
- Log delegated decisions for audit Capture who delegated the agent, which policy allowed the action, and which tool was touched so investigators can reconstruct behaviour after the session ends.
Key takeaways
- MCP security fails when organisations assume authentication and authorization are the same control, because a valid connection does not define what the delegated agent may do.
- OAuth can support delegated access, but it does not by itself govern tool risk, consent scope, or session drift inside agent workflows.
- The control boundary for agent systems must shift to runtime policy, where each action is checked against delegated intent and operational authority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on the difference between authenticating a session and governing delegated agent behaviour. |
| Recommendation — Separate admission controls from runtime authority checks for every delegated agent action. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article focuses on runtime privilege scope for agents acting on behalf of another identity. |
| Recommendation — Bound agent privilege to delegated scope and re-evaluate it at runtime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about permissions and authorization decisions beyond login. |
| Recommendation — Define and enforce entitlements separately from authentication success. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agentic misuse can turn valid delegated access into broader downstream action across tools. |
| Recommendation — Hunt for delegated access paths that enable movement beyond the intended scope. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | The article argues for runtime policy decisions at the gateway or equivalent control point. |
| Recommendation — Place authorization decisions at the enforcement point, not only at session creation. | ||
Key terms
- Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
- Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Consent scope: The exact set of accounts, actions, and time boundaries a user has approved for a third-party application. In regulated financial workflows, scope is not static. It must be checked whenever data is fetched or a transaction is initiated so access does not exceed the original approval.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org