Cortex Agentic Endpoint Security: Watching the Layer Your EDR Forgot

In January 2026, two malicious AI coding extensions, a campaign Koi Security named MaliciousCorgi, worked their way onto the official Visual Studio Marketplace posing as ordinary AI chat and coding assistants providing autocomplete suggestions, an explanation for the error you just hit. A developer installs one the same way they install any extension. A couple of clicks, broad permissions granted without a second thought, back to work. Nothing about the install looks unusual.

That's the point.

By the time anyone noticed, the two extensions had close to 1.5 million installs between them, and they had been quietly shipping the contents of every file a developer opened, plus up to 50 workspace files whenever the operator asked for them, to a server in China. Nobody who installed one had any idea an extension they trusted was doing it.

Run that same install through Cortex Agentic Endpoint Security (Cortex AES from here on, and no relation to the cipher), formerly Koi, and the story changes at every step. Total Visibility catches the extension the moment it lands and shows exactly what it can access and what it talks to externally. Actionable Risks correlates reputation, exploitability, code intent and privilege boundaries and scores it before a human has to notice something is off. Proactive Guardrails and Control decides, before installation finishes, whether that combination of publisher and permissions is allowed to run at all. And if something still gets through, Real-Time Prevention's synchronous hooks sit in the extension's execution path, so the exfiltration call itself gets intercepted before it leaves the machine instead of surfacing in a log the following week.

I'll walk through why agentic AI has quietly redrawn the endpoint attack surface, how the four pillars of AES work together to close it, where it sits in the traffic to make that possible, and where it overlaps (or doesn't) with the tools you're probably already running.

The endpoint isn't an endpoint anymore: how agentic AI rewired the attack surface

For most of my career, "the endpoint" meant an operating system and the binaries running on top of it. That definition doesn't hold anymore. Today's endpoint is a platform: applications, code packages, browser and Integrated Development Environment (IDE) extensions, AI models, Model Context Protocol (MCP) servers, skills, and the agentic platforms (Claude Code, Cursor, Windsurf) that string all of it together. Employees bring these tools in faster than security teams can inventory them, and increasingly the AI agents themselves are doing the bringing.

That last part is the shift I want to sit on for a minute. An agent doesn't only run on the endpoint. It acts on behalf of the user, under the user's own identity and permissions, often without the user reviewing or even seeing the action. We've spent years assuming that an action taken under a user's credentials means the user intended it and knew about it. Agentic AI breaks that assumption. When an agent can call tools, move data or invoke other agents on its own, "who did this" stops being a simple question, and the blast radius of one compromised extension or MCP server extends to everything that identity can touch.

When Palo Alto Networks closed the Koi acquisition in April 2026, Chief Product and Technology Officer Lee Klarich put it this way: these agents "operate with access to critical systems and sensitive data, creating the ultimate insider threat." Software with that reach, running under an identity every control in the environment already trusts. This really starts to reframe the problem. An insider threat program never assumed the badge holder was malicious. It assumed the badge holder's access could be misused. With agents, that misuse happens at machine speed, under a badge nobody issued on purpose, and it looks identical to legitimate work in every log you already collect.

This is not only a developer problem, which is the assumption I keep having to remind everyone about. The same pattern runs through the business units with a browser extension in place of an IDE plugin. Someone in finance installs an AI meeting assistant or an email summarizer, approves the permissions it asks for, and it does exactly what it promised. It also inherits that person's authenticated session. Unit 42's research on high-risk GenAI browser extensions flagged 18 of them doing exactly that. One Gmail and Outlook assistant, Supersonic AI, POSTed the subject, sender, recipients and body of every message the user read or sent to an external server in plaintext, one-time passcodes included. No exploit, no malware and nothing an endpoint tool would recognize as an intrusion. The person had every permission to install it. What changes is what gets exposed: contracts, payroll records, customer data and board material instead of source code.

The numbers back this up. In February 2026, Koi disclosed an operation called ClawHavoc that had seeded ClawHub, the skill marketplace for OpenClaw, with malicious skills: 341 in Koi's first disclosure, a count Palo Alto Networks now puts past 1,000. The MaliciousCorgi campaign I opened with landed the same quarter. And in November 2025, Shai-Hulud 2.0 left more than 25,000 malicious repositories across roughly 350 GitHub accounts, leaking NPM tokens, GitHub personal access tokens and cloud credentials at scale.

