AI & DETECTION · 11 MIN
The AIDR Architecture: A Protection Map for Enterprise AI
How CrowdStrike AIDR inspects AI traffic across seven layers — the collector map, the Layer 5 policy engine, and the roadmap. A practitioner walkthrough.
How does the CrowdStrike AIDR architecture inspect AI traffic across the enterprise?
CrowdStrike AIDR inspects AI traffic along the path a prompt actually travels: down through seven layers from the user's endpoint to the model, then back up through the same layers as a response. A collector sits at each layer — browser, IDE, MCP proxy, AI gateway, cloud and container — and every intercepted prompt and response passes through one policy engine that can allow, block, transform, log, or exclude it before it reaches the model or the user.

The AIDR Architecture: A Protection Map for Enterprise AI
If you have already accepted that AI agents need runtime security — that the risk is the agent, not the prompt — the next question is mechanical. Where, exactly, does the inspection happen? A prompt typed into a browser, a tool call fired by Claude Code, a request routed through an internal AI gateway, and a Copilot action inside Microsoft 365 travel completely different paths. Securing "AI" means securing all of them.
CrowdStrike AIDR inspects AI traffic along the path a prompt actually travels: down through seven layers from the user's endpoint to the model, then back up through the same layers as a response. A collector sits at each layer. Every intercepted prompt and response passes through one policy engine that can allow, block, transform, log, or exclude it before it reaches the model — or before the answer reaches the user.
This post is the map. If you want the case for why the category exists, start with AIDR explained for CISOs; if you want the hands-on mechanics of three specific collectors, see deploying AIDR across Claude Code, MCP, and the browser. Here, we follow one prompt through the whole stack.

