Delinea’s StrongDM acquisition reframes AI agent privilege control

At a glance

What this is: Delinea’s acquisition of StrongDM centers identity governance on continuous authorisation for human and non-human identities, with zero standing privilege as the core outcome.

Why it matters: IAM, PAM, and NHI teams need to treat runtime authorisation as a governance layer, not just an access-control feature, because AI-driven environments compress decision windows and widen privilege risk.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Delinea's account of the StrongDM acquisition and runtime authorisation strategy

Context

Continuous authorisation is the practice of evaluating access at the moment of action rather than only at sign-in or provisioning. In AI-driven environments, that matters because privileged activity now comes from non-human identities that can move quickly across infrastructure, data, and tooling. This acquisition lands in the middle of a broader identity governance problem, not just a vendor consolidation story.

The core issue is that standing privilege was built for access that could be reviewed, certified, and revoked on a human-paced cycle. AI agents and machine identities compress that cycle into runtime decisions, which means PAM, JIT, and lifecycle controls have to be treated as one control plane. For teams already wrestling with NHI sprawl, this is a familiar but sharper version of the same governance gap.

Key questions

Q: How should security teams implement just-in-time access for AI agents and machine identities?

A: Start by classifying the privileged actions, not just the identities, then require a runtime policy decision before each sensitive operation. The goal is to prevent persistent elevation from surviving long enough to be reused outside its intended task. Teams should also log the full action chain so review is possible after execution, not only before it.

Q: When does standing privilege become unacceptable in modern IAM programmes?

A: Standing privilege becomes unacceptable when the identity can act faster than your review cycle, especially for workloads and AI agents that move across systems autonomously. If the access can be reused for multiple tasks without fresh context, the programme is relying on assumptions that no longer hold. That is the point at which runtime enforcement becomes necessary.

Q: What do teams get wrong about zero standing privilege?

A: Teams often treat zero standing privilege as a vaulting or credential-rotation problem, when the real issue is whether access can exist without being continuously reauthorised. If policy only governs issuance, then the dangerous action still happens later with no additional check. ZSP only works when execution itself is part of the control model.

Q: Who should own continuous authorisation when PAM and NHI controls overlap?

A: Ownership should sit with the team that governs privileged behaviour across the full identity lifecycle, because continuous authorisation cuts across PAM, IAM, and NHI operations. Security, platform, and identity teams need a shared policy model so no one group assumes another is checking runtime risk. Otherwise the control exists in name only.

Technical breakdown

Why standing privilege fails in AI-driven environments

Standing privilege assumes the right to act can be granted ahead of time and remain safe until the next review cycle. That model works poorly when an AI agent, workload, or automation path can initiate privileged actions at machine speed across multiple systems. The problem is not simply excessive access, but the mismatch between static entitlement and dynamic execution. JIT runtime authorisation narrows that gap by evaluating identity, context, and policy at the moment a privileged action is requested. Practical implication: teams should treat persistent privilege as an architectural risk, not just an access-review finding.

Practical implication: inventory where persistent privilege still exists and move the highest-risk workflows to runtime policy enforcement.

How PAM and JIT runtime authorisation fit together

Traditional PAM concentrates on who can obtain elevated access, while JIT runtime authorisation decides whether a specific action should proceed right now. In a modern identity control plane, those functions become complementary rather than separate. PAM establishes governed access pathways, and JIT adds the action-level decision that makes Zero Standing Privilege possible in practice. That matters for databases, cloud infrastructure, CI/CD, and other environments where non-human identities often inherit more privilege than operators realise. Practical implication: separate approval of access from approval of action, then map both to the same policy source.

Practical implication: align PAM workflows with action-level policy decisions so approval does not end where execution risk begins.

Continuous identity authorisation for non-human identities

Non-human identities include service accounts, machine credentials, API-driven workflows, and AI agents. What changes here is not just volume, but governance timing. A credential can be valid while still being wrong for the current task, data set, or system context. Continuous identity authorisation is designed to close that gap by reassessing privilege each time the identity attempts a sensitive operation. This is especially relevant where AI agents can chain tool calls, traverse systems, or trigger downstream actions that were never explicitly pre-approved. Practical implication: govern non-human identity access as a sequence of actions, not as a one-time login event.

Practical implication: define policy around the action sequence an identity may perform, not only the identity that is permitted to authenticate.

NHI Mgmt Group analysis

Zero standing privilege is becoming the practical test for whether identity governance still matches operational reality. Standing privilege was designed for environments where access could persist long enough to be reviewed, certified, and revoked between human decisions. That assumption fails when AI agents and machine identities execute privileged actions at runtime, because the risky state may exist only for the duration of a task. The implication is that access governance must move from static entitlement management to action-time control.

