TL;DR: Palo Alto Networks’ planned $25B acquisition of CyberArk signals that identity security has moved from a set of point controls into a platform category, while AI, machine identities, and lateral movement keep widening the attack surface, according to Silverfort. The practical shift is that IAM, PAM, NHI, and AI governance can no longer be treated as separate programmes with separate risk models.
At a glance
What this is: Silverfort argues that Palo Alto Networks' planned acquisition of CyberArk marks identity security as a platform category, not a collection of separate controls.
Why it matters: For IAM, NHI, and autonomous identity programmes, the deal reinforces that visibility, privilege control, and lifecycle governance now need to be coordinated across identity types rather than managed in silos.
By the numbers:
- $25B.
- According to research from analyst Francis Odum, 93% of breaches are preventable through improved identity security controls.
👉 Read Silverfort's analysis of the CyberArk acquisition and identity security shift
Context
Palo Alto Networks' planned acquisition of CyberArk is a signal about the direction of identity security, not just a transaction between two vendors. The primary keyword here is identity security, and the article argues that the market is moving toward unified control across human, machine, and AI-era identities rather than isolated point tools.
The governance gap is that organisations still split identity work across PAM, MFA, NHI, ITDR, and IGA while attackers treat identity as one attack surface. That fragmentation matters because access, privilege, and detection decisions are increasingly interdependent across cloud, on-prem, and AI-enabled environments.
Silverfort frames the moment as a category shift: identity security is becoming a distinct control layer above identity infrastructure. For practitioners, the implication is less about vendor consolidation and more about whether their current operating model can actually see, classify, and protect every identity type consistently.
Key questions
Q: How should security teams govern identity risk across humans, service accounts, and AI systems?
A: Teams should govern identity risk by separating lifecycle management from abuse prevention and by mapping controls to the actor type involved. Human identities, service accounts, and AI systems do not fail in the same way, so a single policy model will miss important differences in privilege, timing, and runtime behaviour. The practical test is whether one control story can explain access, elevation, and movement across the full identity path.
Q: Why do point solutions struggle to contain identity attacks?
A: Point solutions struggle because identity attacks rarely stay inside one control category. An attacker can move from credential exposure to privilege abuse to lateral movement without ever crossing a clean product boundary. If authentication, PAM, NHI, and detection are owned separately, the attack path becomes visible only after the damage is already spread across systems.
Q: What breaks when AI agents are governed like machine identities?
A: What breaks is the assumption that the identity's behaviour is stable enough to be modelled at provisioning time. Machine identities usually follow fixed workflows, but AI agents can alter tool use, sequence, and timing during runtime. That means static privilege design can understate actual reach and overstate the value of periodic review alone.
Q: How should organisations decide whether to consolidate identity security tooling?
A: Organisations should consolidate when fragmented tools prevent them from tracing one identity event across authentication, privilege, and movement. The question is not how many products exist, but whether the programme can produce a single control story for the attack surface. If not, consolidation may reduce blind spots more than it reduces licences.
Technical breakdown
Why identity security is separating from identity infrastructure
Identity infrastructure manages accounts, roles, authentication, and lifecycle. Identity security is the protective layer that detects abuse, limits privilege, and responds to compromise across those identities. The article's core argument is that treating IAM, PAM, NHI, and related tools as separate control planes leaves blind spots because attackers move across them as one path. A platform approach matters here because identity risk is no longer isolated to login events or privileged sessions; it includes standing access, credential exposure, and machine-to-machine trust. Practical implication: align operating ownership so identity protection is measured as a cross-programme control outcome, not as disconnected tool performance.
Practical implication: measure identity risk as one control outcome across IAM, PAM, NHI, and detection, not as silo performance.
Machine identities and AI agents need different control assumptions
The article distinguishes human users, machine identities, and AI agents. Machine identities such as service accounts and tokens are non-human identities with predictable execution patterns, while AI agents introduce runtime decision-making that can alter what they access and when. That distinction matters because a static privilege model assumes intent is known at provisioning time, which is not true for autonomous behaviour. For AI-era environments, identity governance must account for dynamic tool use, session scope, and uncertain action paths. Practical implication: separate the control logic for machine identities from the governance logic for autonomous agents, even when both are non-human.
Practical implication: separate machine identity controls from autonomous-agent governance, even when both are non-human.
Consolidated visibility is now part of privilege control
Silverfort argues that point solutions cannot deliver end-to-end identity protection when the real problem is attack path continuity. Unified visibility is not just a monitoring feature. It is what lets teams connect authentication, entitlement, privilege elevation, and lateral movement into one picture. That becomes especially important when the same organisation uses human logins, service accounts, API tokens, and AI-enabled workflows in the same environment. Without shared visibility, teams cannot reliably answer which identity was used, which privilege was abused, or where the control boundary failed. Practical implication: require identity telemetry that spans every identity type and every privileged pathway.
Practical implication: require telemetry that spans every identity type and privileged pathway.
Threat narrative
Attacker objective: The attacker’s objective is to turn identity access into broad environment control, then use that reach to exfiltrate data, disrupt operations, or pivot deeper into the estate.
- Entry occurs when attackers exploit identity exposure rather than a perimeter weakness, using credentials, tokens, or abused identity pathways to get into the environment.
- Escalation follows as standing privilege, lateral movement, or weak privilege segmentation lets the attacker expand access across systems and identity domains.
- Impact is achieved when the attacker reaches sensitive data, administrative control, or operational disruption through compromised identity trust.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity security is becoming the governing layer above IAM, not a feature inside it. The article is right to separate identity security from identity infrastructure, because managing identities and protecting identities are different jobs. IAM creates accounts and lifecycle states, while security has to detect misuse, reduce blast radius, and stop abuse across those states. Practitioners should treat that split as architectural, not semantic.
Machine identities and human identities cannot share one privilege model without governance leakage. The article correctly points out that NHIs outnumber humans and behave differently, which means the same access assumptions will not scale cleanly. Lifecycle, elevation, and monitoring controls need to be evaluated by actor type rather than by a single generic identity policy. Practitioners should stop expecting one control design to govern both people and workloads equally.
Dynamic AI behaviour breaks the assumption that access intent is knowable at provisioning time. Least privilege was designed for access that can be scoped before execution begins. That assumption fails when an autonomous system can change its tool use, sequence, and timing during runtime. The implication is that teams must rethink which governance decisions are still safe to make upfront and which now depend on live behavioural observation.
Consolidation in identity security will pressure teams to reassess tooling boundaries and control ownership. When large security vendors move into identity, the market signal is that identity protection is now a core control domain rather than an adjacent capability. That tends to accelerate platform consolidation while also exposing programme fragmentation inside enterprises. Practitioners should evaluate whether their current mix of PAM, NHI, MFA, and detection tools still gives them one coherent control story.
Runtime identity visibility gap: the article exposes a control model that still relies on separate products to explain one attack path. That is the real operational weakness behind the platform argument. If teams cannot trace access, privilege, and movement across identity types in one workflow, they are managing symptoms rather than the identity attack surface. Practitioners should reframe the problem as a runtime visibility failure, not a product selection exercise.
From our research:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is why control models built for static access are already under strain.
- For a broader lens on the identity side of this shift, see Ultimate Guide to NHIs for the governance patterns that still matter as machine and agent identities multiply.
What this signals
Runtime identity visibility gap: the next programme risk is not just more identities, but weaker confidence that teams can explain what each identity can do in real time. With only 13% of organisations feeling extremely prepared for agentic AI, most enterprises are still designing governance around static assumptions that no longer match operational reality.
The practical signal for identity teams is that consolidation pressure will keep rising, but consolidation by itself will not solve control fragmentation. Teams should prepare to measure whether one identity event can be traced from authentication to privilege use to lateral movement without handoffs between tools or owners.
For organisations already dealing with NHIs, the important next step is to distinguish workload identity governance from autonomous behaviour governance. A service account review and an AI agent review may both sit inside the same programme, but they require different evidence, different review triggers, and different failure detection logic.
For practitioners
- Map identity controls by actor type Inventory where your current programme treats humans, service accounts, and AI agents with the same control design. Separate the policies that manage lifecycle from the controls that prevent abuse, then identify where the same workflow is being forced across incompatible identity types.
- Trace privileged pathways across silos Walk one real access path from authentication to elevation to lateral movement and record which product owns each step. If no single control owner can explain the path end to end, the programme is fragmented at the point attackers exploit most.
- Re-evaluate static credential dependence Review where service accounts, API keys, and tokens still provide persistent access to production systems. Replace standing access where possible, but also document where behavioural monitoring is the only viable compensating control for access that cannot be made ephemeral.
- Test AI governance against runtime behaviour For any AI-enabled workflow, check whether current approval and review models assume stable intent. If the system can change tool use or timing within a session, your governance model must account for session-level behaviour rather than only provisioning-time policy.
Key takeaways
- Identity security is shifting from a set of adjacent tools into a single control layer that must explain access, privilege, and movement across all identity types.
- The clearest risk signal in the article is programme fragmentation, because attackers can move from identity exposure to lateral movement without respecting product boundaries.
- Practitioners should separate lifecycle management from protection logic and re-check whether current controls still work for AI-era runtime behaviour.
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-01 | The article centers on non-human identities and their governance gaps. |
| NIST CSF 2.0 | PR.AC-4 | Unified identity control depends on least privilege and access governance across systems. |
| NIST Zero Trust (SP 800-207) | The article's platform argument aligns with continuous verification across identity pathways. |
Apply continuous verification to identity events so access decisions are not one-time trust grants.
Key terms
- Identity security: Identity security is the control layer that protects identities from abuse, compromise, and privilege misuse. It sits above identity infrastructure, which creates and manages accounts, and focuses on detection, containment, and enforcement across human, machine, and autonomous identities.
- Non-human identity: A non-human identity is any digital identity used by software, services, workloads, tokens, certificates, or agents rather than a person. In practice, NHIs often outnumber human users and need lifecycle, privilege, and monitoring controls that reflect machine behaviour, not human login patterns.
- Identity blast radius: Identity blast radius is the amount of access or operational reach that is exposed when one identity is compromised or misused. The term is useful because the real security question is not whether an identity exists, but how far an attacker can move once that identity is abused.
- Autonomous identity behaviour: Autonomous identity behaviour occurs when an identity can decide what to do, which tools to use, and when to act without human approval between those decisions. That creates governance problems that static review cycles and provisioning-time privilege assumptions do not handle well.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Silverfort: Palo Alto Networks' planned acquisition of CyberArk and what it means for identity security. Read the original.
Published by the NHIMG editorial team on 2025-08-06.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org