Topic starter
14/08/2026 6:34 pm
TL;DR: Opal Security says its MCP servers now use OAuth 2.1 with PKCE so each person signs in through a browser, receives a short-lived scoped token, and avoids long-lived bearer secrets in configs. That moves MCP access from static credentials to governed grants, which is the correct identity model for agents.
Editorial analysis by NHI Mgmt Group, based on content published by Opal Security: “OAuth for Opal MCP: give agents access, not a standing key”.
Key questions
Q: How should security teams govern MCP OAuth flows in enterprise environments?
A: Treat MCP OAuth as an identity control plane, not a convenience layer.
Q: Why are long-lived tokens a governance problem for MCP clients?
A: Long-lived tokens create secret persistence outside normal identity controls.
Q: What signs show that MCP access is still being handled like a secret instead of a grant?
A: Look for Authorization headers in configs, manually pasted tokens, shared onboarding snippets, and any client that cannot refresh access without human handling.
Practitioner guidance
- Replace pasted MCP tokens with OAuth grants Move human-operated MCP clients to browser sign-in with short-lived scoped tokens and remove shared bearer secrets from configuration files.
- Separate interactive and script-based MCP access Use OAuth for users and reserve API tokens only for non-interactive clients where federation is not practical, so the access model matches the actor type.
- Review MCP grants as access decisions Track who approved each grant, what server it applies to, and how it is revoked so the connection is governed like any other identity event.
Bottom line: MCP access should be governed as a scoped authorization grant, not as a static secret embedded in client configuration.
What's in the full announcement
Opal Security's full post covers the operational detail this post intentionally leaves for the source:
- Browser sign-in flow specifics for MCP clients using OAuth 2.1 with PKCE
- Per-server support details for End User, Admin Provisioning, and Admin Audit connections
- Manual setup steps for clients that still need API tokens for non-interactive use
- How users review and revoke their own OAuth grants inside the product
👉 Read Opal Security's OAuth for MCP analysis on governed agent access →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:41 pm
OAuth for MCP is a grant-governance problem, not just an authentication upgrade. The important change is that access is now issued through a browser-mediated grant with a clear owner, scope, and revocation path. That aligns MCP with lifecycle governance instead of treating it like a static integration secret. For practitioners, the implication is that MCP access should be reviewed as an authorization event, not a configuration artifact.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should teams keep using API tokens for MCP clients?
A: Use API tokens only when the client is non-interactive and cannot complete a browser-based sign-in flow. For people-driven MCP access, OAuth is the better control because it preserves user attribution, scoped authorization, and revocation. The decision point is actor type, not convenience or implementation familiarity.
👉 Read our full editorial: OAuth for MCP shifts agent access from static keys to grants