Most organizations can't answer three basic questions today: how many agents are active, what data they can touch, and what they are allowed to do.

Enter Cortex AES: a category built for agents

Palo Alto Networks announced its intent to acquire Koi on February 17, 2026 and closed the deal on April 14, introducing what it calls a new category of protection: Agentic Endpoint Security. Instead of bolting AI monitoring onto existing endpoint tools, AES rebuilds application control for the AI era around four pillars, named here the way the AES solution brief names them:

• Total Visibility: complete visibility into the AI tools, agents and modern software running in the environment.
• Actionable Risks: translating complex security signals into clear, context-aware decisions.
• Proactive Guardrails and Control: governing what packages, extensions and AI tools are allowed to be introduced or configured in the first place.
• Real-Time Prevention: stopping malicious activity, unsafe interactions and prompt injections as they happen.

I'll walk through each one, then get into the part I find most interesting: the gap it closes that EDR and XDR were never built to close.

Total visibility: if you can't see it, you can't govern it

AES starts with a real-time inventory of everything modern running on an endpoint: applications, the OS, drivers, code packages, AI models, extensions, containers and skills. That part sounds like table stakes, and it would be, except AES pairs the inventory with a dynamic risk assessment of how each component behaves: the data it can access, the external services it talks to, the actions it can perform and where it creates exposure.

That's the difference between a passive inventory and an active understanding of risk.

AES surfaces specific capabilities like data export, unauthenticated tool execution, external calls and auto execution, and flags specific risks like prompt injection vulnerabilities and unmanaged components. Instead of a spreadsheet of installed software, you get a live map of where exposure exists, how it spreads and what needs attention.

The same blind spot shows up in categories that get less attention. Koi's own research caught what it called the first malicious MCP server found in the wild, back in September 2025; a counterfeit NPM package called postmark-mcp that added a single line of code in version 1.0.16 and quietly BCC'd every email an agent sent through it to an attacker-controlled address. Unit 42's research into model namespace reuse showed the same trust gap on the model side such as a Hugging Face author deletes their account or transfers the organization, the Author/ModelName path becomes claimable again, and an attacker who re-registers it gets an agent to pull a backdoored model instead of the real one. Unit 42 demonstrated reverse shells that way against models in both Vertex AI Model Garden and Azure AI Foundry.

Actionable risks: fewer alerts, more answers

Visibility alone doesn't help if every finding lands in the queue with equal weight. That's the same alert fatigue problem I've watched play out in Security Operations Centers (SOCs) for years, just aimed at a new category of software. AES addresses it with a risk engine driven by a Large Language Model (LLM)-based AI researcher that runs in-depth, context-aware risk analysis on every software version across the stack, from traditional applications to agentic systems.

The engine correlates reputation, exploitability, code intent and privilege boundaries to build a real-time, multidimensional map of risk. It connects signals that used to sit in isolation (a prompt injection attempt here, an unsafe cross-agent interaction there) and turns a pile of low-context alerts into a small number of high-confidence findings a security team can act on.

Proactive guardrails and control: trust it before you run it

Here's where I think AES earns its keep with software supply chain risk specifically. The instinct with most endpoint controls is to police behavior after something is already running. AES flips that. Out-of-the-box policies and guardrails govern what packages, extensions, models and MCP servers are allowed to be introduced in the first place, so trust gets established, or denied, before code ever executes on the endpoint.

Look at the Delayed Access guardrail in the screenshot above for a second. It blocks installation of brand-new packages or extensions for a set minimum period, two days in the example, before they're allowed into the environment at all. Its sibling guardrail, Version Update Cooldown, does the same for a newly pushed update to a package you already trust, which turns out to be the one that matters most below. That's a deceptively simple control aimed at a real problem. In the old model, a human had to notice a new package existed, maybe read about it or ask around, before installing it, and that friction bought time for the community to catch anything malicious. AI coding agents remove that friction entirely. An agent evaluating dependencies doesn't hesitate, doesn't research the publisher and doesn't wait for a changelog to look suspicious. It pulls the latest version because latest is usually what the task calls for, and it does it in seconds.

