Cortex · Agentic Endpoint Security · Technical Reference
Cortex AES (Koi) —
Technical Deep Dive
Everything a technical seller needs to land and deploy Cortex Agentic Endpoint Security (AES / Koi): discovery, Wings risk scoring, supply-chain gateway prevention, MCP & runtime governance, guardrails, coverage, and the SSL / CSR trust model. Content consolidated from the official Koi FAQ into a single reference that links back to every related PAN Portfolio page.
4
Enforcement Layers
10+
Marketplaces Covered
6
AI Agents Governed
Local
Runtime Enforcement
01 · Overview
What Koi Actually Does
Cortex AES (Koi) governs every self-provisioned piece of software before it reaches your endpoints — extensions, code packages, MCPs, skills, plugins, AI models, and AI agents — plus macOS binaries via Santa. One SaaS platform, one single pane of glass, six pillars of enforcement.
Discovery
A lightweight script package deployed via existing MDM or EDR (Jamf, Intune, Kandji, SCCM, Hexnode, Workspace ONE, FleetDM, CrowdStrike, SentinelOne, Cortex XDR, Tanium) detects marketplace-sourced items on every endpoint — extensions, packages, MCPs, agents, models, and applications — and inventories them centrally.
Risk — Wings AI Engine
Every item is scored on three pillars: publisher identity (reputation, breach exposure), deep composition analysis (vulnerabilities, malicious snippets, exposed secrets, LLM source-code evaluation), and behavioral insights (sensitive API calls, external comms, suspicious runtime patterns). Wings is continuously enriched by Koi research.
Prevention — Supply Chain Gateway
A network proxy routes only marketplace-domain traffic through Koi. Risky components are blocked at download / install time. Integrates with Zscaler ZIA, Palo Alto Prisma Access, Netskope, Cloudflare, Cisco Umbrella, Blue Coat, FortiGate, and any PAC-file-capable network.
Remediation
Automated or admin-triggered removal, executed by the MDM/EDR script package on the next run. Auto-remediation is opt-in and scoped to the Malware Protection and Auto-remediate Delisted guardrails. All other blocking policies surface in Remediation → Open for admin review — preserving productivity while giving you control.
Runtime Hooks — Agent Control
Native runtime hooks in Claude Code, Cursor, Codex CLI, GitHub Copilot CLI, Gemini CLI, and Antigravity CLI observe and gate shell commands, file access, MCP tool calls, skills, and network requests. Enforcement is local — a Koi cloud outage never fails open and never changes what your endpoints permit.
Guardrails
Curated, out-of-the-box protections — Malware Protection, Scan-first, Version Update Cooldown, Delayed Access, Auto-remediate Delisted, Sideloading Monitoring, MCP Registry Enforcement, Block Execution from Risky Paths (Santa), and agent credential / destructive-command restrictions. Every guardrail has alert-only mode, device-group targeting, and a 30-day Impact Check before enabling.
02 · Deployment
Deployment Scenarios
Koi has two integration surfaces — the Endpoint Integration (script package via MDM/EDR) and the Network Integration (gateway routing via SASE/SWG/PAC). Each one delivers value on its own; both together deliver full visibility, prevention, and remediation.
Endpoint Only — Script Package
Scenario A
Fastest to value — leverages your existing MDM or EDR
What it is: The lightweight Koi script deployed to every endpoint via your existing MDM/EDR on a scheduled cadence (recommended: once per hour). No gateway, no network route changes.
Includes
- ✓ Marketplace discovery & inventory
- ✓ Wings risk assessment
- ✓ Manual remediation of installed items
- ✓ Guardrails in detection / remediation mode
Trade-off
- ! No proxy-based prevention at download time
Best For
Pilots, air-gapped orgs, teams without a SASE/SWG in place, or CX-led first-30-day rollouts.
Endpoint + Network — Full Deployment
Recommended
Script package on every endpoint + marketplace traffic through the Koi Supply Chain Gateway
What it is: Complete lifecycle protection. Discovery + risk on the endpoint, prevention at the gateway, remediation via the script.
Adds Over Scenario A
- ✓ Real-time prevention at install / update time
- ✓ Guardrails in full prevention mode
- ✓ Allow / block custom policies at the gateway
- ✓ Developer Request Approval workflow for blocked items
Best For
Any org with Zscaler ZIA, Prisma Access, Netskope, Cloudflare, Umbrella, Blue Coat, FortiGate, or a PAC-file-capable network. See Prisma SASE for the native Palo route.
Network Only — Gateway Only
Scenario C
Prevention at the wire, no endpoint agent
What it is: Marketplace traffic routed through Koi without an endpoint script. Ideal when you can't touch endpoints but can steer network traffic.
Includes
- ✓ Marketplace discovery from network traffic
- ✓ Risk assessment & inventory
- ✓ Prevention (allow / block) at gateway
Trade-offs
- ✗ No endpoint inventory (no hostnames or user attribution)
- ✗ No remediation of already-installed items
Best For
Contractor / BYOD populations where MDM enrollment isn't possible.
Remote Developer Environments
Scenario D
Coder, VS Code Remote SSH, Dev Containers, WSL, JetBrains Gateway
What it is: Coverage for modern developer platform teams whose workloads live off the physical endpoint.
Includes
- ✓ Coder: full deployment — discovery, prevention, remediation
- ✓ Remote SSH via Koi-supported IDEs on a Koi-protected workstation — local policies apply to remote traffic
- ✓ Package managers (pip, npm) on remote hosts — configured to your architecture
Best For
Modern developer platform teams. Engage your account manager for remote-host wiring guides.
Agent Runtime Control
Scenario E
Out-of-the-box hooks for supported AI coding agents
What it is: Governance of what AI coding agents can do — no gateway or script cadence required beyond the endpoint agent.
Includes
- ✓ Claude Code, Cursor, Codex CLI, GitHub Copilot CLI, Gemini CLI, Antigravity CLI
- ✓ Block or Ask on shell commands, file access, MCP tools, skills, network requests
- ✓ Enforcement is local — cloud outage never fails open
- ✓ 30-day Impact Check before enabling any rule
Best For
Agent-forward teams — activate alongside the Endpoint Integration.
Binary Control — macOS Santa
Scenario F
Application control for macOS endpoints
What it is: A Santa configuration profile deployed via MDM, with Koi managing the policy plane.
Includes
- ✓ Real-time block at execution
- ✓ Custom policies and guardrails on binaries
- ✓ Deployed as a Santa configuration profile via MDM
- ✓ End-user notifications + approval workflow
Best For
Regulated orgs and macOS-heavy dev fleets that need application control.
Capability by Integration
Which Capabilities Come with Which Integration?
Use this to right-size the customer's first deployment and to plan the upgrade path from Endpoint-only to Full.
| Capability | Script Package | Network | Both (Full) |
|---|---|---|---|
| Marketplace discovery & inventory | ✓ | ✓ | ✓ |
| Endpoint inventory (hostnames, users) | ✓ | — | ✓ |
| Wings risk assessments & reports | ✓ | ✓ | ✓ |
| Manual remediation | ✓ | — | ✓ |
| Guardrails | Detect / Remediate | Prevention | Full |
| Policies | Alert / Alert + Remediate | Allow / Block | Full |
| Device-group scoping | ✓ | ✓ | ✓ |
| Audit log & APIs | ✓ | ✓ | ✓ |
| Version pinning (VS Code Publish) | Platform-based | Platform-based | ✓ |
03 · Rollout
The Five-Step Rollout
The exact sequence to take a customer from zero to full deployment — and the checkpoints to verify at each stage.
1
Generate Your Script
In Settings → Deployment, pick MDM / EDR, OS, install method (Agentless — leverages your existing MDM/EDR, or Installed — native macOS Launch Daemon / Windows Service), script type, and update mode (Automatic for Managed, or Manual for portal re-download).
2
Deploy to a Small Test Group
Recommended cadence is once per hour. Any MDM/EDR that can run scripts on a schedule works — direct guides are available for Jamf, Intune, Kandji, SCCM, Hexnode, Workspace ONE, Salt, FleetDM, CrowdStrike, SentinelOne, Palo Alto Cortex XDR, and Tanium. If your tool isn't listed, use the Manual deployment mode.
3
Verify Connectivity
In the Deployment portal, look for the Deployed badge and the Running status per script. Confirm inventory is landing before rolling to more devices.
4
Establish Trust for Network Integration
Choose customer-signed CSR (recommended — Koi generates a domain-scoped signing request, you sign with your own org CA) or Koi Root CA (install Koi's root cert in the device / SASE / SWG trust store). This must happen before any routing is configured, or developers will see cert warnings.
5
Establish Route
Route marketplace domains via SASE, SWG, or PAC file. Roll policy scope from the pilot group out to the fleet using device-group scoping. Policies can take up to 60 minutes to propagate; Homebrew prevention is enforced by the endpoint script and takes effect on the next scheduled run.
04 · MCP & SSL
Encrypted Traffic Handling — MCP, CSR, and What Koi Can & Cannot Inspect
The single most common technical objection on Koi deals is: "Are you inspecting all our HTTPS traffic?" The answer is no. Here is the architecture that constrains what Koi can see, backed by both cryptographic controls and routing scope.
Two rails constrain Koi's visibility: the domain-scoped certificate limits what Koi can impersonate, and the customer's PAC / SWG routing rules limit what traffic Koi does inspect. Together they mean SSL inspection credentials cannot be turned into broad internet surveillance.
MCP Identification & Assessment
How Koi understands MCP servers without decrypting the developer's live session
Identification
The Koi endpoint agent reads MCP server configurations from developer tools (Cursor, VS Code, Claude Code, and others) — including remote HTTPS URLs. Koi does not sit in the middle of an active encrypted MCP connection to identify it.
Assessment
- → Local / package-based MCPs (npm, PyPI): standard Wings risk analysis on the underlying package.
- → Remote MCPs: Koi's backend independently connects to discover tools, auth methods, and capabilities — a separate scan, not an interception of the developer's session.
- → Registry-installed MCPs (e.g. GitHub MCP Registry): fetched and assessed through the Supply Chain Gateway when developers browse or install.
Runtime Enforcement
When enabled, Koi intercepts MCP tool invocations at the agent / IDE level (before the action executes) — not by breaking network encryption. A developer's live connection to their configured MCP server (Figma, Slack, etc.) is left untouched.
Known Limit
Remote MCPs that require authentication (API key or OAuth) cannot currently be fully scanned for tool information.
Gateway SSL — Decrypt / Re-Encrypt Model
How the Supply Chain Gateway inspects marketplace HTTPS without triggering cert warnings
When marketplace traffic is routed to Koi (via PAC or SWG), the gateway terminates the encrypted connection on the client side, inspects the traffic to apply policies, then opens a new encrypted connection to the real marketplace on the other side. That's what allows real-time allow / block on installs.
To Avoid Cert Warnings — Establish Trust First
- ✓ Koi Root CA — install Koi's root cert in the device / network trust store via Jamf, Intune, or in the SASE / SWG trust store.
- ✓ Customer-signed cert — Koi provides a signing request scoped to marketplace domains only; you sign with your own org root CA. Devices that already trust that authority accept the gateway's certs automatically.
Pinning
Supported browser and IDE extension stores validate connections through the device's trusted certificate store — not hardcoded pinning — so installing the root CA up front makes inspection transparent for extension traffic. CLI tools with their own bundled cert stores (npm, pip) need separate configuration.
CSR & Private Key Management
Why Koi requires a signed CSR, and how misuse is prevented
Why: Koi requires a signed CSR + private key to inspect SSL-encrypted marketplace traffic in order to identify extensions and packages being accessed or installed. The CSR is domain-scoped — valid only for specific marketplace domains.
Key Handling
When you choose customer-signed, Koi generates a signing request listing only the marketplace domains it protects (Chrome Web Store, VS Code Marketplace, etc.). Koi generates and keeps the matching private key in its own secure, managed cloud infrastructure — never shared with the customer, never installed on endpoints. You sign the request with your org CA and upload the signed certificate through the Deployment Portal. Koi Support applies it to your dedicated gateway.
Controls That Prevent Misuse
- ✓ Domain-limited certificate — cannot present trusted certs for unrelated sites.
- ✓ Routing scope, not full capture — you control which domains are forwarded; all other traffic bypasses the gateway.
- ✓ Customer approval gate — your org CA must sign before Koi can use the cert.
- ✓ Controlled updates — new marketplace domain = new signing request, your re-sign, your re-upload, Koi re-apply. Nothing routes until you approve.
Storage
Credentials in AWS Secrets Manager with strict access controls and encryption. Tenant-partitioned storage across the platform.
What the Proxy Does Not Touch
The IDE and browser behaviors that keep inspection scoped
Two Mechanisms Enforce Scope
- ✓ IDE / browser proxy behavior is limited. IDEs like VS Code route only marketplace-related and IDE-configuration traffic through the configured proxy. Code commits, debugging, API calls all bypass Koi — they don't respect the IDE proxy setting.
- ✓ Controlled scope via CSR. The proxy operates with a CSR that restricts inspection to marketplace domains only. Koi cannot inspect or decrypt data outside those specific marketplace URLs.
Not Inspected
- ✗ Source code & git commits
- ✗ General browsing traffic
- ✗ Any traffic outside the CSR's marketplace domains
TLS is respected end-to-end for anything outside the marketplace scope.
05 · Runtime
Runtime Hooks & AI Agent Control
Runtime protection extends Koi from "what installed" to "what an agent is doing." Five rule types, two enforcement actions, local decisions on the endpoint.
Supported Agents
Full agent hardening & behavior control for Claude Code, Cursor, Codex CLI, GitHub Copilot CLI, Gemini CLI, and Antigravity CLI. Enforcement uses each agent's native runtime hooks — nothing extra to enable.
Five Rule Types
Shell commands · file access · MCP tools · skills · network requests (URLs / IPs). Each rule supports Block (deny outright) or Ask (pause for developer approval). Codex CLI and Gemini CLI run web access through hosted infra, so URL/IP rules are best expressed as shell rules on
curl / wget.Impact Check (30 Days)
Before enabling any runtime policy, the Impact Check shows how many endpoints and actions would have been affected over the last 30 days. Sellers should demo this as the "confidence gate" that turns runtime controls from "risky to enable" into "safe to enable."
Local Enforcement — Never Fails Open
Enforcement decisions are computed locally on the endpoint against policy already on the device. Koi's cloud is never in the decision path — a cloud disruption cannot change what your endpoints permit. This is a critical differentiator against cloud-only agent-governance tools.
What Koi Collects at Runtime
Shell commands the agent runs; file paths the agent reads/writes/deletes (plus the changed content on writes/edits); MCP server + tool invoked; skill invoked; URLs/IPs reached and fetched content; developer prompt text (masked in portal); event context (type, timestamp, agent/model, session, device, hostname, user).
What Koi Deliberately Does Not Collect
Contents of files the agent didn't act on; separate terminal
stdout/stderr streams; activity of anything outside the scoped agent — git, IDE, browser, other apps are all out of scope. Answers most privacy-team objections directly.
MCP-Specific Governance
Koi discovers MCP servers configured in Claude Code, Cursor, VS Code, Codex, Windsurf, and the Claude Connectors marketplace. Wings surfaces MCP-specific findings including Tool Poisoning, Tool Shadowing, Prompt Injection risk, Data Export Capability, and Arbitrary Code Execution. The MCP Registry Enforcement guardrail removes MCP servers installed outside the official GitHub MCP Registry, and the Request Approval workflow is available for the Claude Connectors marketplace and the GitHub MCP Registry.
06 · Coverage
Coverage Matrices
Visibility, risk assessment, remediation, and prevention across the modern software supply chain. Prevention columns require the Network Integration; Remediation columns require the Endpoint Integration.
Visibility, Risk & Remediation
| Component | Agentic Component | Discovery | Risk | Remediation |
|---|---|---|---|---|
| Claude, Claude Code, Cursor, Codex, Kiro, Windsurf, Antigravity | Agents | ✓ | ✓ | ✓ (IDE ext.) |
| MCPs | Agent extensions | ✓ | ✓ | ✓ |
| Skills | Agent extensions | ✓ | — | — |
| Plugins | Agent extensions | ✓ | — | ✓ |
| Hugging Face | AI models | ✓ | ✓ | ✓ |
| Ollama | AI models | ✓ | ✓ | — |
| npm, PyPI | Code packages | ✓ | ✓ | npm malware only |
| Homebrew | OS packages | ✓ | ✓ | ✓ |
| Chocolatey | OS packages | ✓ | ✓ | — |
| VSCode, JetBrains, OpenVSX | IDE extensions | ✓ | ✓ | ✓ |
| Chrome, Firefox, Edge, Prisma, Comet, Dia, ChatGPT Atlas, Arc | Browser extensions | ✓ | ✓ | ✓ |
| Cloned Git repos | Git repos | ✓ | — | — |
| Windows, macOS | Applications | ✓ | — | — |
Prevention (via Network Integration)
| Source | Component | Custom Policies | Guardrails | Enforcement |
|---|---|---|---|---|
| GitHub MCP Registry | Agent extensions — MCPs | ✓ | ✓ | Proxy |
| Claude Desktop Connectors | Agent extensions — MCPs | ✓ | — | Proxy |
| Hugging Face | AI models | ✓ | ✓ | Proxy |
| npm, PyPI | Code packages | ✓ | ✓ | Proxy |
| Homebrew | OS packages | ✓ | ✓ | Endpoint script |
| VSCode, JetBrains, OpenVSX, Cursor, Windsurf | IDE extensions | ✓ | ✓ | Proxy |
| Chrome, Firefox, Edge, Prisma, Comet, Dia, ChatGPT Atlas, Arc | Browser extensions | ✓ | ✓ | Proxy |
Enforcement Layers at a Glance
| Layer | Where | When It Runs | Time-to-Effect |
|---|---|---|---|
| Proxy (marketplace gateway) | Public source | At install / download time | ~1 hour to propagate |
| Script package | Endpoint | On-demand or scheduled | Depends on MDM/EDR cadence |
| Runtime hooks | Endpoint | Real time · AI agent activity | ~1 hour to propagate, then continuous |
| Santa | macOS device | At binary execution | ~1 hour, then continuous |
07 · Guardrails
Out-of-the-Box Protections
Guardrails deliver maximum security with zero operational overhead. Every guardrail is configurable with alert-only mode, endpoint-group targeting, and an Impact Check before enabling.
Malware Protection
Blocks new installs and remediates any non-binary software identified as malicious by Wings. Continuously updated via Koi's Supply Chain Malware Database. This is the highest-value guardrail — position first in every deployment.
Scan-first Protection
Prevents installation of newly published non-binary software until Wings finishes scanning — typically minutes to hours after publication. Kills the "install-in-the-first-hour" attack pattern.
Version Update Cooldown
Delays automatic updates to allow public scrutiny of newly pushed versions. Supported for npm and PyPI. Defends against compromised-maintainer / typo-squatted-version attacks.
Delayed Access
Blocks installs of newly published packages for a configurable minimum period so they can establish reputation before rolling into production endpoints.
Auto-remediate Delisted
Automatically removes items delisted or pulled from the marketplace — reducing exposure to abandoned or pulled software that will never receive another security update.
Sideloading Monitoring
Detects unauthorized sideloading of items outside official marketplaces — the primary blind spot of gateway-only supply-chain controls.
MCP Registry Enforcement
Removes MCP servers installed outside the official GitHub MCP Registry. The single fastest way to shrink MCP attack surface in an agent-forward org.
Block Execution from Risky Paths
Blocks execution of binaries from user-writable paths like
/tmp, /var/tmp, $TMPDIR, and /Users/Shared/. macOS via Santa.Agent Credential Access Restriction
Prevents AI agents from reading sensitive files that store credentials and secrets.
Agent Destructive Command Restriction
Prevents AI agents from performing destructive commands (
rm -rf classes, force pushes, etc.).08 · Security
Product Security & Data Handling
Everything the customer's InfoSec / privacy team asks — in one page, with the cryptographic and routing controls that make each answer enforceable.
Data Collected
Everything endpoints send Koi
- ✓ Item inventory (ID, name, version)
- ✓ Machine / hostname & OS type
- ✓ Logged-in username (for reporting)
- ✓ Agent runtime events (when Runtime Protection is on)
No sensitive user data is collected. Most extension metadata is public.
Encryption & Storage
In transit and at rest
- ✓ TLS 1.2+ in transit
- ✓ AES-256 at rest
- ✓ AWS Secrets Manager for SSL credentials
- ✓ Tenant-partitioned storage & APIs
Tenant isolation is enforced on the endpoint (every runtime event is tagged with the tenant ID) and in storage (tenant-partitioned) — the portal and API are authenticated and scoped to the tenant.
What Koi Does Not See
The hard limits, backed by CSR scope
- ✗ Source code & git commits
- ✗ General browsing traffic
- ✗ Contents of files the agent didn't act on
- ✗ Any traffic outside the CSR's marketplace domains
TLS is respected end-to-end for anything outside the marketplace scope.
Customer Controls
The kill-switches the customer holds directly
- ✓ Customer-signed CSR restricts what Koi can inspect
- ✓ PAC / SWG rules restrict what Koi does inspect
- ✓ Enforcement decisions computed locally on the endpoint
- ✓ Every policy exclusion audit-logged with approver + justification
- ✓ SSO via Okta & SAML with JIT provisioning; Entra ID for end-user email notifications
SIEM Integration — Webhooks + APIs
Koi is API-first: risk analysis, rescan triggers, remediation actions, allow/block requests, alerts, audit logs, Search Inventory (nested AND/OR filters mirroring the UI query builder), and the asynchronous Reports API (POST → poll → presigned 12-hour download URL). Combine Webhooks (event forwarding) with the Reports API for continuous SIEM ingest into Splunk, XSIAM, or your SIEM of choice. See the XSIAM page for the Palo-native destination.
09 · Sales Conversations
Discovery Questions for Sellers
A mix of technical and business questions. Goal: surface the agent-forward reality of the customer's dev org, the supply-chain blind spot in their existing controls, and the InfoSec / privacy questions the CSR model already answers. Companion page: AES Conversation Starters — nineteen questions with expected answers, how to read them, the response to give, and the control-gap truth table.
01
How many of your developers are actively using AI coding agents today — Claude Code, Cursor, Codex CLI, Copilot CLI, Gemini CLI? What controls are in place on what those agents can execute or exfiltrate?
02
Do you have an inventory of MCP servers installed across your dev fleet — and could you tell me right now whether any of them came from outside the official GitHub MCP Registry?
03
When a new npm or PyPI package is published, how long does it take before your developers can install it? Do you have a cooldown or scan-first control, or does the first developer to install it also become the first target?
04
If a browser or IDE extension gets pulled from its marketplace for malicious behavior, what removes it from your fleet? Is there any auto-remediation path today, or does someone open a ticket?
05
Do you have an MDM or EDR that can run scripts on a scheduled cadence — Jamf, Intune, Kandji, SCCM, Workspace ONE, CrowdStrike, SentinelOne, Cortex XDR? What's the fastest way to add another hourly script?
06
Do you route web traffic through a SASE / SWG today — Prisma Access, Zscaler, Netskope, Cloudflare, Umbrella? Would routing only marketplace domains through a domain-scoped proxy be a viable change for your network team?
07
What is your InfoSec team's biggest concern about installing another root CA, or about SSL inspection scope? Would a customer-signed, domain-scoped CSR — where you hold the CA and Koi's cert cannot be used on anything outside a fixed marketplace domain list — change that conversation?
08
If a Koi-style cloud service had an outage, what should happen to your endpoint controls? Would you accept a cloud-dependent decision path, or do you need enforcement computed locally on the device?
09
Which developer populations are the hardest to reach with endpoint tooling — contractors, remote devs, Coder / VS Code Remote SSH / WSL users? What would coverage there change about your risk picture?
10
If I could show you a single platform that inventories every extension, package, MCP, model, and AI agent across your fleet — scores them with a research-driven risk engine — blocks new risky installs at the wire — and can gate what agents actually do at runtime, all without inspecting your source code or your general internet traffic — what would that change about how you govern the modern dev supply chain?
Continue Your AES / Koi Research
Every related page across the PAN Portfolio site — product overview, compete positioning, adjacent Cortex platforms, and the Palo-native network integration surface.