OAuth for MCP shifts agent access from static keys to grants

At a glance

What this is: Opal Security’s update replaces static bearer tokens for MCP clients with OAuth 2.1, short-lived scoped tokens, and per-person grants for agent access.

Why it matters: That matters because identity teams need MCP access to inherit the same approval, revocation, and audit expectations as other access paths instead of creating a new secret sprawl problem.

👉 Read Opal Security's post on OAuth for MCP access and scoped grants

Context

OAuth for MCP is an identity design choice, not just a transport detail. When an agent or client connects through a long-lived token, the security model silently shifts from governed access to durable secret possession, which is harder to review, revoke, and scope cleanly across users and workflows.

The vendor’s approach changes that starting point by making access flow through browser sign-in, short-lived tokens, and account-scoped grants. For IAM, NHI governance, and access review teams, the important question is no longer whether the client works, but whether the connection itself now behaves like any other governed identity grant.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why are long-lived tokens a governance problem for MCP clients?

A: Long-lived tokens create secret persistence outside normal identity controls. They are easy to copy, hard to attribute cleanly, and often survive role changes or project handoffs. That turns a personal connection into durable access that outlives the original approval, which is why lifecycle handling matters as much as the initial grant.

Q: What breaks when MCP access is built on shared API tokens?

A: Shared API tokens break accountability first. Once one token is reused across people or scripts, the action trail no longer maps cleanly to a single identity, and revocation becomes blunt rather than targeted. The result is access that may still work after the original user’s intent has changed.

Q: Who should own revocation and review of MCP OAuth grants?

A: The identity or access governance team should own the review model, while application owners define the scopes required for each server. That split keeps the grant in the standard entitlement process instead of leaving it as a developer-owned integration detail. In practice, revocation should follow the user lifecycle, not the client installation date.

How it works in practice

OAuth 2.1 with PKCE for MCP clients

OAuth 2.1 with PKCE is designed for interactive authorization where the client proves continuity during sign-in without embedding reusable secrets. In this model, the client obtains a short-lived token after user consent, and the token can be refreshed without exposing a long-lived bearer credential in configuration. For MCP, that matters because the server connection becomes an access grant with defined scope and revocation, not a static secret that can quietly spread through scripts, shared configs, or copied environments.

Practical implication: treat MCP onboarding as an access governance flow and require sign-in based grants instead of pasted tokens wherever interactivity exists.

Scoped agent action through the signing user

The vendor states that every agent action runs as the person who signed in, which means the agent inherits the signer’s permissions and audit trail rather than acting under a shared service credential. That is a conventional delegated authorization pattern, but it still changes operational risk because the identity behind the action is now a human principal with bounded entitlements. The critical control question is whether approvals, logging, and revocation follow the user grant in a way that preserves accountability across access requests, admin actions, and evidence retrieval.

Practical implication: align MCP server permissions to the user’s existing role and review whether delegated actions inherit the same approval and logging standards as direct human requests.

Short-lived tokens reduce secret persistence, not governance duty

Replacing a pasted API token with OAuth reduces the persistence of secrets in configs, but it does not eliminate identity governance. You still need to decide who can authorize the connection, how grant revocation works, which scopes each server can receive, and how to detect overbroad or stale access. In practice, this is a shift from secret-handling risk to grant-management risk, which is usually easier to govern but still requires lifecycle discipline across onboarding, change, and offboarding.

Practical implication: add MCP grants to access review, offboarding, and revocation workflows so short-lived credentials do not become long-lived entitlements.

NHI Mgmt Group analysis

OAuth for MCP is really a shift from secret possession to governed entitlement. The important change is not that the client becomes more convenient, but that the access path now behaves like an authorization grant with revocation and audit hooks. That matters because identity teams can only govern what they can see, scope, and retire. The practitioner conclusion is simple: stop treating MCP onboarding as a configuration task and treat it as a control point in the identity lifecycle.

Long-lived bearer tokens are a secret sprawl problem disguised as integration convenience. A pasted token is durable, portable, and easy to copy into places the original approver never intended. Once that happens, the token is no longer personal in any meaningful governance sense, even if the label says otherwise. The practitioner conclusion is to assume that any bearer secret used for MCP will eventually need lifecycle controls equal to other privileged credentials.

Per-user OAuth grants give identity teams a cleaner audit story than shared tokens do. If every action can be tied back to the signing user, then review, approval, and revocation can follow existing IAM and IGA patterns instead of inventing a separate exception path for agents. That does not make the model safe by default, but it does make it governable in a way static secrets rarely are. The practitioner conclusion is to insist on user-bound grants wherever the workflow is interactive.

Named concept: connection-as-grant governance. This article points to a useful concept for MCP and similar agent access patterns: the connection itself should be treated as a governed grant, not a technical convenience layer. That framing forces teams to ask who approved it, what scope it carries, when it expires, and how it is revoked. The practitioner conclusion is that access governance must extend to the first handshake, not begin after the token already exists.

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.
• A separate finding from the same research shows only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why OAuth-connected access needs tighter governance.
• For a broader control model, see the Ultimate Guide to NHIs , 2025 Outlook and Predictions for lifecycle and governance context.

What this signals

Connection-as-grant governance: MCP access should be managed as an entitlement lifecycle, not as a client setup detail. That means sign-in, scope assignment, revocation, and review belong in the same operational chain that governs other privileged access. The policy signal is clear: if your identity programme cannot explain who approved a connection, it is not governing the connection.

The security programme should also assume that OAuth reduces one class of exposure while exposing another. Short-lived tokens are better than pasted bearer secrets, but they still require scope discipline, offboarding, and visibility across connected clients. That is especially true for access workflows, where one overly broad grant can influence approvals, evidence, and administrative change paths at the same time.

For practitioners

• Replace pasted MCP tokens with user-bound OAuth grants Use browser-based sign-in and short-lived tokens for interactive MCP clients so access is tied to the signing identity rather than a copied bearer secret.
• Add MCP grants to access review and offboarding Track each OAuth grant as an entitlement that must be reviewed, revoked, or re-approved when the user changes role or leaves the organisation.
• Limit server scopes to the minimum workflow boundary Separate end-user, admin provisioning, and admin audit permissions so a single MCP connection cannot silently expand across unrelated identity tasks.
• Reserve API tokens for non-interactive scripts only Keep static tokens out of interactive clients and restrict them to automation paths that cannot complete browser sign-in, then apply tighter rotation and storage controls.

Key takeaways

• MCP access becomes governable when it is treated as an identity grant rather than a pasted secret.
• Short-lived OAuth tokens reduce secret persistence, but they do not remove the need for access review, revocation, and scope control.
• Interactive MCP clients should use user-bound sign-in flows, while static tokens should remain limited to non-interactive automation.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• OAuth Token Persistence: OAuth token persistence is the tendency for delegated access to remain usable after the original user action is over. In practice, refresh tokens and long-lived access tokens can keep an application connected until someone revokes them, which makes lifecycle control central to security.
• Scoped Delegation: Scoped delegation is the practice of giving an agent time-bound authority limited to a specific task, resource, or condition. It prevents inherited access from becoming permanent and preserves accountability by recording who granted authority, what was granted, and when it expires.

What's in the full announcement

Opal Security's full product post covers the operational detail this post intentionally leaves for the source:

• Client configuration examples for adding MCP servers without an Authorization header
• Per-server sign-in steps for End User, Admin Provisioning, and Admin Audit flows
• Manual and documentation-specific commands for interactive and non-interactive clients
• Grant review and revocation details shown in the product interface

👉 Opal Security's full post covers the MCP sign-in flow, grant handling, and client configuration details

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