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.
Why This Matters for Security Teams
MCP OAuth grants are not just integration plumbing. They define which tools, data sources, and downstream actions a server can reach, so ownership determines whether the grant is governed as a normal entitlement or allowed to drift into shadow access. When revocation sits with developers alone, stale grants persist after role changes, project closures, or vendor offboarding, which is exactly how over-privilege turns into exposure.
This is a NHI governance problem as much as an application problem. The grant lifecycle should be managed through identity and access review, because OAuth consent, token scope, and revocation are part of access governance. NHI Management Group’s research on The State of Non-Human Identity Security shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means the review process is often blind at the exact point where risk accumulates. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls still maps well here: access governance needs ownership, evidence, and repeatable review. In practice, many security teams discover stale MCP grants only after a service account has already been reused or a vendor connection has already outlived the original business need.
How It Works in Practice
The clean operating model is split ownership. The identity or access governance team owns the review workflow, approval evidence, and revocation decisions. Application owners define the minimum scopes each MCP server needs, but they should not be the long-term custodians of grant hygiene. That keeps the grant in the entitlement process rather than buried inside a code repository or a one-off admin console.
Practically, this means treating MCP OAuth grants like privileged non-human access. The governance team should maintain a register of grants, map each one to a business owner, and attach review dates to the lifecycle of the user, service, or vendor relationship. Where the platform supports it, use short-lived authorization and automatic renewal checks, not indefinite tokens. For the technical baseline, align the control model with OWASP Agentic AI Top 10 because tool-connected workloads create similar risks around excessive authority and unreviewed escalation paths.
For incident response, revocation should be available to both access governance and the service owner, but with different purposes: governance revokes for lifecycle, policy, or risk reasons; the app owner revokes when a scope no longer supports the use case. The operational evidence should include what was granted, why it was granted, who approved it, and when it was last validated. The NHIMG analysis of the Salesloft OAuth token breach is a reminder that token-based access can persist far beyond the moment the original workflow changes. These controls tend to break down when grants are embedded in SaaS app onboarding flows and no central team has a complete inventory of connected OAuth apps.
Common Variations and Edge Cases
Tighter revocation controls often increase operational overhead, so organisations need to balance speed of integration against the risk of orphaned grants. That tradeoff becomes most visible in fast-moving product teams, partner integrations, and AI-assisted workflows where owners change frequently and access review cadence lags behind deployment speed.
There is no universal standard for every MCP deployment yet, but current guidance suggests the same rule should apply across environments: one team owns the policy, another owns the business justification. In small teams, the same person may temporarily fill both roles, but the separation should still exist logically so reviews are not self-approved by default. In regulated environments, evidence retention matters as much as revocation itself.
Edge cases usually involve shared integrations, external vendors, or reused OAuth clients across multiple servers. In those situations, a single grant can support several business functions, which makes revocation riskier if scope boundaries are not documented. The safest pattern is to break shared access into discrete grants where possible, then review each grant against the active user lifecycle. The Klue OAuth Supply Chain Breach and Vercel Context.ai OAuth Supply Chain Breach both underscore why hidden third-party paths are difficult to govern after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | OAuth grant review depends on timely credential and entitlement rotation. |
| OWASP Agentic AI Top 10 | A2 | Tool-connected agents can overreach when scopes are not reviewed centrally. |
| CSA MAESTRO | GOV-02 | MAESTRO emphasizes governance ownership for autonomous and tool-using workloads. |
| NIST AI RMF | AI RMF governance requires accountable ownership for high-impact access decisions. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review is directly relevant to OAuth grant ownership. |
Assign governance teams to own review and revocation, with app owners defining least privilege.