That's exactly the window Shai-Hulud 2.0 lived in.

The whole campaign worked because a fresh malicious version of an already-trusted package carries unearned trust from the moment it publishes, and the worm only needed hours. By the time NPM finished pulling packages it had left more than 25,000 malicious repositories behind, all of it tracing back to one manually published version of @asyncapi/specs. A cooldown period buys back the dwell time an AI agent otherwise erases. The newest version of anything sits in quarantine long enough for reputation signals, community scrutiny and AES's own risk engine to catch up before it's trusted to run. When the agent installing your dependencies doesn't know to be suspicious of anything, a mandatory pause is one of the few controls built for how fast this now moves.

That doesn't mean security becomes another dead end for developers. When something is blocked, static denial gives way to a request-approval workflow, so a user can provide a business justification instead of hitting a wall. And when something already deployed turns out to be untrustworthy, administrators get one-click removal, updating or reconfiguration across every affected endpoint, no ticket queue required.

Shift the trust decision left, and you spend a lot less time cleaning up after it.

Unit 42's own research backs up why that kind of pre-execution check matters, especially for skills. This is a different study from ClawHavoc, run later against the whole OpenClaw registry, so keep its numbers separate from the ones above. Their Behavioral Integrity Verification (BIV) work crawled OpenClaw's public skill registry, all 49,943 listed skills, and compared what each skill's metadata claimed against what its code and natural-language instructions actually did. Four out of five skills, 39,933 of them, showed at least one mismatch. Unit 42 is careful to say that is not 80% malicious of the deviations they classified, but 81% read as developer oversight rather than intent. But 5% of the registry, 2,490 skills, carried multi-stage attack chains such as reading a credential and transmiting it, or hijack the agent's instruction stream and exfiltrate from there. Those two patterns alone accounted for 88% of all multi-stage chains BIV found. A gateway that only checks publisher reputation and package age would wave every one of them through. Catching them means comparing what a skill says it does against what it actually does, before it ever gets an agent's credentials.

Real-time prevention: the layer EDR and XDR never saw

This is the part of AES I've found the most interesting, because it's an instrumentation gap, not a detection gap. Traditional EDR and XDR telemetry is built around process creation, binary execution, file and registry writes and network connections, the fingerprints of compiled malware and human-driven attack chains. Agent-driven threats frequently don't touch any of that. A prompt injection that steers an already-trusted agent, a malicious MCP tool call or a compromised extension calling an API directly can move data or act without ever spawning a new process or dropping a binary to disk. The whole thing can run inside a signed, legitimate process the entire time.

EDR and XDR are watching the right layer for the threats they were built for. This class of threat lives one layer up.

AES closes that gap by deploying synchronous security hooks directly into the agent's execution path, intercepting intent before it reaches the system shell or the underlying LLM. That's enforcement at the exact moment of risk, and it shifts the model from "detect and respond" to "intercept and validate." It's built for the threats that specifically bypass conventional defenses such as indirect prompt injections, unauthorized tool calls and automated data exfiltration. When an agent attempts an unsanctioned action, AES blocks the operation on the spot without disrupting the rest of the developer's workflow, and gives security teams one control plane to watch it from.

Since the close, Palo Alto Networks has been specific about what that looks like in practice. In its August 2026 update covering the first quarter of Koi under Cortex, runtime custom policies span Cursor, Claude Code and Antigravity and can restrict shell execution, file access, MCP tools, skills and network requests. Two enforcement modes ship: block, which denies the action, and ask, which pauses the agent for explicit user approval so intent gets confirmed before the action runs. When a policy fires, the block message shows up inside the agent's own chat window, and the developer can request an exclusion from there. The same release added personal account detection across Claude Code, Cursor, Codex and Antigravity, flagging any session where the signed-in account's email domain isn't the organization's, which is the shadow AI question every CISO asks first. On the platform side, the deployment portal covers macOS and Windows endpoints, and registry traffic can be routed through Quick Trust or a native SASE integration.

The chokepoint: where AES actually sits in the path

Look closely at the blocked request above and you'll notice the URL. The Node Package Manager (NPM) install doesn't fail against registry.npmjs.org directly. It fails against a gateway address, npmjs-demo.gateway.koi.security. That detail tells you how this works. Package manager traffic, and by extension the traffic from the AI tools and MCP servers built on top of it, gets routed through an enforcement point that evaluates it against policy before it ever reaches the public registry. The request gets evaluated in line rather than sampled after the fact from a log.