Continuous authorisation collapses the old separation between PAM and runtime enforcement. For years, teams treated privileged access approval, credential issuance, and action execution as distinct layers. In AI-driven infrastructure, that separation creates gaps because the identity can already be authenticated while the action is still unsafe. The practical consequence is that identity teams have to govern the operation itself, not just the account behind it.

Identity control planes are now being evaluated on whether they can govern both human and non-human privilege with the same policy logic. That is the real market signal behind this acquisition, not the deal mechanics. Enterprises want one governance model that can handle administrators, workloads, and AI agents without creating separate exceptions for each. Practitioners should expect closer convergence between PAM, IGA, and machine identity controls.

Runtime privilege enforcement is the named concept practitioners should adopt for AI-driven access governance. It means evaluating whether a sensitive action is allowed at the point of execution, using identity, context, and policy together. That concept matters because static controls can certify an identity without understanding the action it will take next. Teams should use this lens when deciding where ZSP is actually enforceable versus aspirational.

This consolidation validates that NHI governance is moving from credential custody toward behavioural authorisation. The centre of gravity is no longer just secret storage or account hygiene. It is proving that a non-human identity may exist, but cannot act freely without contextual policy checks. Practitioners should use this shift to reclassify which controls belong in IAM, PAM, and NHI governance workstreams.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which leaves a large compliance and investigation blind spot when agent behaviour changes at runtime.
• The OWASP NHI Top 10 is the right next reference point for understanding where agent privilege, tool use, and policy enforcement break down.

What this signals

Runtime privilege enforcement is likely to become a baseline expectation for any programme that claims to govern AI agents responsibly. With 96% of technology professionals already identifying AI agents as a growing security threat, the governance conversation is shifting from discovery to enforceability, and that makes policy timing as important as policy content.

For IAM and PAM teams, the practical signal is that entitlement reviews alone will not prove control effectiveness in AI-driven environments. If your operating model cannot show whether a privileged action was authorised at the moment it occurred, the programme is still measuring access ownership rather than access behaviour.

The strongest near-term response is to align machine identity governance, privileged access policy, and runtime audit evidence into one workflow. That gives security teams a way to explain not only who had access, but whether the system should have allowed the action when it happened.

For practitioners

• Map every standing privileged pathway Identify where human administrators, service accounts, and AI-driven workflows still retain persistent elevation. Prioritise systems where access can trigger destructive, data-moving, or infrastructure-changing actions without a fresh policy decision.
• Separate access approval from action approval Define which tasks may be authorised at login and which must be rechecked at runtime. Use the same policy source for both so teams do not approve a session and then lose sight of the operation that session performs.
• Extend governance to non-human identity action chains Review workflows where service accounts, tokens, or AI agents can call multiple tools in sequence. Limit each step to the minimum required privilege and require contextual re-evaluation before downstream actions are allowed.
• Align PAM metrics to runtime decisions Measure how often privileged actions are allowed, denied, or escalated at the moment of execution, not just how many accounts are vaulted or rotated. That gives teams evidence of whether policy is actually constraining behaviour.

Key takeaways

• The acquisition matters because it pushes identity governance toward action-level control instead of static privilege custody.
• The underlying risk is not just more access, but access that exists too long and is checked too late for AI-driven operations.
• Practitioners should treat runtime authorisation as part of PAM and NHI governance, not as a separate optimisation project.

Key terms

• Zero Standing Privilege: A governance model in which privileged access is not kept persistently available. Access is granted only when needed, for only the task in scope, and removed as soon as the action is complete. In practice, this reduces the chance that a dormant credential or elevated session can be reused unexpectedly.
• Just-in-time runtime authorisation: A control pattern that checks whether a privileged action should proceed at the moment it is requested. It combines identity, context, and policy so access is evaluated against the current task rather than assumed safe because it was previously approved.
• Non-human identity: Any identity used by software rather than a person, including service accounts, tokens, API keys, certificates, workloads, bots, and AI agents. These identities often carry privileged access, which means they require lifecycle, visibility, and authorisation controls that are stricter than simple authentication.
• Runtime authorisation: The process of deciding whether a specific action is allowed while the system is running. It goes beyond login or session creation by checking the action itself, which is especially important when identities can make fast, repeated, or autonomous access requests.

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 building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Delinea: Delinea completes StrongDM acquisition to secure AI agents with continuous identity authorization. Read the original.