Cortex — Agentic Endpoint Security
Cortex Agentic Endpoint Security
Powered by Koi
Secure the agentic endpoint surface — vibe coding agents, MCP servers, browser extensions, and AI plugins. The new category of protection for an AI-native enterprise. Acquisition closed April 14, 2026.
Overview
What is Agentic Endpoint Security?
Agentic Endpoint Security (AES) is a new category of protection introduced by Palo Alto Networks with the April 14, 2026 acquisition of Koi (~$400M). AES secures the new attack surface created by AI agents on the endpoint: vibe coding agents like Claude Code and Cursor, autonomous AI tools, MCP servers, browser extensions, AI plugins, and the broader AI software supply chain.
Traditional EDR was not designed for autonomous software with production access. AES provides inventory, real-time risk analysis, and automated enforcement so harmful code from AI-generated tools and extensions never reaches production. As enterprises adopt AI-driven developer tools, the endpoint becomes the first place an autonomous agent can do damage. AES closes that gap.
AES is available three ways: as a Cortex XDR 5.0 module that uses the existing XDR agent, as a standalone product alongside any other EDR, and as part of Prisma AIRS for a single AI control plane across the enterprise.
Customer Choice
Three Deployment Modes
Customers don't have to switch EDRs to get AES. We meet them where they are.
Mode 1
Cortex XDR 5.0 Module
Integrated into Cortex XDR 5.0 using the existing XDR agent footprint. No additional agent to deploy. Findings, inventory, and enforcement actions surface inside the Cortex XDR console alongside endpoint and email findings. Best for customers already running Cortex XDR.
Mode 2
Standalone Product
Runs alongside CrowdStrike, SentinelOne, Microsoft Defender, or any other EDR. Provides AES capabilities to customers who don't run Cortex XDR but still need agentic-AI risk visibility and enforcement. Best for customers committed to a competing EDR who still need AES.
Mode 3
Prisma AIRS Integration
Koi technology extended into Prisma AIRS for a single control plane covering enterprise-wide AI adoption — endpoint AI tools, AI workloads, and model security in one place. Best for customers buying AIRS who want unified AI governance across the stack.
As of Today
How Koi Fits Across the Cortex + Prisma AIRS Portfolio
A single technology, three commercial paths. Pick the one that matches the customer's existing stack.
All three paths use the same Koi technology under the hood. Choose the path; the underlying capability set is consistent.
What it does
Key Capabilities
Buyer Profile
When to Use
- Customer is rolling out AI-driven developer tools (Claude Code, Cursor, Copilot, OpenClaw, internal agents) and wants visibility before scaling further.
- Customer has had — or is worried about — a software-supply-chain incident from a malicious browser extension, npm package, or compromised dev tool.
- CISO is being asked by the board "what do we know about agentic AI risk?" and currently has no answer.
- Customer is adopting MCP-based agent architectures and the security team has zero visibility into what those agents can do.
- Customer runs Cortex XDR 5.0 and wants to add AES via the integrated module — fastest path, no new agent to deploy.
- Customer is committed to CrowdStrike, SentinelOne, or Defender and won't switch EDRs but still needs AES capabilities — standalone is the fit.
- Customer is buying Prisma AIRS and wants AI security spanning model, runtime, and now endpoint in one control plane.
Competitive Positioning
Compete — What to Know
AES is a new category, not a like-for-like EDR replacement. The closest comparisons are software supply chain scanners and bolt-on DLP with AI policies.
vs. Snyk / GitGuardian (supply chain scanners)
Where AES wins: Real-time enforcement at the endpoint where agents actually execute, not just commit-time scanning. Inventory of installed AI tools, not just code dependencies. Operates inside any EDR or as an XDR module. MCP-layer coverage that no supply chain scanner addresses.
Where to be careful: Snyk's developer-workflow integration is mature; AES is a security-team product, not a developer-experience product. Some customers will want both.
vs. Bolt-on DLP with AI policies
Where AES wins: Purpose-built for agentic and autonomous behavior — not retrofitted. Understands tool chain hijacking, prompt injection, and memory poisoning at the endpoint. Inventory and risk analysis are first-class capabilities, not extensions of DLP rules.
Where to be careful: DLP vendors have long integration histories with HR, legal, and compliance workflows. AES is newer; some customers will want continuity with existing DLP policy frameworks.
vs. Doing nothing
Many customers haven't yet recognized agentic endpoint risk as its own category. The conversation isn't "Koi vs Competitor X" — it's "what do you currently do about AI tools running on endpoints with production access?" When the answer is silence, AES is the only purpose-built product that addresses the gap.
Services Fit
Optiv Alignment
Optiv's AI Security practice and Endpoint Security services align directly with AES deployments:
- AI tool inventory and risk assessment — discover what's already installed, score risk, prioritize what to govern first.
- Deployment-mode selection — guide customers between XDR module, standalone, and AIRS integration based on existing tooling and governance maturity.
- Policy design — translate enterprise risk appetite into AES enforcement rules that don't kill developer productivity.
- Integration with existing workflows — wire AES findings into XSIAM, ServiceNow, Jira, or whatever the customer already uses for incident and exception management.
- Operational tuning — reduce false positives, refine baselines, and report on AI risk reduction over time.
Customer Conversation
Discovery Questions
Which AI-driven developer tools is your team using today (Claude Code, Cursor, Copilot, internal agents)?
Do you have visibility into which browser extensions and MCP servers are installed across your developer endpoints?
If a malicious extension or compromised AI tool ran on a developer's machine today, how would you know?
What policies do you currently have for which AI agents can install software, access data, or call external services?
Are you running Cortex XDR today? If yes, the integrated AES module deploys without a new agent. If not, the standalone product runs alongside your existing EDR.
Has your board or audit committee asked about agentic AI risk in the last quarter?
Are you considering Prisma AIRS for AI model and runtime security? AES integrates as the endpoint side of that control plane.
What's your current process when a developer requests a new AI tool — and how long does it take?