The install path. AES decides at the gateway. SCA and SBOM tooling scan later, after the package is already on disk.

Mechanically, that gateway is a forward proxy built for package registries instead of general web traffic. The package manager's registry URL gets pointed at the gateway the same way a corporate web proxy intercepts HTTP, except this one understands NPM, PIP and the other registry protocols well enough to parse the request, check it against policy (publisher reputation, package age, the cooldown window from the Delayed Access guardrail) and only then forward it to the real registry or return the block page you saw above. Nothing gets pre-downloaded and scanned afterward. The decision happens on the wire, inside the same request cycle the install already makes, which is why a developer or an agent doesn't notice the extra hop unless something gets blocked. It's the same trust-before-deployment pattern from the guardrails section, applied at the network layer instead of the policy layer.

If you already run something like an enterprise repository manager with curation turned on, you have part of this today, and I don't want to oversell the gap. A curated private registry does gateway-style blocking for the package managers that are pointed at it, which in most shops means continuous integration and whatever the developer's .npmrc happens to say this week. What it doesn't see is the VS Code and JetBrains marketplaces, MCP server installs, skill registries or a model pulled from Hugging Face, and I've yet to look at a developer laptop that didn't have at least one tool going straight to the public registry anyway. The AES gateway sits in front of every registry a tool might reach rather than only the one your mirror serves, so it evaluates the request regardless of where the tool was headed. That is the practical difference between a package gateway and a software gateway. Before the acquisition, Koi described that gateway as a Supply Chain Gateway fronting GitHub, Hugging Face, the Chrome Web Store, the VS Code Marketplace and Homebrew alongside the package registries, which is the coverage list that matters when the question is what a curated NPM mirror leaves out.

Three campaigns, four pillars: what catches what

I opened with MaliciousCorgi run through all four pillars because it's the cleanest illustration. The other two campaigns deserve the same treatment, because they fail in different places.

ClawHavoc is the visibility case. Hundreds of malicious skills reached a public marketplace, and that worked because almost nobody inventories skills at all, so there was nothing to compare a new one against. Unit 42 later tracked a separate set of five skills on the same marketplace that stayed live from February to May 2026, clearing both ClawScan and VirusTotal. One of them buried its payload at the top of a README and padded the file with 22 MB of filler to blow past scanner size limits. Different skills, same lesson that a publisher reputation check on its own would not have saved you. What catches this is the risk engine reading the skill's code and instructions instead of its listing, plus the cooldown holding a brand-new skill out of the environment while the community works out what it does.

Shai-Hulud 2.0 is the timing case. The worm's whole advantage was that a fresh, malicious patch version of an already-trusted package carries unearned trust the moment it publishes, and an agent resolving dependencies pulls the newest version without pausing to wonder. Here the guardrail and the gateway do the work together. Version Update Cooldown denies the version for being new, and because the decision happens at the gateway, the install request never reaches the registry and the poisoned version never lands on disk. If something did execute, the preinstall script's credential read and outbound send are precisely what Real-Time Prevention is positioned to intercept.

A different pillar carries the weight in each case. That is the argument for having all four instead of buying the one that happens to map to last year's incident.

The pattern hasn't slowed since. Palo Alto Networks' write-up of the TeamPCP attack on Nx Console in May 2026 is worth reading next to these three. The poisoned extension was live for roughly 18 to 36 minutes and showed 28 installs on the VS Marketplace and 41 on OpenVSX, yet activation telemetry counted about 6,000. Credentials from a single compromised employee device were enough for the actor to walk out with roughly 3,800 of GitHub's internal repositories and offer them around for $95,000. That is the timing case and the permissions case in one incident, and it's the clearest argument I've seen for a version cooldown on IDE extensions specifically, not only on packages.

Overlap or gap? Where AES fits with what you already run

