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.

Gregori Nazarovsky· CTO — QMasters· 2026-07-20
TL;DR

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 seven-layer architecture — prompt flow down through endpoint, MCP, gateway, cloud, and model layers, with the CrowdStrike policy engine enforcing at the center
The AIDR seven-layer architecture — prompt flow down through endpoint, MCP, gateway, cloud, and model layers, with the CrowdStrike policy engine enforcing at the center

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.

The seven-layer AIDR protection map — a prompt flows down through endpoint tools, MCP, gateway, and cloud layers to the model, and the response flows back up, with the CrowdStrike policy engine enforcing at the center

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:

ActionWhat it doesExample
AllowPass the content through unchangedA routine, clean prompt
BlockStop the prompt or response entirelyA detected prompt-injection payload
TransformRedact, mask, or encrypt in placeStrip an AWS key before it reaches the model
LogRecord for audit and correlationStream the interaction to Next-Gen SIEM
ExcludeDrop sensitive prompt content from recordsKeep regulated data out of logs for privacy

Underneath those actions sits a catalog of detectors that inspect both the input and the output:

DetectorCatchesDirection
Malicious PromptPrompt injection, jailbreaksInput + Output
Malicious EntityBad IPs, URLs (threat-intel backed)Input + Output
PII EntitySSN, credit card, email, phone, IPInput + Output
Secret & KeyAWS keys, API keys, tokens, passwordsInput + Output
MCP ValidationTool poisoning, duplicate/malicious toolsInput
Code / TopicSource code, off-limits subjectsInput + Output
Emoji SmugglingPayloads hidden in Unicode modifiersInput + Output
Competitors / CustomOrg-specific sensitive termsInput + 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.

CollectorLayerProtectsStatus
Browser extension2Workforce AI use — ChatGPT, Gemini, M365 Copilot, DeepSeek, PerplexityGA (Chrome, Edge, Firefox)
Application SDK2–3Homegrown AI apps — Python, TypeScript, Go, OpenAI-compatibleGA
MCP proxy3Agent tool traffic — tool poisoning, MCP validationGA
Gateway collectors4Centralized AI traffic — Kong, Apigee, Azure APIM, LiteLLM, Portkey, TrueFoundryGA
Copilot Studio6Custom Microsoft Copilot agentsGA
Container Sensor6Kubernetes AI workloads (OpenAI-compatible), prompt-layer inspectionGA (detection)
Cloud / OTel6AWS Bedrock, Azure OpenAI, OpenTelemetry standardMonitoring

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.

Michael Sentonas, President of CrowdStrike: Security built for static applications cannot keep up with autonomous systems. Organizations need real-time visibility and control over AI behavior wherever it runs. CrowdStrike is that new standard.

That single sentence explains the gap in the comparison below:

CapabilityAIDRNetwork DLPAI-Specific AgentCASB / 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:

  1. 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.
  2. 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.
  3. Inventory before you enforce. Run AI Discovery to see the shadow-AI estate — local models, extensions, MCP configs — before writing a single policy.
  4. 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.
  5. 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.

Talk to a security expert →

References

  1. CrowdStrike, AIDR: Defining the Next Era of Cybersecurity (white paper, 2026); Falcon AI Detection and Response data sheet.
  2. CrowdStrike, Establishes the Endpoint as the Epicenter for AI Security (press release, 2026).
  3. CrowdStrike, Falcon AIDR Detects Threats at the Prompt Layer in Kubernetes AI Apps (blog, 2026).
  4. NVD / GitHub Advisory, CVE-2025-59536 — Claude Code code execution before trust confirmation (CVSS 4.0 base 8.7); fixed in 1.0.111.
  5. Anthropic, Claude Mythos Preview announcement, 7 April 2026; UK AISI evaluation of Claude Mythos Preview.
  6. 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.

ABOUT THE AUTHOR

Gregori Nazarovsky
CTO — QMasters

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.

READY TO TUNE YOUR SIEM?

Tighter detections, fewer false positives.

Book a working session with a senior detection engineer. Bring a sample of your noisiest alerts and we will rebuild the rule with you.

Explore Managed Detection & Response

F-003 · CONSULTATION

Book 30 minutes. No slides.

A real working session with a SOC engineer — bring your alerts.