Palo Alto Networks’ Koi acquisition shifts AI agent endpoint security

At a glance

What this is: Palo Alto Networks' acquisition of Koi reframes endpoint protection around agentic AI identity and access risk, with a focus on securing coding agents and autonomous tools.

Why it matters: IAM, NHI, and endpoint teams now have to treat agentic tools as access-bearing identities whose runtime behaviour can outgrow static control models.

👉 Read Palo Alto Networks' acquisition announcement for Koi and agentic endpoint security

Context

Agentic endpoint security is the attempt to govern AI tools that can take actions on endpoints, not just run in the background. The problem is that existing identity and endpoint models assume the actor behind the activity is stable, reviewable, and bounded. When coding agents can access sensitive systems and data during execution, the security question shifts from device trust to runtime identity control.

That matters for NHI governance because the endpoint is now part of the identity plane, not just the device plane. If an AI tool can retrieve credentials, move data, or trigger actions on behalf of a user, then access scope, session control, and monitoring all need to reflect the agent as an operational identity. The starting point in this market is typical: enterprises are adopting the tools faster than they are redesigning governance.

Key questions

Q: How should security teams govern AI agents on endpoints?

A: Security teams should govern AI agents on endpoints as access-bearing identities, not as ordinary software. That means defining owners, scoping what each agent can reach, logging its actions with identity context, and revoking access when the workflow ends. The key is to align runtime authority with task intent, especially where agents can touch secrets, code, or production systems.

Q: Why do coding agents change endpoint security assumptions?

A: Coding agents change endpoint security assumptions because the activity can be legitimate software behaviour while still exceeding business intent. EDR can see the process, but it cannot by itself judge whether the agent should have reached a repository, secret store, or API. That turns identity scope into the decisive control point for endpoint governance.

Q: What breaks when AI tools are not governed like identities?

A: When AI tools are not governed like identities, organisations lose accountability for who or what accessed sensitive systems, and they cannot reliably prove whether a session stayed within scope. That creates audit gaps, weak offboarding, and unclear privilege ownership. In practice, the tool behaves like an unmanaged non-human identity with no lifecycle controls.

Q: How do teams reduce the risk of autonomous tools accessing sensitive data?

A: Teams reduce risk by narrowing the access window, separating agent permissions by task, and requiring evidence that every privileged action was expected. They should also revoke connectors and secrets when the tool is retired or repurposed. If the same credentials follow the tool across multiple workflows, the control model is already too loose.

How it works in practice

Agentic endpoint security and runtime access scope

Agentic endpoint security focuses on what a coding agent or autonomous tool can do while it is actively interacting with local software, cloud services, and sensitive data. Unlike a static workload, an agent may switch tasks, call tools, and touch multiple systems in one session. That creates a governance problem because access is no longer just provisioned once and reviewed later. The control point shifts to runtime visibility, session scoping, and detection of tool-use patterns that exceed the intended task boundary.

Practical implication: map which endpoint tools can reach secrets, code, and production systems, then require runtime telemetry for every privileged agent session.

Why traditional endpoint controls miss agentic identity behaviour

Traditional endpoint security was designed around malware, user activity, and device compromise. Agentic tools complicate that model because the action is often legitimate from a software perspective while still being risky from an identity perspective. A coding agent may execute commands, open files, or interact with APIs in ways that look normal to EDR but exceed the business intent of the session. This is why identity context, authorisation context, and tool context have to be evaluated together.

Practical implication: correlate endpoint alerts with identity and access data so agent-driven actions can be judged against intended scope, not just process reputation.

Single control plane logic for AI adoption

A single control plane for AI adoption matters because agentic systems are spreading across endpoint, cloud, and data workflows at the same time. If governance is fragmented, one team may approve the agent, another may monitor the endpoint, and a third may own the data exposure, leaving no full view of effective privilege. The technical issue is not only control consolidation but evidence continuity. Practitioners need a traceable record of who or what the agent acted for, what it could reach, and what changed during the session.

Practical implication: unify entitlement, endpoint, and audit data so every agent action can be traced back to a scoped identity decision.

NHI Mgmt Group analysis

Agentic endpoint tools are becoming identities in practice, even when organisations still treat them as software features. Once a coding agent can access systems, read data, and execute commands, it behaves like an access-bearing actor rather than a passive application. That shifts the governance burden from device hygiene to identity control, because the real risk is not installation but authority. Practitioners should classify these tools by runtime privilege, not by product category.