The question I get most often is whether AES duplicates the Software Composition Analysis (SCA) or Software Bill of Materials (SBOM) tooling, the Cloud Access Security Broker (CASB) or the Chrome Enterprise extension management a team already has in place. Mostly, no. SCA and SBOM tools inventory known packages and match them against vulnerability databases. They're strong at catching a known-bad version and weaker at catching a brand-new extension behaving maliciously right now. CASB and SaaS Security Posture Management (SSPM) tools govern SaaS posture and access, not what's running locally on an endpoint. Chrome Enterprise extension management is stronger than it usually gets credit for, ExtensionSettings can block by requested permission, fence an extension off named hosts with runtime_blocked_hosts, and the Admin console now surfaces third-party risk scores. What its reasons about are what an extension declares, not what its code does at runtime, and it has nothing to say about IDE extensions, MCP servers, local models or agent-to-agent calls.

The objection I hear more than any of those is application control. Teams running Windows Defender Application Control (WDAC), AppLocker, Defender's attack surface reduction rules or Cortex XDR's own allowlisting assume they have this covered, and it's a reasonable assumption right up until you look at what actually executes. Every threat in this post ran inside a host that was already allowed and already signed such as Code.exe, node, python, the Claude Code or Cursor binary. Allowlisting decides whether node is permitted to run. It has no opinion about what node loads once it does. WDAC script enforcement and AppLocker script rules do reach past the interpreter, which is how non-allowed PowerShell ends up in Constrained Language Mode, but only for the Windows script hosts they integrate with. None of it applies to node, python or an IDE extension host loading arbitrary JavaScript. The malicious extension, the poisoned package and the counterfeit MCP server all inherit the trust of the process that hosts them, which is exactly why a policy built around binaries never sees them.

The same is true inside Cortex. If you're on Cortex XDR, Host Insights already gives you an application inventory and Behavioral Threat Protection (BTP) already watches process chains, so it's fair to ask what AES adds. Host Insights inventories installed applications and their CVEs, and on macOS it will list system and kernel extensions plus the apps holding Apple's Transparency, Consent, and Control (TCC) framework grants full disk access. What it does not enumerate is IDE extensions, NPM or PIP packages, MCP servers, skills or local models, and it has no extension-level view of what permissions were granted. Asset enrichment does collect browser extensions, and there are shipping analytics alerts for uncommon extension loads, so call that one partial rather than absent. BTP keys on process, file, registry and network behavior, which is the layer these attacks are built to avoid. I'd rather say that plainly here than have an analyst discover it during an incident.

Then there's the network. A shop with Prisma Access or any decrypting secure web gateway plus DLP will tell me they'd catch the exfiltration on the wire, and for a classic data theft they might. The destinations in these campaigns are the problem. Shai-Hulud 2.0 pushed stolen secrets into public GitHub repositories created under a compromised GitHub token. postmark-mcp BCC'd mail through a legitimate email API. An extension shipping source to a storage bucket or a chat webhook is a small, valid TLS session to a trusted SaaS domain under an authenticated user. The May 2026 TeamPCP compromise of Nx Console made the same point harder, the poisoned release for VS Code ran an NPX command that pulled its second stage from the legitimate nrwl/nx GitHub repository, hidden in a parentless orphan commit reachable only by its SHA, then harvested Vault, AWS, GitHub, 1Password, SSH and Kubernetes credentials. Every byte of that traffic went to github.com. There's no signature to fire, no volume anomaly and no untrusted destination. The network sees a developer using developer tools.

Here's the way I've started drawing it for SOC teams. Take one event, an outbound HTTPS connection from a signed IDE process, and look at what each layer records.

You can approximate some of this with the telemetry you already collect, and I'd encourage you to try before you buy anything. File events on ~/.vscode/extensions, ~/.npmrc, pip.conf (pip.ini on Windows), claude_desktop_config.json and .cursor/mcp.json will tell you which machines have agentic tooling and when an MCP server was added. DNS and network events to registry.npmjs.org, pypi.org, marketplace.visualstudio.com and huggingface.co will tell you who installs from where. Child processes of Code.exe or the Cursor binary will show you a shell being spawned. What none of that gives you is intent such as which extension made the call, what permissions it holds, whether its code matches its listing and whether the package it pulled was published an hour ago. Inventory you can hunt for. Risk you can't.

