Agent-based PEDM and the limits of agentless zero standing privilege

At a glance

What this is: This analysis argues that agent-based PEDM is required to make Zero Standing Privilege real because agentless models still leave standing roles, session-wide elevation, and upstream enforcement gaps.

Why it matters: It matters because IAM, PAM, NHI, and host security teams need the same privilege model to work across human admins, service accounts, and automated access paths.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Delinea's analysis of why agent-based PEDM closes the gaps in Zero Standing Privilege

Context

Zero Standing Privilege is supposed to mean that privileged access never sits around waiting to be abused. In practice, many enterprise models still depend on standing roles, vaulted superuser accounts, or session-level elevation that leaves too much privilege available for too long, especially where the identity provider remains the control point rather than the resource itself.

That distinction matters across IAM, PAM, NHI, and endpoint governance. If a control only manages who can request elevation, but not what the host allows once that elevation exists, the programme has reduced exposure without actually removing standing privilege.

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: Why do service accounts and shared admin identities complicate Zero Standing Privilege?

A: They complicate Zero Standing Privilege because shared or long-lived privileged identities can remain valid outside the moment of use, making accountability and containment harder. Even with vaulting or rotation, the access path still exists. ZSP works best when privilege is short-lived, task-scoped, and tied to a unique operator identity.

Q: What do security teams get wrong about just-in-time privilege in PAM?

A: They often treat just-in-time privilege as a synonym for true privilege removal. In many implementations, the session still becomes broadly privileged for a window of time, which is enough for malware, lateral movement, or misuse. JIT improves access control, but it does not automatically eliminate standing privilege unless the host enforces the boundary.

Q: Who is accountable when elevated access is shared across operators?

A: Accountability becomes blurred when multiple operators use the same privileged account, even if the credential is vaulted and rotated. The cleaner model is one named operator, one named task, and one auditable elevation event. Shared access may still be necessary for emergencies, but it should not be the ordinary operating pattern.

Technical breakdown

Why agentless privilege elevation still leaves standing access

Agentless or IdP-centric elevation usually works by placing a user into a privileged role or group for a limited session window. The problem is that the privileged role still exists permanently, and the elevated session often inherits broad rights rather than narrowly scoped task permissions. That creates a residual target in the directory and shifts enforcement upstream, where the server cannot independently distinguish legitimate access from replayed credentials or broker abuse. In ZSP terms, the role disappears only after use, not before privilege becomes available.

Practical implication: treat upstream elevation as risk reduction, not ZSP, unless the resource itself enforces the privilege boundary.

How agent-based PEDM changes enforcement at the host

Agent-based Privilege Elevation and Delegation Management moves the control point to the endpoint or server. Instead of granting a full privileged session, the agent elevates only the approved process, script, or command and can require local MFA at both login and elevation. That means the system can enforce policy where the action occurs, not just where the request starts. The model also lets built-in accounts remain disabled for routine use, which reduces persistent login paths while keeping break-glass access available under tighter controls.

Practical implication: place the last authorization decision at the host when you need true action-scoped privilege.

Why ZSP depends on unique identities and break-glass discipline

ZSP breaks down when organisations rely on shared superuser identities for ordinary administration. Even if passwords are rotated, accounts like root or Administrator still complicate accountability because actions cannot be cleanly tied to one person or one task. The better model is a unique low-privilege identity for every administrator, with break-glass use reserved for the smallest possible emergency set. That preserves attribution, constrains drift, and keeps privileged pathways auditable in a way shared elevated identities never can.

Practical implication: remove shared routine admin use from your operating model and reserve shared superuser access for audited emergencies only.

Threat narrative

Attacker objective: The attacker wants durable administrative reach that can be used to move laterally, disrupt operations, and exfiltrate valuable data before defenders can constrain the session.

1. Entry begins when an attacker obtains valid privileged credentials or replays an elevated session through an upstream identity control that still trusts the broker or directory role.
2. Escalation occurs when session-wide elevation or standing privileged roles grant broad rights across systems, letting the attacker move beyond the original request into admin-level actions.
3. Impact follows when those rights are used to spread ransomware, exfiltrate sensitive data, or interrupt core services at machine speed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is the wrong abstraction for host-level enforcement. Agentless models still reason about privilege as something the directory grants and later revokes, but that leaves a window in which the host itself must trust a broadly elevated session. The practical failure is not just weaker enforcement, it is that the control boundary sits too far away from the action. For IAM and PAM teams, that means ZSP cannot be claimed while privilege still exists outside the resource boundary.

