Runtime authorization for MCP agents: why OAuth alone falls short

At a glance

What this is: This is an analysis of why OAuth alone is too static for MCP-driven AI agents and why runtime authorization is the missing control layer.

Why it matters: IAM teams need to treat MCP agents as non-human identities whose permissions must be decided at action time, otherwise blast radius, auditability, and revocation all lag behind how the agent actually works.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Britive's analysis of runtime authorization for MCP agent access

Context

MCP changes the identity problem because the actor is not just a service calling one API. An AI agent can decide which tool to use next, combine multiple systems in one task, and make those choices while its context is still changing. That makes static OAuth scopes a poor fit for MCP agent identity governance, especially when access must be judged per action rather than per application session.

OAuth, SAML, and OIDC solve different parts of the identity stack, but this article focuses on the gap between delegated authorization and runtime decision-making. For IAM teams, the real issue is that agent intent, data sensitivity, and execution timing shift at runtime, while traditional token-based permissioning assumes the opposite. The result is not simply broader access. It is access that is too durable and too coarse for agentic work.

For practitioners building controls around MCP, the key question is not whether OAuth still has value. It does. The question is whether OAuth is being used as the outer transport layer while another policy layer makes the actual authorization decision, or whether teams are mistaking token issuance for governance. That distinction matters for NHI lifecycle, revocation, and least privilege across cloud, SaaS, and on-prem systems.

Key questions

Q: How should teams secure MCP authorization beyond OAuth scopes?

A: Teams should use OAuth scopes only as a coarse capability layer and enforce the real authorization decision on the server. That means evaluating user role, resource ownership, and request context at runtime, so access changes when policy changes instead of waiting for token expiry.

Q: Why do MCP agents make static access scopes risky?

A: Because agents can sequence multiple tools in one task, and the needed permissions change as the task unfolds. A static scope is either too broad, which expands blast radius, or too narrow, which breaks the workflow. MCP therefore exposes the weakness of provisioning-time authorization when the actor makes decisions at runtime.

Q: What breaks when organizations treat OAuth token issuance as the final control?

A: They lose action-level governance. Token issuance shows that access was granted, but not whether the agent was allowed to use it for this specific resource, at this specific moment, under this specific task context. Without a runtime policy, audits become token logs rather than proof of controlled behaviour.

Q: Who is accountable when an MCP client grants access too broadly?

A: Accountability sits with the team operating the client, the server, and the authorization policy, because MCP failures usually come from broken relationship handling rather than a single bad request. Security and platform teams should document who owns consent registration, token validation, and local execution restrictions.

Technical breakdown

Why OAuth scopes break down for MCP tool chains

OAuth scopes are designed to express pre-approved access boundaries, usually for APIs and user-consented delegation. MCP agents do not behave like fixed client applications. They can sequence different tools during one task, and the set of required permissions may change as the task evolves. If teams try to pre-declare scopes broad enough to cover every action, they end up with blanket privilege. If they make scopes too narrow, the agent cannot complete the work. The problem is not OAuth syntax. It is the mismatch between static permissioning and runtime task variability.

Practical implication: Treat OAuth as a transport token, not the authorization decision itself.

Runtime authorization for non-API resources

MCP is not limited to APIs, and that is where OAuth becomes especially incomplete. Agents may need to access file systems, databases, data warehouses, or object stores, each of which may not map cleanly to OAuth-style scopes. Runtime authorization evaluates each request against identity, action, resource, time, and risk signals before granting the smallest usable permission. That is a different control pattern from pre-issued token scopes because the decision happens at the moment of use, not at session start.

Practical implication: Extend authorization logic beyond APIs so non-API resources are governed with the same policy engine.

What ZSP and JIT mean in agent workflows

Just-in-time authorization and zero standing privilege are especially relevant when an agent operates across multiple tools. The article’s model creates a short-lived permission for one resource and one action, then revokes it automatically. That reduces the chance that an agent keeps durable access after the immediate task is complete. In identity terms, this aligns with the idea that permissions should exist only for the duration of the action that requires them. For MCP, the guardrail is not merely least privilege at provisioning time. It is least privilege at execution time.

Practical implication: Use short TTLs and immediate revocation so agent permissions do not persist beyond the task.

Threat narrative

Attacker objective: The objective is to turn delegated access into durable cross-system reach that outlives the original user intent.

1. Entry occurs when an MCP agent receives delegated access through OAuth tokens or other pre-issued credentials that were created for a broader session than the immediate action.
2. Escalation happens when the agent can combine several tools under broad scopes, turning one consent grant into effective access across systems the user did not explicitly intend for that action.
3. Impact follows when long-lived tokens or blanket permissions let the agent act outside the narrow task boundary, expanding blast radius and weakening revocation control.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Runtime authorization is the correct control plane for MCP agents, not OAuth alone. OAuth answers whether a client may use an API on behalf of a user. It does not answer whether an agent should be allowed to take the next action, on the next tool, against the next resource, under the current task context. That gap becomes visible as soon as the actor can chain decisions across multiple systems. Practitioners should stop treating token issuance as the final authorization event.