Here's what that looks like as two XQL hunts against xdr_data, scoped to a macOS fleet running Claude Code and ChatGPT, which is the pairing I see most often on developer laptops right now. The first catches the tooling as it lands, Claude Code's settings, skills and plugins under ~/.claude, Claude Desktop's MCP config, Codex CLI under ~/.codex, the ChatGPT desktop app's support directory and any project-level .mcp.json. The second shows you what those agents are spawning underneath such as shells, package managers, osascript and curl, and how often.

// Hunting in macOS: Claude Code, Claude Desktop and ChatGPT/Codex tooling landing on the endpoint
dataset = xdr_data
| filter agent_os_type = ENUM.AGENT_OS_MAC
| filter event_type = ENUM.FILE and event_sub_type in (ENUM.FILE_CREATE_NEW, ENUM.FILE_WRITE)
| filter action_file_path ~= "/Users/[^/]+/\.claude(\.json|/)"
    or action_file_path ~= "/Users/[^/]+/\.codex/"
    or action_file_path ~= "/Users/[^/]+/Library/Application Support/Claude/claude_desktop_config\.json"
    or action_file_path ~= "/Users/[^/]+/Library/Application Support/com\.openai\.(chat|codex)/"
    or action_file_path ~= "/Users/[^/]+/\.mcp\.json"
    or action_file_name in (".npmrc", "pip.conf")
| alter tool = if(action_file_path ~= "/\.claude(\.json|/)", "Claude Code",
                  action_file_path ~= "claude_desktop_config\.json", "Claude Desktop MCP",
                  action_file_path ~= "/\.codex/", "Codex CLI",
                  action_file_path ~= "com\.openai\.(chat|codex)", "ChatGPT desktop",
                  action_file_path ~= "/\.mcp\.json", "Project MCP config",
                  action_file_name in (".npmrc", "pip.conf"), "Registry config", "Other")
| alter what = if(action_file_path ~= "(settings|mcp|config)\.json", "config", action_file_path ~= "/(skills|plugins|commands)/", "skill or plugin", "other")
| fields _time, agent_hostname, actor_effective_username, tool, what, action_file_path, actor_process_image_name
| sort desc _time

Shells, package managers and scripting hosts spawned by Claude Code or ChatGPT.

// Hunting in macOS: shells, package managers and scripting hosts spawned by Claude Code or ChatGPT
dataset = xdr_data
| filter agent_os_type = ENUM.AGENT_OS_MAC
| filter event_type = ENUM.PROCESS and event_sub_type = ENUM.PROCESS_START
| filter actor_process_image_name in ("claude", "codex", "ChatGPT", "node")
    or actor_process_image_path ~= "/Applications/(Claude|ChatGPT)\.app/"
    or causality_actor_process_image_name in ("claude", "codex", "ChatGPT")
| filter action_process_image_name in ("zsh", "bash", "sh", "osascript", "python3", "curl",
                                      "npm", "npx", "pip3", "uv", "uvx", "brew", "git")
| alter agent = if(actor_process_image_name = "claude" or causality_actor_process_image_name = "claude", "Claude Code",
                  actor_process_image_path ~= "/Claude\.app/", "Claude Desktop",
                  actor_process_image_name = "codex" or causality_actor_process_image_name = "codex", "Codex CLI",
                  actor_process_image_name = "ChatGPT" or actor_process_image_path ~= "/ChatGPT\.app/", "ChatGPT desktop", "node (unattributed)")
| comp count() as spawns, count_distinct(action_process_image_command_line) as unique_cmds,
      values(action_process_image_command_line) as sample_cmds
  by agent_hostname, actor_effective_username, agent, action_process_image_name
| sort desc spawns

Run those in your own tenant and you'll have a decent map of which Macs run agents and who is driving them, which is more than most teams have today. Then look at what the results don't contain. The first hunt tells you a file under ~/.claude/skills changed, not what the skill's instructions tell the agent to do. The second tells you claude spawned zsh and ran curl, not whether the developer asked for that or a poisoned skill did, and not which MCP server's tool call led there. You're also inferring tooling from paths, so a new agent with a new dotfile is invisible until someone adds it to the query, and something as small as CODEX_HOME pointing elsewhere takes Codex out of the results entirely, and anything running under a personal ChatGPT or Claude account looks identical to the enterprise one. That gap between the file path and the intent is the whole product.

