IAM teams should govern OAuth for MCP as a delegated machine access path, not as a routine web login. That means separating client onboarding, token validation, and connection authority into distinct review points. If those controls are merged, the organisation may approve a working login flow without understanding the access model it creates.
Why MCP OAuth needs delegated access governance, not web-login governance
MCP changes the control question. The important issue is not whether a user can sign in, but whether an MCP client is allowed to obtain and use delegated access on behalf of a principal. That makes OAuth a machine access and authorization design problem, with separate decisions for client trust, token scope, and server-side authority.
Teams should treat the MCP client as an integration that can request and exercise access, not as a browser session. That means reviewing which client is registered, which grant path it uses, and what resource authority the server accepts, because those are the points where delegated access becomes real.
For the protocol mechanics, the MCP authorization specification is useful because it defines MCP servers as OAuth 2.1 resource servers, with audience-bound tokens and no token passthrough. That framing is very different from a normal web app login flow.
Which control points should IAM own separately?
IAM governance works better when the review points are split. Client onboarding answers who may integrate, token validation answers whether the token is valid for this server and this audience, and connection authority answers what the MCP server is allowed to do with that delegated access. If one review collapses all three, the organisation can approve a technically working flow without understanding the real access boundary.
This is also where delegated machine access should be distinguished from end-user authentication. A routine login review often focuses on user identity, session behaviour, and interactive access. MCP governance should instead ask whether the client, the token, and the target service are aligned to the intended delegated purpose.
The cleanest external anchor for that model is RFC 6749: The OAuth 2.0 Authorization Framework, because it defines OAuth around delegation and client grants, including machine-to-machine use cases. Teams should map their approval workflow to the delegated grant model, not to a human login pattern.
What usually goes wrong when MCP OAuth is treated like ordinary app login?
The most common failure is over-trusting the client boundary. If the client is assumed to be “just another app,” teams may under-review scope, reuse broad consent patterns, or accept tokens that are valid in general but not appropriate for a specific MCP server. That creates a confused-deputy risk, where the server performs actions that were never meant for that integration.
A second failure is weak token-boundary thinking. If the access token is accepted without checking audience, token type, or sender constraints, a valid token can become a reusable capability rather than a tightly bound delegated grant. In practice, that expands the blast radius of a stolen or misissued token.
For a broader control model, the RFC 9700 OAuth 2.0 security BCP matters because it pushes teams toward modern protections such as sender-constrained tokens and stronger handling of token theft risk. That is the right mindset for MCP, where access is often service-to-service and operationally sensitive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP clients and servers rely on machine-to-machine authentication and delegated access. |
| AC-6 — Least Privilege | MCP scopes and delegated authority should be limited to the minimum needed by each integration. | |
| IA-5 — Authenticator Management | OAuth secrets, assertions, and token handling for MCP depend on strong credential lifecycle management. | |
| Recommendation — Apply IA-9 to authenticate MCP service clients and validate delegated access before action. Constrain MCP tokens and server actions to least privilege for each client and resource. Manage MCP client credentials and tokens with rotation, protection, and revocation controls. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP authorization depends on correct OAuth token validation and client authentication. |
| API5 — Broken Function Level Authorization | MCP servers must enforce which delegated actions each client may perform. | |
| API10 — Unsafe Consumption of APIs | MCP is a protocol consumption path where unsafe trust in upstream grants can expose downstream systems. | |
| Recommendation — Validate OAuth authentication flows and reject tokens that are invalid, misbound, or reused. Enforce function-level authorization for every MCP tool and delegated action. Treat MCP integrations as constrained API consumers and validate every upstream trust assumption. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP OAuth is a non-human delegated access path that can fail through weak authentication design. |
| NHI-05 — Overprivileged NHI | MCP clients can become overprivileged if scopes and server authority are not separated. | |
| NHI-07 — Long-Lived Secrets | MCP OAuth deployments often depend on tokens or client secrets that should not persist indefinitely. | |
| Recommendation — Harden non-human OAuth authentication for MCP clients and reject weak grant handling. Limit MCP client privilege to the minimum scopes and actions required. Prefer short-lived MCP credentials and revoke long-lived secrets promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | MCP governance depends on separating identity proof, access decisions, and authorization enforcement. |
| Recommendation — Separate MCP client identity, token validation, and authorization decisions in policy and review. | ||
Practitioner Guidance
What to prioritise: Build a registration and approval path for MCP clients that is separate from your ordinary web SSO process. The question is not “can the user sign in?” but “what delegated authority does this client receive, and for which server and audience?”
What to verify: Confirm that token validation checks audience, issuer, expiry, and the intended MCP resource boundary before any downstream action is authorised. If the server cannot prove that the token was minted for this connection, treat the integration as under-controlled.
What good looks like: Client identity, token acceptance, and server authority are reviewed independently, with scoped consent and short-lived delegated access. The resulting control model should be understandable to IAM, application owners, and platform owners without relying on browser-login assumptions.
Practitioner takeaway: MCP OAuth should be governed as delegated machine access with explicit resource boundaries, not as a generic sign-in experience, because the real risk is authorising the wrong action model while thinking you only approved authentication.
Related resources from NHI Mgmt Group
- How should security teams govern experimental MCP services without treating them like production integrations?
- How should IAM teams govern branded login experiences without creating policy drift?
- How should security teams govern interactive MCP apps without treating them as a new trust boundary?
- How should security teams govern enterprise AI agent access to MCP servers without creating per-app consent fatigue?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org