Process-scoped elevation is the named concept that closes the gap left by session-scoped access. ZSP becomes materially different when the control elevates only the approved command or process instead of the entire user session. That changes the governance problem from managing broad privilege windows to managing specific executable actions. The implication is that privilege policy must be expressed where work happens, not just where identities authenticate.

Shared privileged identities undermine accountability even when they are vaulted and rotated. Root and Administrator remain operationally convenient, but they blur attribution and make emergency access look like ordinary administration. The issue is not whether the password changes, but whether the action can be tied back to a named operator and a named task. Security programmes should treat accountability as a first-class ZSP requirement, not a reporting afterthought.

Zero Standing Privilege is only credible when the endpoint can reject the wrong broker. If the host cannot tell a legitimate elevation path from a replayed credential or malicious broker, the directory becomes a single point of failure. That is why host-local enforcement matters more than upstream approval for this pattern. Practitioners should read ZSP as distributed trust, not central delegation alone.

Agent-based PEDM validates the direction of least privilege, but it also exposes how much of IAM still depends on human-paced review cycles. Session windows, approval chains, and shared roles all assume the actor remains in a reviewable state long enough for governance to act. Once the privilege boundary is pushed to the host and narrowed to a command, the old review model becomes too coarse to describe actual exposure. Teams should redesign governance around action scope, not just identity scope.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly identity risk is actually removed in practice.
• For broader breach context, the 52 NHI Breaches Analysis shows how long-lived credentials and weak offboarding patterns turn access into persistence.

What this signals

Process-scoped elevation is the more useful control concept for teams trying to operationalise ZSP. If the host can approve only the command or script that needs privilege, the programme stops relying on session-wide trust and starts expressing least privilege at the point of execution.

The practical signal for IAM and PAM leaders is whether your controls still assume privilege is stable long enough to be reviewed. If the answer is yes, then your governance model is still built for broad roles, not for action-scoped enforcement across human admins, service accounts, and automation.

With only 5.7% of organisations claiming full visibility into their service accounts, per the Ultimate Guide to NHIs, host-level privilege controls are becoming inseparable from identity visibility. Programmes that cannot see the account cannot confidently bound the privilege, regardless of where elevation starts.

For practitioners

• Map where privilege is still session-scoped Identify every place where elevation creates a broad privileged session rather than a process, command, or task-scoped entitlement. Replace those areas first, because session-wide access is where lateral movement and misuse remain easiest.
• Disable routine use of built-in superuser accounts Keep root and Administrator reserved for break-glass scenarios only, and require unique low-privilege identities for day-to-day administration. This preserves attribution and reduces the number of always-valid login paths.
• Move MFA enforcement to the host boundary Require local verification at login and again at elevation so the system can validate privilege at the point of use. Upstream MFA alone does not stop an attacker who replays a trusted broker or inherited session.
• Audit trust in your identity provider as an enforcement dependency If the endpoint cannot independently validate privileged actions, your IdP has become a single point of failure. Separate request approval from host authorization so a compromised broker does not automatically translate into full admin reach.

Key takeaways

• Agentless elevation reduces exposure but does not fully remove standing privilege because the privileged role still exists and the host still trusts the session.
• The evidence problem is not theoretical. Privilege-heavy environments remain a primary path for credential abuse, lateral movement, ransomware, and service disruption.
• To get closer to Zero Standing Privilege, teams need host-enforced, action-scoped elevation, unique admin identities, and break-glass use reserved for emergencies.

Key terms

• Zero Standing Privilege: Zero Standing Privilege is an operating model in which privileged access is not kept available for routine use. Access exists only when needed, for the minimum scope required, and is removed immediately after the task is complete, reducing the attack surface for both humans and machines.
• Privilege Elevation and Delegation Management: Privilege Elevation and Delegation Management is the discipline of granting elevated rights for a defined task and then removing them when that task ends. In mature implementations, enforcement happens close to the resource, which helps preserve accountability and limit blast radius.
• Break-glass access: Break-glass access is emergency privileged access reserved for exceptional situations when normal administration paths are unavailable. It should be tightly controlled, logged, and rare, because it is meant to preserve continuity without becoming an everyday workaround for weak governance.
• Standing privilege: Standing privilege is any elevated access that remains continuously available instead of being provisioned only at the moment of need. It is easier to operate, but it expands exposure because attackers can reuse it whenever they obtain the associated account or session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Delinea: Why agent-based PEDM is the only path to Zero Standing Privilege. Read the original.