TL;DR: Agent-based PEDM shifts privilege enforcement to the host, eliminating routine standing access and narrowing elevation to specific actions, while agentless IdP-centric models still leave persistent roles and session-wide exposure, according to Delinea. The unresolved issue is that ZSP assumptions built around directory-held privilege and upstream MFA do not fully hold when enforcement stops at the identity provider.
At a glance
What this is: This is an analysis of why agentless zero standing privilege still leaves residual privileged access risk and why host-level PEDM changes the control boundary.
Why it matters: It matters because IAM and PAM teams need to distinguish reduced exposure from true privilege elimination when designing controls for servers, cloud platforms, and administrative workflows.
Context
Zero Standing Privilege is meant to prevent privileged access from lingering in a reusable state, but that goal depends on where enforcement actually happens. When elevation is mediated only through the identity provider, the control can still leave standing roles, shared privileged identities, and session-wide rights that survive long enough to be misused.
In plain terms, agentless models can reduce friction without eliminating the privilege state the attacker wants. This article is about the gap between directory-level approval and host-level enforcement, which is why it sits squarely in NHI and privileged access governance.
The article's core claim is that the control boundary matters more than the label. If privilege is not enforced at the server or endpoint, the organisation has changed the workflow, not fully removed the standing access condition.
Key questions
Q: What breaks when privilege elevation is handled only in the identity provider?
A: The model breaks when the IdP is treated as the only enforcement point, because the host still receives a broad elevated session that it cannot independently challenge. That creates standing roles, replay risk, and weak attribution. If the server cannot validate the action itself, the programme has reduced friction without achieving Zero Standing Privilege.
Q: When does just-in-time elevation still leave excessive risk?
A: It still leaves excessive risk when the entire session receives admin rights and the server cannot scope privilege to one command or process. In that case, the session becomes the unit of trust, which expands blast radius and makes malware or misuse harder to contain.
Q: How should security teams reduce the blast radius of privileged identities?
A: Security teams should define a small set of tightly governed admin identities, give them the minimum authority needed, and make elevation time bound. The goal is to prevent one compromise from cascading across identity, device, and SaaS control planes. Continuous review of who can administer what is more important than periodic access cleanup.
Q: What is the difference between agentless ZSP and host-level PEDM?
A: Agentless ZSP changes how access is granted, while host-level PEDM changes where privilege is enforced. The first can still rely on directory-held roles and upstream approval, but the second lets the resource itself validate and scope the privileged action.
Technical breakdown
Why agentless ZSP still leaves standing privilege
Agentless ZSP commonly shifts privilege administration into the identity provider, where users are added to privileged roles or groups for a session window. That still leaves durable objects in the directory, which means the privilege model exists even when a session is not active. The result is a control that limits duration but not the existence of the privileged identity state. Because enforcement is external to the host, the server cannot independently verify whether a request is legitimate or replayed. That is why the model reduces risk without eliminating the attack surface.
Practical implication: treat directory-held privileged roles as residual standing access even when the workflow is marketed as just-in-time.
How agent-based PEDM changes the enforcement point
Agent-based PEDM moves decision and enforcement to the endpoint or server, where the resource itself decides whether a specific process, command, or login action gets elevated. This matters because the host can scope privilege to the exact action rather than the whole session. It also means the privileged account does not need to remain broadly usable for routine work. Instead, the account can be disabled for normal use and reserved for break-glass conditions, while day-to-day work happens through low-privilege identities. The control boundary shifts from approval to execution.
Practical implication: place elevation controls where privileged actions occur, not only where authentication is brokered.
Why session-wide elevation weakens attribution and containment
When an elevated session inherits full admin rights, every action in that session inherits the same trust level. That makes attribution harder because shared or temporary privileged identities obscure who did what, and it makes containment harder because malware in the session can reuse the elevated context. The article's distinction is between task-scoped elevation and blanket session rights. Task-scoped elevation narrows blast radius because only the authorised process is elevated, while everything else remains at standard user rights. That is the practical divide between controlled privilege and broad access.
Practical implication: separate process-level elevation from session-level trust if you want smaller blast radius and cleaner accountability.
Threat narrative
Attacker objective: The attacker wants durable privileged reach that can be used to spread malware, exfiltrate data, or shut down critical systems.
- Entry occurs through compromised credentials or stolen tokens that can be replayed against privileged access workflows.
- Escalation happens when the attacker inherits session-wide administrative rights or standing privileged roles that already exist in the directory.
- Impact follows when those rights are used to move laterally, deploy malware, or disable systems before the session expires.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentless ZSP is risk reduction, not privilege elimination: When the privileged identity still lives in the directory, the organisation has not removed standing privilege, only wrapped it in a temporary workflow. That distinction matters because the attacker still has a durable target. The practitioner conclusion is simple: the control state must be judged by where privilege exists, not by how quickly it expires.
Privilege enforcement belongs at the resource, not only at the IdP: The article exposes a structural weakness in upstream-only governance. If the server cannot validate and scope elevation locally, it cannot distinguish a legitimate broker from a replayed credential or malicious session. The implication is that ZSP claims need host-level proof, not directory-level intent.
Session-wide admin access creates identity blast radius: Once elevation is granted across an entire session, the damage model changes from one command to the whole administrative context. That broad trust increases misuse potential and makes attribution weaker. Practitioners should read this as a governance problem as much as a technical one: the blast radius is defined by the unit of trust.
Host-level PEDM is a better expression of zero standing privilege than role mutation: The article sharpens a useful concept, identity blast radius, meaning how far one privileged decision can travel before it is constrained. Role mutation in the IdP still leaves the blast radius intact inside the session, while host-scoped elevation shrinks it to the task. The practical conclusion is that ZSP should be measured by scope of privilege, not just by its duration.
The real assumption collapse is that identity-provider control equals resource control: That assumption was designed for environments where approval upstream could reliably represent effective privilege downstream. It fails when the actor can still execute broadly on the host after the broker grants access. The implication is that identity governance must separate authorization intent from enforcement reality, especially for privileged server access.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: Just-in-Time Access and Zero Standing Privilege Guide
What this signals
Identity blast radius is the right way to think about this category. If privilege is granted at the session level, the organisation has not removed standing access so much as concentrated it into a shorter but still broad exposure window. That changes how PAM teams should evaluate control effectiveness, because duration alone is no longer a sufficient measure of risk.
Agentless privilege workflows also blur governance ownership. IAM may own the approval path, but the resource owner still needs to answer for what the host actually allows once elevation is granted. That is why host-level enforcement, not directory-side intent, becomes the more defensible control boundary for privileged server access.
For practitioners
- Separate approval from enforcement Use the identity provider for authentication and request workflow, but require the server or endpoint to make the final elevation decision for privileged actions.
- Restrict routine use of privileged accounts Disable built-in administrator and root accounts for daily login, then reserve them for audited break-glass use only.
- Scope elevation to the process level Grant elevation to the specific installer, command, or service task instead of applying admin rights to the whole session.
- Require unique accountable admin identities Make administrators sign in with individual low-privilege accounts so privileged activity can be tied back to a single person.
Key takeaways
- The article argues that agentless zero standing privilege still leaves residual standing roles and session-wide exposure, so the control is weaker than the label suggests.
- The practical failure is the control boundary itself. If the host cannot enforce privilege locally, directory-level approval does not fully eliminate misuse risk.
- Teams should judge ZSP by where privilege is enforced and how narrowly it is scoped, not by whether access expires after a short interval.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agentless ZSP leaves standing privileged roles and broad session rights in place. |
| Recommendation — Reduce residual standing privilege by scoping elevation to the specific action or process. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on privileged credential handling and how access is granted and revoked. |
| Recommendation — Use IA-5 to govern privileged credential lifecycle and prevent persistent administrative access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is how entitlements are assigned, scoped, and revoked for privileged access. |
| Recommendation — Apply PR.AA-05 to ensure privileged entitlements are temporary and tightly constrained. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on managing privileged accounts, groups, and break-glass identities. |
| Recommendation — Use CIS-5 to inventory privileged accounts and remove routine login paths for superuser identities. | ||
Key terms
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
- Privilege Elevation and Delegation Management: A privileged access model that grants higher permissions only when a task requires them and removes them when the task ends. In practice, it narrows the window in which elevated rights exist, which reduces exposure for both human administrators and non-human identities.
- Break-glass Access: Break-glass access is an emergency path that bypasses normal access controls when standard authentication fails or a critical incident demands immediate intervention. It must be tightly time-bound, logged, and reviewed, because it exists to restore operations without becoming a permanent back door.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org