Figure 1 — The AIDR protection map. A prompt travels down through the seven layers to reach the model; the response returns up the same path, inspected at each one, with enforcement at the policy engine in the middle. (These are traffic-path layers — distinct from the seven-layer AI estate taxonomy in AIDR explained for CISOs.)
Follow one prompt through the stack
Read the map top to bottom and it tells a story in two directions.
Layer 1 — the user endpoint. Everything starts here: an employee at a workstation, or an autonomous agent running under that employee's session. This is where AI executes, and it is the layer network tools never see clearly.
Layer 2 — endpoint AI tools. The prompt enters through one of many front doors: a browser tab (ChatGPT, Gemini, M365 Copilot), an IDE extension (Cursor, VS Code), a desktop agent (Claude, OpenClaw), a CLI tool (Claude Code, Aider), a local model (Ollama, LM Studio), or an AI SDK baked into homegrown software.
Layer 3 — MCP and agentic. If the tool is agentic, the prompt now fans out into tool calls. The Model Context Protocol connects the agent to filesystems, databases, and APIs — often configured locally, with no organizational oversight. Every MCP server is a door, and the supply chain behind it (npm, pip, community skill registries) is a way in.
Layer 4 — the AI gateway. In mature environments, traffic is centralized through a gateway — Kong, Apigee, Azure APIM, LiteLLM, Portkey. This is a natural inspection point for anything that routes through it, and AIDR ships a collector for each.
Layer 5 — the AIDR policy engine. This is the center of the map. Whatever collector intercepted the prompt routes it here, to a single detection core, before it continues to the model. We come back to this layer in detail below, because it is where enforcement actually happens.
Layer 6 — cloud, SaaS, and containers. For SaaS-native AI — M365 Copilot, Copilot Studio, Salesforce Agentforce, ServiceNow AI, containerized AI apps in Kubernetes — the prompt reaches the AI service running in someone else's environment.
Layer 7 — the model. GPT-4o, Claude, Gemini, Llama, DeepSeek, Mistral. The prompt finally hits the model, which generates a response.
Then the whole thing runs in reverse. The response flows back up — layer 7 to layer 1 — and AIDR inspects it again on the way out. A model that has been jailbroken into leaking secrets, or manipulated into returning a malicious URL, gets caught on the return trip before the answer is ever displayed.
The QMasters take: most "AI security" conversations fixate on the prompt going in. Half the risk is in the response coming back. An architecture that only inspects one direction is doing half the job.
The four things the map has to stop
The layers exist because the threats live at different points on the path. Four matter most, and each lands on a specific layer:
- Shadow AI (Layers 1–2). Employees install local models, browser extensions, and autonomous agents with no approval, no policy, and no visibility for the security team. You cannot govern what you cannot see.
- Prompt injection (Layers 2–3). Malicious instructions hidden inside a document, a code file, or a web page. The agent reads them as commands and acts — silently, with the user's privileges. Every agentic tool is exposed to it.
- MCP supply chain (Layer 3). Researchers have already found malicious MCP servers and poisoned packages. One compromised dependency can reach thousands of organizations. The endpoint is the last line of defense.
- Data leakage (Layers 2, 6). Source code, keys, and sensitive documents pasted into ChatGPT or Claude — where they may be retained, used for training, or exposed later.
This isn't hypothetical, and the scale is already large: CrowdStrike's own telemetry identifies more than 1,800 distinct AI applications running across roughly 160 million unique instances on enterprise endpoints — most of it adopted with no security review. Even the agents themselves carry vulnerabilities: CVE-2025-59536, a CVSS 8.7 flaw in Claude Code, allowed code execution before the trust dialog even appeared.
Where enforcement happens: the Layer 5 policy engine
Every collector on the map is a sensor. The policy engine is the muscle. Whatever surface a prompt came from, it converges here — and the engine applies one of five actions:
| Action | What it does | Example |
|---|---|---|
| Allow | Pass the content through unchanged | A routine, clean prompt |
| Block | Stop the prompt or response entirely | A detected prompt-injection payload |
| Transform | Redact, mask, or encrypt in place | Strip an AWS key before it reaches the model |
| Log | Record for audit and correlation | Stream the interaction to Next-Gen SIEM |
| Exclude | Drop sensitive prompt content from records | Keep regulated data out of logs for privacy |
Underneath those actions sits a catalog of detectors that inspect both the input and the output:
| Detector | Catches | Direction |
|---|---|---|
| Malicious Prompt | Prompt injection, jailbreaks | Input + Output |
| Malicious Entity | Bad IPs, URLs (threat-intel backed) | Input + Output |
| PII Entity | SSN, credit card, email, phone, IP | Input + Output |
| Secret & Key | AWS keys, API keys, tokens, passwords | Input + Output |
| MCP Validation | Tool poisoning, duplicate/malicious tools | Input |
| Code / Topic | Source code, off-limits subjects | Input + Output |
| Emoji Smuggling | Payloads hidden in Unicode modifiers | Input + Output |
| Competitors / Custom | Org-specific sensitive terms | Input + Output |
On top of detection, Access Rules decide who gets to use what — by user, model, application, token count, department, or directory group — so governance policy becomes something enforced at runtime, not written in a PDF.
The collector map: one line per surface
The reason AIDR can inspect at every layer is that it ships a purpose-built collector for each. This is the breadth the architecture depends on — and the part that is easy to underestimate.
| Collector | Layer | Protects | Status |
|---|---|---|---|
| Browser extension | 2 | Workforce AI use — ChatGPT, Gemini, M365 Copilot, DeepSeek, Perplexity | GA (Chrome, Edge, Firefox) |
| Application SDK | 2–3 | Homegrown AI apps — Python, TypeScript, Go, OpenAI-compatible | GA |
| MCP proxy | 3 | Agent tool traffic — tool poisoning, MCP validation | GA |
| Gateway collectors | 4 | Centralized AI traffic — Kong, Apigee, Azure APIM, LiteLLM, Portkey, TrueFoundry | GA |
| Copilot Studio | 6 | Custom Microsoft Copilot agents | GA |
| Container Sensor | 6 | Kubernetes AI workloads (OpenAI-compatible), prompt-layer inspection | GA (detection) |
| Cloud / OTel | 6 | AWS Bedrock, Azure OpenAI, OpenTelemetry standard | Monitoring |
Alongside the collectors, Falcon for IT AI Discovery & Governance inventories the AI estate itself — dozens of AI application signatures, IDE-extension detection, local-model discovery (including country-of-origin mapping for models like DeepSeek and Mistral), AI SDK dependency scanning, and MCP configuration scans across common AI tools. It can quarantine a tool reversibly, remove one entirely, or enforce an MCP configuration.
For the deployment mechanics of the browser, MCP-proxy, and Claude Code collectors specifically — what each one sees and what it cannot — we walked through the whole process in deploying AIDR across Claude Code, MCP, and the browser.
Why network- and app-layer tools miss this
It is worth being precise about why the incumbent tooling cannot simply extend into this space. CrowdStrike's own framing puts it plainly:
Network-layer controls cannot see these actions because they never cross a network boundary. Application-layer controls cannot distinguish them because the AI agent inherits the user's full context and privilege.

