When Agents Act, OAuth Isn’t Enough: Securing MCP With Runtime Authorization 

OAuth works well for what it was designed to do: let an application or service access user data from another service on the user’s behalf. You give consent once by sharing a token to the application that proves their identity and allows for the application to interact with the other service. 

But when you move to Model Context Protocol (MCP) to manage tool access for AI agents that plan, decide, and take actions across many tools, often without a human in the loop, OAuth’s model starts to break down. 

What OAuth Is and Isn't 

There’s a lot of confusion around OAuth, SAML, and OpenID Connect (OIDC). 

• SAML is for authentication (proving who you are) — commonly used for SSO. 
• OAuth is for authorization (what a client is allowed to do) — using scopes you consent to. 
• OIDC adds the authentication layer back on top of OAuth. 

Even with OAuth’s client credentials flow (the “machine-to-machine” variant), the design assumes relatively stable scopes granted ahead of time. This isn't how MCP-driven agent systems behave. 

Why OAuth Alone Doesn’t Fit AI Use Cases 

1) One Agent, Many Tools, Dynamic Actions 

An agent can interact with a dozen MCPs in a single task. Pre-declaring OAuth scopes that cover every possible MCP server’s tools/actions is either too coarse (with broad, blanket permissions) or too granular (impossible to enumerate with all of the potential permissions an agent could need). Agents are meant to decide and act — not just read — so “read-only” scopes don’t solve the problem. 

2) Balancing OAuth Consent and Agent Intent 

OAuth permission scopes reflect a user’s one-time consent for access. Agents make context-dependent decisions at runtime. The “who/what/why/for how long” changes per action, and static scopes can’t express that intent. 

3) OAuth Only Works for APIs 

OAuth authorizes APIs. But what happens when agents also need controlled access to databases, data warehouses, data lakes, file systems, and other non-API surfaces? This leaves gaps in access management where OAuth simply doesn’t apply. 

4) Establishing Granular Guardrails 

MCP doesn’t enforce security checks; it only passes data back and forth. Without another layer that makes authorization decisions per action, OAuth access tokens become long-lived hall passes. 

Imagine this scenario: support agent needs to read a CRM case, write to a ticketing system, and attach a log from object storage. 

OAuth scopes that cover “CRM + Tickets + Storage” becomes blanket access. What you really want is the ability to provision something more specific: “grant read-case for 5 minutes, then grant write-ticket for this record only, then permit a single signed object download, then revoke everything.” 

The Perimeter Has Shifted: Identity + Permissions 

If agents and automations are the workforce, then identity + its permissions are the perimeter. The control that actually reduces risk is runtime authorization: 

• Just-in-time Authorization at Runtime — create the permission at request time, scope it to the exact resource/action, and auto-revoke on a short TTL (ZSP by default). 
• Unified policy engine — evaluate each request using identity, task, data sensitivity, environment, time, and risk signals. Extend this for every identity across cloud, SaaS, hybrid, and on-prem. 
• On-behalf-of boundaries — agents operate only within a human owner's privilege perimeter, preventing free-floating super-agents. Human in the loop approvals when an agent is accessing sensitive data on behalf of the user.  
• Tool allowlists/approvals — define which tools/APIs an agent may call, under what conditions, and for how long. 
• Identity registry & lifecycle (agents/apps) — register every integration and agent, assign ownership, define purpose and lifetime to maintain comprehensive visibility. 
• Unified visibility + rapid revocation — log who/what/when/why/how long and connect detections to immediate privilege tear-down. If behavior drifts, revoke first, then investigate. 

Bringing OAuth and Runtime Authorization Together

• OAuth: “You can use these APIs for this account, until your token or refresh expires.” 
• Runtime authorization: “For this specific action, right now, here’s the smallest permission you need — and it will expire automatically.” 

OAuth is still useful for delegated API calls and user-consented access. It should be used as a transport token behind a runtime layer that decides, for this action, what the agent may do next, and for how long. Think “OAuth + runtime authorization,” not OAuth alone. 

The results? 

• A smaller blast radius — no always-on agent privilege. 
• Cleaner audits — identity-level evidence is available by action, not just token logs. 
• Fewer surprises — agents can’t “upgrade themselves” at runtime and tool calls remain gated according to security policy. 
• Consistent controls — humans, NHIs, and agentic AI follow the same guardrails for consistent policy enforcement. 

Ready to See AI Identity Security in Action?  

Schedule time with a member of our team to talk about mapping runtime authorization and safer agent patterns to your top MCP workflows. Or learn more and explore additional resources about agentic AI identity security.