Notifications
Clear all
Topic starter
11/08/2026 3:11 pm
TL;DR: MCP authorization uses OAuth 2.1 to let AI agents discover, request, and reuse access tokens for tools and data through the Model Context Protocol, but it only validates tokens and does not decide tool choice, approval, or ongoing appropriateness, according to C1.ai. That leaves governance to handle ownership, least privilege, revocation, and review before shadow servers and stale grants take hold.
NHIMG editorial — based on content published by C1.ai: MCP Authorization: Controlling What AI Agents Can Access
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do OAuth misconfigurations create NHI governance risk?
A: OAuth misconfigurations create NHI governance risk because tokens, proxies, and linked accounts act like non-human identities with delegated access.
Q: What breaks when teams rely on MCP authorization instead of identity governance?
A: Approval, ownership, and recertification break first.
Practitioner guidance
- Define ownership for every MCP-connected agent Assign a named human owner and an accountable business purpose to each agent, then require that ownership to exist before any token or registration is approved.
- Separate token validity from access approval Use OAuth 2.1 for authentication and token validation, but keep tool approval, least privilege, and recertification in your identity governance process.
- Inventory remote and local MCP servers Track both internet-facing and STDIO-based servers, because local deployments can bypass the OAuth flow and still consume environment credentials.
What's in the full article
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP discovery, registration, and token exchange flow for remote servers
- The role of WWW-Authenticate headers, PKCE, refresh tokens, and audience validation in the protocol
- Practical examples of how the spec differs for HTTP transport versus local STDIO servers
- C1.ai's framing of agent ownership, just-in-time approval, and speed of access decisions
👉 Read C1.ai's blog on MCP authorization and AI agent access control →
MCP authorization and AI agent access: what does governance still need to decide?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:25 pm
OAuth validation is a transport control, not an identity governance decision. The MCP authorization layer proves that a token is valid for a server, but it does not decide whether the agent should still have access or whether the access was ever properly owned. That distinction matters because many programmes conflate protocol security with lifecycle governance. Practitioners should treat MCP as the pipe and governance as the policy layer that decides who may use it.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do organisations reduce shadow MCP server risk?
A: By inventorying every MCP server, including local and developer-run instances, and tying each one to a known owner and approved identity source. If a server can be created outside central governance, it should be treated as an unmanaged NHI path until proven otherwise.
👉 Read our full editorial: MCP authorization defines what AI agents can reach through OAuth 2.1
