A delegated application identity is an access path that lets an app act on behalf of a user, tenant, or business process. It is common in OAuth-based ecosystems and becomes risky when nobody owns the permissions, reviews the scope, or can revoke it quickly.
Expanded Definition
A delegated application identity is the authority an application uses when it performs actions for a user, tenant, or business process rather than for itself alone. In OAuth-based ecosystems, that delegation is typically expressed through scopes, consent, tokens, and policy decisions. The exact boundary varies across vendors, and usage in the industry is still evolving, especially where AI Agents and MCP integrations can chain multiple delegated actions across services.
What distinguishes this concept from a normal service account is the inherited trust relationship. A delegated app identity may have broad reach into mailboxes, files, tickets, or cloud resources even though the application never logs in as a person. That makes governance harder because ownership is often split between application teams, identity teams, and business process owners. For a broader NHI frame, see the Ultimate Guide to NHIs and the deeper primer on Ultimate Guide to NHIs — What are Non-Human Identities. The NIST Cybersecurity Framework 2.0 is useful here because delegated access still needs clear identity governance, access control, and continuous review.
The most common misapplication is treating delegated application identity as a one-time consent event, which occurs when long-lived scopes remain active after the business need has changed.
Examples and Use Cases
Implementing delegated application identity rigorously often introduces consent friction and review overhead, requiring organisations to weigh user convenience against tighter scope control and revocation speed.
- A productivity app reads a user’s calendar and email to schedule meetings, but the delegated scope also permits broader mailbox access than the feature actually requires.
- An enterprise HR workflow submits approvals on behalf of managers, but no single owner can quickly revoke the app when the process changes or the vendor relationship ends.
- An AI Agent connected through MCP requests files, tickets, and chat context to complete a task, creating a chain of delegated permissions that must be reviewed as one trust path, not as isolated tokens.
- A partner integration uses OAuth consent to call APIs across multiple tenants, and the risk grows when the consent survives staff turnover or a change in contractual scope.
- A security team investigates an incident and finds that the app’s delegated token was over-scoped, similar to patterns discussed in the JetBrains GitHub plugin token exposure and the Cisco DevHub NHI breach.
For implementation guardrails, the OAuth model should be assessed alongside NIST guidance and identity federation practices, not assumed safe because a user clicked approve. The broader NHI breach landscape in the 52 NHI Breaches Analysis shows how delegated trust becomes dangerous when scope, lifespan, and revocation are not operationalized.
Why It Matters in NHI Security
Delegated application identity matters because it can turn a legitimate business workflow into a high-value attack path. When scopes are excessive, revocation is slow, or ownership is unclear, an attacker who steals a token can inherit the same privileges the application was granted on behalf of the user or process. In NHI security terms, that is not just an authentication problem; it is a lifecycle and governance failure. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a strong warning sign for delegated identities too, because hidden or weakly owned access paths are hard to review and even harder to revoke. This is why the topic maps closely to NIST Cybersecurity Framework 2.0 and to the operational lessons captured in the Top 10 NHI Issues.
Practitioners should treat delegated identity as a controlled entitlement, not as a convenience feature, and should pair it with least privilege, time-bound scopes, and rapid offboarding. Organisations typically encounter the consequence only after a token leak, tenant compromise, or unexpected data access alert, at which point delegated application 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers excessive scopes and weak lifecycle control for non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege governance for delegated identities. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust requires each delegated request to be explicitly evaluated and constrained. |
Treat each delegated action as a separately authorized request and enforce continuous validation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
