Notifications
Clear all
Topic starter
14/08/2026 6:34 pm
TL;DR: MCP servers now use OAuth 2.1 with PKCE so agents authenticate through browser sign-in, receive short-lived scoped tokens, and avoid long-lived bearer secrets in configs, according to Opal Security. That shifts MCP access from shared static credentials to governed grants, which is the right direction for identity control.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
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.
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 breaks when MCP access is built on shared API tokens?
A: Shared API tokens break accountability first.
Practitioner guidance
- 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.
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
👉 Read Opal Security's post on OAuth for MCP access and scoped grants →
OAuth for MCP access: are static tokens still acceptable?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/08/2026 6:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth for MCP shifts agent access from static keys to grants