The runtime identity gap is the named concept this market is exposing. Endpoint security tools were designed to observe machines and processes, while IAM was designed to govern stable subjects and reviewable entitlements. Agentic tools sit between those models and can change context mid-session, which means neither side fully owns the failure mode. The implication is that identity governance for endpoints now needs to follow action, not just account, and that is a programme design issue, not a logging issue.

Access review assumptions weaken when the actor can change scope faster than review cycles can observe. Review processes were designed for entitlements that persist long enough to be certified, challenged, or revoked. With agentic tools, the meaningful question is whether the active authority matched the task at the moment of execution. That forces practitioners to rethink the evidentiary model behind access governance, not merely add a new policy layer.

Platform consolidation is signalling that agentic AI governance is moving into the core identity and security stack. Endpoint, identity, and AI controls are no longer separable categories in practice. For practitioners, the important signal is that governance has to account for tool-use, data access, and execution authority together, because that is where agentic risk accumulates. The control model is becoming cross-domain by necessity.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Use the OWASP Agentic AI Top 10 to map tool misuse, and compare it with the NIST AI Risk Management Framework for governance design.

What this signals

The practical signal for practitioners is that agentic endpoint governance will need to sit closer to IAM, not only EDR. As coding agents move from pilot to production, identity telemetry, secret access, and endpoint activity will have to be judged together or the control picture will remain incomplete.

Runtime identity drift: agentic tools can accumulate authority across a session in ways that static approval models do not capture. Teams should expect audit questions about who approved the task, what the agent could reach, and whether that authority was still appropriate at the moment of execution.

With 80% of current AI-agent deployments already showing rogue behaviour in the SailPoint research, the governance problem is no longer hypothetical. Practitioners should plan for evidence quality, offboarding discipline, and cross-team ownership before agentic tools become deeply embedded in endpoint workflows.

For practitioners

• Classify agentic endpoint tools as access-bearing identities Inventory coding agents and autonomous endpoint tools alongside service accounts and other non-human identities, then assign owners for privilege, telemetry, and offboarding. Treat any tool that can touch production systems or secrets as a governed identity subject, not a convenience layer.
• Tie endpoint telemetry to entitlement context Correlate process activity with identity records, approved task scope, and secret access so you can tell whether the agent stayed within intent. This is especially important where multiple teams share responsibility for endpoint, IAM, and data controls.
• Scope agent sessions to discrete tasks Limit what a coding agent can reach during a single workflow, and force re-authorization when it moves across data classes, environments, or privileged APIs. The goal is to shrink the authority window around each action sequence.
• Build offboarding for agentic tools Require a documented disablement path for every agent or autonomous tool that is removed, replaced, or no longer approved, including credential revocation, connector teardown, and audit retention. Without that, the identity can outlive the business use case.

Key takeaways

• Agentic endpoint security is fundamentally an identity problem because these tools can act with meaningful authority, not just execute code.
• Most organisations are moving faster on deployment than on governance, which leaves endpoint, IAM, and data controls out of sync.
• The control question is no longer whether the agent runs, but whether its authority was scoped, monitored, and revoked as an identity lifecycle event.

Key terms

• Agentic Endpoint Security: A governance model for AI tools that act on endpoints with enough authority to access data, run commands, or trigger workflow changes. The focus is not just endpoint detection but runtime scope, identity context, and revocation when the task or session ends.
• Access-Bearing Identity: Any software or machine actor that can exercise meaningful access to systems, data, or secrets. In agentic environments, this includes tools that look like applications but behave like identity subjects because they hold permissions and make runtime choices.
• Runtime Identity Drift: The gradual expansion or change of authority while an actor is active, often within a single session. For agentic tools, drift can happen as the agent switches tasks, calls new tools, or reaches systems that were not part of the original intent.
• Authority Window: The period during which an identity is allowed to act with a given level of privilege. In agentic systems, the window may need to be much smaller than a traditional session because the actor can complete several high-impact actions before a human review cycle would normally trigger.

Deepen your knowledge

Agentic endpoint security and access-scoped AI tools are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for coding agents and other endpoint-bound identities, it is worth exploring.

This post draws on content published by Palo Alto Networks: Introducing Idira and the completion of its acquisition of Koi for agentic endpoint security. Read the original.