A delegated identity created when an AI-enabled client obtains access to external services through MCP and OAuth. It behaves like a non-human identity because the credential can persist, refresh and operate outside normal human session controls, even when it originated from a developer action.
Expanded Definition
MCP delegated identity is the credentialed service identity that emerges when an AI-enabled client uses Model Context Protocol and OAuth to reach external tools or APIs. It is not a human session token in disguise; it is a machine-operable identity with its own lifecycle, refresh behavior, scope, and revocation needs. In practice, it sits at the intersection of delegated authorization and non-human identity governance, which is why NHI Management Group treats it as an NHI control problem rather than a purely application-layer convenience.
Definitions vary across vendors because some teams describe the same pattern as an OAuth grant, while others call it a brokered service account or agent token exchange. The important distinction is operational: the identity may persist after the initiating developer is gone, and it can continue acting without normal human session boundaries. That is why MCP delegated identity should be reviewed alongside OWASP Agentic AI Top 10 guidance and NHI lifecycle controls from Ultimate Guide to NHIs. The most common misapplication is treating the delegated credential as a temporary user session, which occurs when teams ignore refresh tokens, tool scope, and offboarding responsibilities.
Examples and Use Cases
Implementing MCP delegated identity rigorously often introduces governance overhead, requiring organisations to weigh agent autonomy against tighter scope control, logging, and revocation discipline.
- An internal coding agent connects to a ticketing system through MCP and receives a long-lived OAuth grant that must be inventoried as an NHI.
- A support assistant uses delegated access to read incident records, but only within a narrow project scope aligned to an external policy control.
- A data agent calls a SaaS reporting API through MCP, then refreshes its token automatically after the original developer setup is complete.
- A platform team rotates the delegated credential independently of the developer account because the operational identity now outlives the human session.
- A security team reviews MCP tool permissions against the State of MCP Server Security 2025 and the OWASP Top 10 for Agentic Applications 2026 to reduce overbroad tool access.
These patterns are most useful when an agent needs persistent, auditable access to a tool chain without borrowing a human login. They are also where mis-scoped secrets or hard-coded credentials become especially dangerous, as highlighted in The State of MCP Server Security 2025 and the broader NHI lifecycle guidance in Ultimate Guide to NHIs.
Why It Matters in NHI Security
MCP delegated identity matters because it can quietly become a standing machine identity with real privileges, even when teams assume they have only enabled a temporary integration. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That risk profile applies directly when an MCP grant is created without clear ownership, expiry, rotation, or tool scoping.
When delegated identity is unmanaged, the blast radius extends beyond one agent. A compromised refresh token can continue operating, a forgotten grant can outlive the project that created it, and a missing offboarding process can leave external access active long after the developer has moved on. This is why the issue belongs in identity governance, not just application engineering, and why Top 10 NHI Issues remains relevant to MCP deployments. Organisations typically encounter the consequence only after a token leak, overbroad tool call, or unexplained API activity, at which point MCP delegated identity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic apps must constrain tool and token use to prevent overbroad delegated access. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and token handling risks that apply to delegated MCP identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control directly applies to MCP delegated identities. |
| NIST Zero Trust (SP 800-207) | 5.3 | Zero Trust requires continuous verification for non-human access paths. |
| NIST SP 800-63 | CSP | OAuth-based delegation depends on strong credential issuance and lifecycle management. |
Bind delegated credentials to clear issuance, renewal, and revocation processes with auditable ownership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
