Standing delegation is persistent authority that remains available after initial approval or setup. In MCP and NHI governance, it becomes risky when a token or account can keep acting across workflows without fresh contextual checks, because the authority outlives the immediate need.
What Standing Delegation Means in Practice
Standing delegation is not just a one-time permission grant. It is a persistent authority relationship that can continue to operate after the original approval moment, which makes it different from a narrowly scoped, time-bound delegation.
In security and governance terms, the key issue is duration. Once delegation is standing, the delegated token, account, or workflow path may keep acting without a fresh contextual decision, so the original trust decision becomes a continuing security control rather than a single event.
Where Standing Delegation Shows Up
Standing delegation often appears in automation, service-to-service access, agent workflows, and other operational patterns where repeated approval would be inefficient. It can be useful when a process must run continuously, but the same persistence is what makes it sensitive to privilege creep and stale authority.
The concept is especially relevant when the delegated actor can move across multiple workflows or environments. If the authority is reused broadly, the delegation starts to resemble a durable access path instead of a narrow exception for one task or session.
Why Persistent Authority Changes the Security Model
The security difference is that standing delegation weakens the natural friction that normally limits abuse. A credential or account that remains eligible to act can be used later, in a different context, or by a different workflow than the one that originally justified it.
That makes the control problem less about initial approval and more about ongoing scope, revocation, and context sensitivity. If the delegated authority is not regularly revalidated, the environment can accumulate access that no longer matches business need.
This is why RFC 8693: OAuth 2.0 Token Exchange is a useful reference point: it formalises token exchange for delegation and on-behalf-of flows, which helps explain how delegated authority can be represented and constrained.
Standing Delegation in MCP and NHI Governance
In MCP and NHI governance, standing delegation matters because persistent authority can outlive the immediate task that created it. When a token, service account, or similar control plane credential can keep acting without fresh checks, the authority becomes harder to reason about and easier to overextend.
That is why standing delegation is often discussed alongside least privilege, expiration, and contextual reauthorization. It is not inherently wrong, but it needs clear boundaries so the delegated path stays aligned to the original purpose and does not become an always-on trust bridge.
Risk and Threat Considerations
Standing delegation creates exposure when persistent authority survives beyond the need that justified it. The longer a token or account remains usable, the more opportunity there is for misuse, forgotten access, or unintended lateral movement across workflows.
Failure mechanism: The delegated authority is not rechecked often enough, so a token, account, or workflow path remains valid after the original context has changed. That can turn a narrow delegation into a durable access path that attackers or misuse can exploit.
Impact: Excess scope and long-lived authority increase the blast radius of compromise, make revocation harder, and raise the chance that actions will occur outside the intended business context.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Standing delegation depends on governed account authority and lifecycle control. |
| AC-3 — Access Enforcement | Delegation is an access decision that must remain enforceable over time. | |
| IA-5 — Authenticator Management | Persistent delegation often relies on tokens or other credentials that must be controlled across their lifecycle. | |
| Recommendation — Review delegated accounts regularly and remove standing access that no longer matches business need. Enforce scope limits so delegated authority cannot act beyond its approved context. Set expiry and rotation rules for delegated credentials so authority does not persist indefinitely. | ||
| NIST Zero Trust (SP 800-207) | 3.0 — Zero Trust Architecture Principles | Standing delegation conflicts with always-on trust unless access is continuously verified. |
| Recommendation — Apply continuous verification and least privilege to reduce the durability of delegated access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Standing delegation can remain active after the original business need ends, creating offboarding risk. |
| NHI-05 — Overprivileged NHI | Persistent delegation can accumulate broader authority than the use case requires. | |
| NHI-07 — Long-Lived Secrets | Standing delegation often persists through tokens or secrets that remain usable for too long. | |
| Recommendation — Revoke delegated access promptly when the underlying task, owner, or workflow changes. Constrain delegated permissions to the minimum scope needed for the approved workflow. Shorten credential lifetimes so delegated authority expires before it becomes stale or overbroad. | ||
Practitioner Guidance
Why practitioners should care: Standing delegation is a governance decision, not just an implementation detail. Teams should treat it as a deliberate exception that needs ownership, expiry, and review, especially where delegated authority can cross workflow or system boundaries.
What to watch for: Pay attention to delegation paths that never naturally end, credentials that remain valid far longer than the task they support, and approvals that are never revisited after setup. Those are the conditions where persistent authority becomes hardest to justify and easiest to forget.