EDR is the other question, and the short answer is that AES does not replace one. Palo Alto Networks has been explicit that Koi's capabilities stay available as a standalone offering that runs alongside an existing EDR, so a shop standardized on CrowdStrike or Defender can cover the agentic software layer without touching the endpoint stack underneath it. Your EDR keeps watching processes, files and network. AES watches the layer above it. On footprint, Palo Alto Networks describes the standalone path as leveraging the endpoint agents you already have in place and staying invisible to the end user. I

It goes deeper if you're already on Cortex, where AES lands as a module in Cortex XDR and Cortex XSIAM rather than another console. In practice, an AES finding arrives in the same incident flow your analysts already work, on the same endpoint record and the same identity, with context XDR never had on its own such as which agent or extension acted, which MCP server it called and what permissions it was holding when it did. The analyst who used to see an outbound connection from a signed, legitimate process now sees the extension behind it and its risk score sitting next to the alert. That turns a hunt into a triage.

AES's differentiation is the combination. It inventories the categories those tools miss (MCP servers, skills, local models, agentic platforms), scores them with the kind of behavioral and intent analysis SCA tools don't attempt, and enforces at runtime instead of on a scan cycle. It fills the part of the stack none of that tooling was built to see, without replacing what you already have in place.

One product, three doors: standalone, Cortex module, Prisma AIRS

The standalone offering is the first door, and for a lot of shops it will be the one they walk through first. It isn't the whole strategy. AES was already named in Prisma AIRS 3.0 when that platform launched in March 2026, and Palo Alto Networks is positioning AIRS to secure the AI enterprise end to end. Under the Protect stage of AIRS 3.0, Agentic Endpoint Security sits next to Agent Identity Security, Agent Runtime Security and a new AI Agent Gateway. Four vantage points on the same underlying problem, software that reasons, decides and acts without a human confirming any of it.

That structure should look familiar. Discover what's running, assess it before you trust it, protect against what it does at runtime. That's the exact pattern I just walked through for AES on a single endpoint. Prisma AIRS 3.0 applies the same pattern everywhere else an agent shows up such as orchestrating work across cloud and SaaS, running in the browser, and now running on the machine in front of the developer. AES becomes the endpoint leg of a platform trying to see the whole agent rather than the slice of it that happens to live where your EDR was already looking.

Because those pieces share a vendor, the placement questions come fast, and two of them come up in nearly every conversation. The first is Prisma Browser. It already governs extensions inside the managed browser, so why does AES need to care about extensions at all? The answer is scope. Prisma Browser covers what runs in the browser. AES covers the IDE, the agentic platform, the package managers and the MCP servers, which is where the developer half of this problem lives, along with a business user's local AI tooling that never touches a browser tab. The second is Prisma AIRS AI Runtime Security, which already advertises prompt injection protection, so a reader hits the Real-Time Prevention section and assumes it's the same feature with a new label. It isn't. AIRS Runtime protects the agents and AI applications your organization builds and deploys, inline with their traffic. AES protects the agents your employees run on their laptops, at the point where the agent's intent turns into a shell command or a tool call. Same problem, different agent, different vantage point. If you're mapping this to a coverage model, AES is the endpoint leg, Prisma Browser is the browser leg and AIRS Runtime is the application leg.

Govern the platform, not just the perimeter

Agentic AI adoption is outpacing governance almost everywhere I look. The endpoint stopped being a fixed perimeter a while ago, and now it's a living platform that includes autonomous software acting on a user's behalf, whether the security team knows it or not.

That's not a problem you solve at the endpoint alone, and Palo Alto Networks isn't betting the strategy that way. Precision AI is already the proprietary AI system running underneath Cortex, Strata and Prisma Cloud. Prisma AIRS is the control plane trying to govern every agent an enterprise runs, on an endpoint, in a browser, in the cloud, calling another agent three hops away. Cortex Agentic Endpoint Security is where that strategy touches the machine in front of the developer. One piece of a company-wide bet that you secure an AI enterprise by watching how the agent behaves everywhere it operates, instead of hardening the perimeter it used to sit behind.

If you want to compare notes on where AES fits next to the EDR you run today, or talk through what an agent inventory would turn up in your own environment, reach out through your WWT account team

In an upcoming post, I'll get hands-on with the risk engine itself and show what an AES risk score looks like when it fires.