Static scopes create privilege that is either too broad or too brittle for agentic work. An MCP agent can need one permission to read a case, another to write a ticket, and a third to retrieve a file, all in one workflow. Pre-declaring all of that in OAuth scope form either produces blanket access or operational failure. Runtime task entropy: the permission set needed for the task is not knowable in full at provisioning time. IAM teams should recognise this as a structural mismatch, not a tuning problem.

OAuth was designed for delegated sessions, not self-directed tool selection. That assumption fails when an AI agent independently chooses which tool to invoke next and when to invoke it. The implication is not simply that authorization must become more granular. It is that the governance model must move from session-based consent to action-based control.

Identity and access governance must extend across humans, NHIs, and agents as one policy domain. The article is right to frame humans, NHIs, and agentic AI under consistent guardrails, because the blast radius problem is the same even when the actor type changes. The practitioner mistake is to separate AI agent governance from the rest of identity. Security teams should use one access governance model and vary the execution controls by actor behaviour.

Action-level evidence is now a governance requirement. If the audit record only shows that a token was issued, teams cannot prove what the agent actually did at the moment of decision. MCP environments need action context, resource context, and revocation evidence together. That is the line between delegated access and governed access, and practitioners should design for provable action history, not just token logs.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs.
• Runtime authorization for MCP agents is the practical extension of Top 10 NHI Issues into action-level control, because static scopes do not match non-human behaviour.

What this signals

Runtime authorization: the category is moving away from token-centric thinking toward action-centric governance, and that shift will affect every IAM programme that touches agents, bots, or service identities. Teams that already manage non-human identity inventory, ownership, and revocation will adapt faster because the policy question is familiar even if the actor is not. The next control gap is not whether access exists, but whether each action can be approved, bounded, and revoked in the same decision cycle.

MCP-style agent workflows will pressure identity teams to unify policy across cloud, SaaS, and on-prem resources instead of leaving API, database, and file access in separate governance lanes. That is where a named gap emerges: permission drift at runtime, the condition where access remains valid after the task context has changed. Practitioners should expect more demand for action logging, short TTL enforcement, and real-time revocation evidence.

For teams building identity architecture, the important signal is that agent control is becoming a lifecycle problem as much as an authorization problem. The same ownership discipline used for service accounts should apply to MCP integrations and AI agents, with explicit purpose, bounded lifetime, and offboarding triggers. That is how runtime authorization becomes operational rather than theoretical.

For practitioners

• Separate transport from authorization Keep OAuth as the delegated transport mechanism, but place a runtime policy layer in front of every tool and resource decision. That layer should evaluate identity, task context, sensitivity, and time before allowing the next action.
• Scope permissions to the action, not the session Grant the smallest usable permission for a specific resource and revoke it automatically after completion. Use short TTLs so the agent cannot carry unused access into the next step of the workflow.
• Map non-API resources into the same governance model Extend policy coverage to databases, file systems, data warehouses, and object storage so MCP does not become a side channel around your API controls.
• Require identity-level audit evidence Log who requested the action, which agent executed it, what resource changed, and when revocation occurred. Token logs alone are not enough to prove bounded access.
• Define owner, purpose, and lifetime for every agent integration Register each agent and integration in an identity inventory, assign business ownership, and enforce an explicit lifetime so dormant MCP access can be retired on schedule.

Key takeaways

• MCP agents expose the limit of static OAuth scopes because action intent changes at runtime, not at provisioning time.
• The relevant control is runtime authorization with short-lived permissions, action-level logging, and immediate revocation.
• Identity teams should govern agents as non-human identities with lifecycle ownership, not as ordinary API clients.

Key terms

• 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.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• On-Behalf-Of Boundary: An on-behalf-of boundary limits an agent to the privileges of the human or service identity it is acting for. It prevents free-floating privilege growth by ensuring the agent cannot exceed the authority of the principal whose intent initiated the task.
• 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.

What's in the full article

Britive's full analysis covers the operational detail this post intentionally leaves for the source:

• A concrete runtime authorization pattern for MCP workflows that spans agent decisions, tool access, and revocation timing.
• Examples of how to layer policy across APIs, databases, and file systems without relying on static OAuth scope design.
• The practical distinction between delegated transport tokens and the real authorization decision for agent actions.
• Guidance on combining on-behalf-of boundaries with human approval for higher-risk access requests.

👉 Britive's full post covers the runtime policy model, action scoping, and revocation approach in more implementation detail.

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 identity programme, it is worth exploring.