That single sentence explains the gap in the comparison below:
| Capability | AIDR | Network DLP | AI-Specific Agent | CASB / SWG |
|---|---|---|---|---|
| Prompt-injection detection | ✓ | ✗ | ~ | ✗ |
| Block malicious agent commands | ✓ | ✗ | ~ | ✗ |
| Supply-chain (MCP) prevention | ✓ | ✗ | ✗ | ✗ |
| MCP server discovery | ✓ | ✗ | ~ | ✗ |
| Process-tree analysis | ✓ | ✗ | ~ | ✗ |
| Kernel-level visibility | ✓ | ✗ | ~ | ✗ |
| Container / K8s AI monitoring | ✓ | ✗ | ✗ | ✗ |
| No separate agent to deploy | ✓ | ✓ | ✗ | ✓ |
| Enterprise scale | ✓ | ✓ | ✗ | ✓ |
The point of the table isn't that adjacent tools are useless — it's that they were built for a boundary the AI traffic doesn't cross. Standalone AI-security startups get closer, but pay for it with a new agent to deploy and no decade of endpoint telemetry behind them.
The road ahead: what's shipping, what's announced, where it's going
AIDR is expanding fast, and as a CrowdStrike Elite Partner our discipline on any vendor roadmap is fixed: buy on what's generally available, plan on what's announced, and watch the stated direction. Three buckets, no invented dates — CrowdStrike has published capabilities, not a calendar.
Roadmap items below are CrowdStrike's announced intentions, in development and subject to change. The advice attached to each is ours.
Shipping today — buy on this
The full collector map from the section above: browser, SDK, MCP-proxy and gateway collectors; the Falcon Container Sensor for Kubernetes AI workloads; AI Discovery & Governance; the Copilot Studio collector; Access Rules; and the detector catalog including emoji-smuggling and secret detection.
For your rollout: this is what a proof of value runs on. Everything below is planning input, not something to buy today.
Announced and in development — plan on this
In March 2026 CrowdStrike publicly announced the next wave, centred on moving inspection into the sensor itself:
- AIDR for Endpoint — sensor-native (kernel-level) inspection of prompt and response content, with no separate proxy or gateway in the path. This is the architectural pivot: the same Falcon sensor already on the endpoint becomes the checkpoint. (Your architecture diagram labels this coming capability "CNI"; CrowdStrike's public name for the endpoint capability is AIDR for Endpoint.)
- Shadow AI discovery for endpoint and cloud, and Shadow SaaS & AI-agent discovery — extending the inventory beyond what the collectors see today.
- AIDR for Cloud and AI data-flow discovery for cloud — deepening the cloud plane.
- Agent-framework and AI-credential detection — recognising AutoGen, CrewAI and LangGraph deployments, and the credentials agents carry.
For your rollout: if Falcon is already deployed, AIDR for Endpoint is the item to sequence against your AI-adoption curve — it adds a checkpoint at the one hop that costs you no new agent.
Stated direction — watch this
CrowdStrike's longer-range signalling points at agentic security operations orchestrated by Charlotte AI, cross-domain correlation that ties AI events to identity, endpoint and cloud telemetry, protection against next-generation model abuse, and eventual platform unification.
For your rollout: nothing here is a purchase decision yet. It's the reason to standardise on a platform whose telemetry already spans those domains, rather than stitching point tools you'll have to unpick later.
Why the direction matters more than usual
Defensive roadmaps normally race attacker capability in the abstract. This one has a date on it. In April 2026 Anthropic announced Claude Mythos — a model that autonomously discovers and exploits zero-day vulnerabilities, reproducing working exploits on the first attempt in over 83% of tested cases, including a 27-year-old flaw in OpenBSD. In defenders' hands that is extraordinary. The moment equivalent capability reaches attackers, the volume and speed of novel exploitation changes the threat model outright — which is exactly why runtime AI defence is being built now, ahead of the incidents rather than after them.
What to do with this map
The value of an architecture diagram is that you can hold your own environment against it. Five moves:
- Trace your real paths. For each way AI enters your org — browser, IDE, gateway, SaaS Copilot, homegrown app — identify which layer it hits first and whether anything inspects it there.
- Find the uncovered layers. Most organizations have a gateway story and nothing at the endpoint, or vice versa. The gaps are where the incidents will come from.
- Inventory before you enforce. Run AI Discovery to see the shadow-AI estate — local models, extensions, MCP configs — before writing a single policy.
- Pick one enforcement path and prove it. Choose a high-risk flow (secrets into a public model is a good first target) and confirm you can transform or block it at runtime.
- Map the roadmap to your adoption curve. If Falcon is already deployed, the endpoint layers cost you no new agent. Sequence AIDR for Endpoint against where your AI usage is actually growing.
Talk to us about an AIDR proof of value
QMasters is a CrowdStrike Elite Partner. We run StrongHold MCSS for our enterprise security customers and we deployed these collectors across our own fleet before recommending them to anyone. If you want to see this map drawn over your environment — which layers are covered, which are exposed — start with a shadow-AI discovery assessment, then scope a Falcon AIDR proof of value on real workloads.
References
- CrowdStrike, AIDR: Defining the Next Era of Cybersecurity (white paper, 2026); Falcon AI Detection and Response data sheet.
- CrowdStrike, Establishes the Endpoint as the Epicenter for AI Security (press release, 2026).
- CrowdStrike, Falcon AIDR Detects Threats at the Prompt Layer in Kubernetes AI Apps (blog, 2026).
- NVD / GitHub Advisory, CVE-2025-59536 — Claude Code code execution before trust confirmation (CVSS 4.0 base 8.7); fixed in 1.0.111.
- Anthropic, Claude Mythos Preview announcement, 7 April 2026; UK AISI evaluation of Claude Mythos Preview.
- AIDR product documentation, aidr-docs.crowdstrike.com (collectors, detectors, access rules).
---
Author · Gregori Nazarovsky, CTO — QMasters
Last updated · 2026-07-20
FAQ
Frequently asked questions.
In traffic-flow terms they are: the user endpoint, endpoint AI tools (browser, IDE, CLI, local models), the MCP and agentic layer, the AI gateway, the AIDR policy engine, cloud and SaaS AI, and the model itself. A prompt flows down through them to the model; the response flows back up the same path, and AIDR can inspect at every step.
At the policy engine layer. Every collector routes the prompt and response through one detection core that applies five actions — allow, block, transform (redact or encrypt), log, or exclude — before the content reaches the model or is shown to the user.
Browser extension (Chrome, Edge, Firefox), application SDKs (Python, TypeScript, Go, OpenAI-compatible), an MCP proxy collector, AI gateway collectors (Kong, Apigee, Azure APIM, LiteLLM, Portkey, TrueFoundry), a Copilot Studio collector, cloud and OpenTelemetry collectors, and a Falcon Container Sensor collector for Kubernetes AI workloads.
Agent actions on the endpoint frequently never cross a network boundary, so network-layer tools cannot see them. And because the AI agent inherits the user's full context and privileges, application-layer controls cannot tell a malicious action from a legitimate one. AIDR inspects at the AI interaction layer instead.
AIDR for Endpoint is CrowdStrike's announced capability for the Falcon sensor to inspect AI prompt and response content itself, at the kernel level, without a separate proxy or gateway. It was announced in March 2026 and is on the roadmap rather than generally available across the board today.
ABOUT THE AUTHOR
Practitioners from the QMasters Security Operations Center. We run 24/7 monitoring, detection engineering, and incident response for organisations across regulated industries — and write here from the offense and defense work in front of us.