AI, CrowdStrike MCP, and RTR: Real-Time Incident Response Across 100+ Machines

AI, CrowdStrike MCP, and RTR: Real-Time Incident Response Across 100+ Machines

It's 02:00. A detection fires, then another, and the pattern says this isn't one box — it's spreading across a fleet of more than a hundred machines. The first real decision isn't technical. It's which hosts do we pull evidence from, right now, before the picture changes. In our incident-response practice, an AI now drafts that host list in minutes — ranked by shared hashes, parent processes, and identity overlap — and the IR lead edits it before a single command runs. Then, and only then, the collection goes out.

AI-assisted incident response with CrowdStrike combines two deliberately separate channels. The Model Context Protocol (MCP) — via CrowdStrike's official open-source falcon-mcp server — gives an AI model read-only access to Falcon telemetry: detections, incidents, hosts, and threat intelligence. Real Time Response (RTR) is Falcon's state-changing capability: a remote session on the endpoint that can run commands, retrieve files, and execute scripts. In a sound architecture, the AI investigates and plans through MCP, a human authorizes every RTR action, and hardened orchestration code executes the collection across the fleet. The AI never holds the shell.

RTR is part of the CrowdStrike Falcon platform. Logo via Wikimedia Commons (public domain; CrowdStrike is a registered trademark of CrowdStrike, Inc.).

Eyes, Hands, and Two Clocks

The one-line version is "MCP gives the AI eyes; RTR gives the operation hands." The important correction: the hands are not the AI's hands. We run three planes, and they don't touch each other by accident — they can't:

• Read plane — falcon-mcp, with a read-only API client, one per tenant. The AI can see detections, incidents, hosts, and intel. Its credential physically lacks the scope to open an RTR session.
• Decision plane — a named human. Every collection wave is one person's recorded decision, against a host list small enough to actually read.
• Execution plane — a versioned, reviewed PowerShell orchestrator (we use one built on CrowdStrike's PSFalcon). The AI does not compose the commands that run on endpoints. It selects and scopes a pre-built, reviewed collection operation.

That separation is the whole thesis, so let me state it plainly: policy lives in the OAuth scope, not in the prompt. This is the difference between a safety architecture and a safety promise. A read-only token can't be talked into running a shell command, no matter what an attacker slips into a log line.

So where does the AI actually help, versus a skilled analyst driving PSFalcon by hand? Not typing speed. Four places:

1. Parallel attention. A human reasons deeply about a handful of hosts at a time. The AI holds the whole fleet's detection context, host state, and collection status at once — and keeps it coherent at hour fourteen, when human working memory has long since frayed.
2. Scoping quality. "Which hosts do we collect from" moves from tribal guesswork to an evidence-ranked candidate list produced in minutes — and edited by the IR lead before anything runs.
3. Elastic interrogation. Arbitrary questions against fleet and evidence state, without pre-built dashboards or one-off scripts.
4. Synthesis. Cross-host correlation over parsed artifacts, a working timeline, and a first draft of the 06:00 client update.

And the honest limiter — the two clocks. An incident runs on a machine clock (bytes moving, sessions polling, archives uploading — physics you cannot compress) and a human clock (scoping, deciding, synthesizing, communicating). AI compresses only the human clock. The real claim isn't "minutes instead of days." It's that the human-clock work now runs alongside the collection instead of after it.

The Four Ways We Use It — Ask, Investigate, Summarize, Trend

This is the same four-verb structure from Part 1 of this series, now at incident-response scale.

Ask

First-hour scoping, in plain language, against the read-only MCP. "Which hosts saw this hash in the last seven days?" "Of those, which are servers, which are online now, which are in reduced-functionality mode?" For us as an MSSP, the AI asks these per tenant using member-CID scoping — the same question, isolated to each client's data, with no credential swapping. That isolation is a feature, not a footnote.

Investigate

Investigation is a pivot chain the AI is very good at not losing branches of: detection → process tree → host → sibling hosts with the same parent or hash → intel context. When that chain justifies pulling evidence, a human authorizes the collection — and investigation continues off the endpoint, over parsed artifacts. We never re-enter the box to analyze it. The analysis runs on derivatives: event logs, execution artifacts, persistence locations, scheduled tasks, services, autoruns — the artifact families our collector actually gathers.

Summarize

Three different jobs live under this word, and separating them is what operational maturity looks like:

• Operation status from the orchestrator's own logs — collected, offline-queued, failed readiness check, low disk; here's the retry list.
• Evidence synthesis — every conclusion cited back to specific artifacts on specific hosts. "The same scheduled-task name on four hosts" must point at four files. No unsourced findings.
• Communications drafts — executive and client updates, always human-reviewed before they're sent.

Trend

Scoped honestly to two things: trends in Falcon telemetry (recurring initial-access patterns, detections that historically precede real incidents) and trends in our own IR machinery (collection success rates, the long tail of never-online hosts, time from authorization to artifact-in-hand). We do not frame this as "the AI discovers novel attacker techniques." It doesn't. It removes the friction between a question and the data that answers it — and, for our MSSP clients, it stays strictly per-tenant, with no cross-client pooling.

MCP's client–server shape: one read-only server per Falcon tenant. Diagram via Wikimedia Commons (CC BY-SA).

What 100+ Machines and 100GB Actually Look Like

This is the part practitioners read to decide whether the author has done it. The scale is a logistics problem before it's an AI problem, and the details are where naive implementations die.

RTR sessions are ephemeral, and a single command's runtime is capped (today, on the order of a few minutes — verify the current ceiling against CrowdStrike's docs). A deep triage collection takes far longer than that. So the collection can never run inside the session. Our collector detaches: the RTR session's only job is to light the fuse — launch the collector as a background process on the host — and get out in seconds. On a domain controller, a ten-day Windows Security log alone can run to several gigabytes; that work has to outlive the session, or it fails every time.

Readiness is a polling contract, not a held connection. The collector writes a completion marker and a manifest on the host. The orchestrator polls for that marker with cheap, short sessions — present means ready to retrieve; still absent past a deadline is how we detect a crash or hang. Holding sessions open across a hundred hosts is exactly how you fall over.

Retrieval is a two-hop, cloud-queued transfer. get moves the archive from endpoint to the CrowdStrike cloud; then we download it. The platform reports a SHA256 for the retrieved file, so we verify integrity at both hops — the archive is hashed on the host at creation, and again after download. Two hops, two hash checks.

A batch is not a transaction. Fan-out across a host list means every host is its own state machine, and our failure taxonomy is explicit: offline (queued for later), low disk, session-init failure (a sensor in reduced-functionality mode), mid-collection failure, retrieval failure, hash mismatch. Re-runs are idempotent — keyed on run ID plus host ID, so already-collected hosts are skipped. In one recent engagement this held up across 41 Windows hosts and 22 Linux nodes in a single sweep, including domain controllers with multi-gigabyte log sets; a few hosts landed in the failure buckets by design, and the re-run picked up exactly those. One honestly-handled failure is worth ten capability claims.

100GB is disk and bandwidth, not magic. On the endpoint: check free space before staging an archive (a triage zip that fills a production server's disk is an incident you caused), and run in waves to spare live workloads. On the analyst side: storage for the archives, bounded-parallelism downloads, hash verification after each, and constrained branch-office links stretching the tail for days. The orchestrator is deliberately lean — small, staged, and boring — precisely because it sits on the critical path and the AI deliberately does not.

The Governance We Commit To

Because RTR executes on endpoints, this section is the point of the whole post. These are commitments, in order of importance.

1. Structural read/execute separation. The AI's credential is read-only and cannot open an RTR session. Execution uses a separate credential with RTR scopes that never appears in the AI's context or environment. Even a fully compromised AI context ends at a proposal — that is the designed ceiling on blast radius.
2. Least privilege inside RTR itself. CrowdStrike's RTR roles are tiered — read-only, active responder, and administrator (RTR vs. RTR Admin in the API). Even CrowdStrike's own Falcon MCP RTR module draws the line in the same place: it's capped at read-only commands — ls, ps, cat, filehash, reg, single-host — and the docs state it "does not expose admin or remediation commands." Our orchestrator's credential is mapped to the minimum tier that can run our signed, pre-staged collector, and nothing more — no ad-hoc script upload mid-incident without review.
3. Human authorization per operation, not standing. Every wave records who approved, the exact host list, the script version, a timestamp, and the rationale. Canary first — a few hosts, verify, then the fleet — with bounded wave sizes and an abort path.
4. *Prompt injection from both surfaces. Telemetry is attacker-authored: process names, command lines, and file paths flow through MCP into the model's context. And here's the sharp one most coverage misses — when you pull 100GB off attacker-controlled machines and feed parsed content to an AI, the attacker gets a message into your analyst's assistant. Our mitigations: treat all observed content as data, never instructions; run deterministic parsers that normalize artifacts before the AI sees them; never let AI output flow into the orchestrator's input automatically; and rely on the scope separation above to keep any hijack non-catastrophic. Injection is bounded and mitigated* here — not "solved."
5. Chain of custody. SHA256 manifest computed on-host at collection time with UTC timestamps and the collector version; re-verified after the cloud hop and after download; originals to immutable storage; the AI works only on copies and parsed derivatives. Falcon logs every RTR command cloud-side — we treat that audit trail as a feature. And an honesty note DFIR readers will respect: RTR triage is live response, not a forensic image. It perturbs the endpoint by running. We document exactly what the collector touches, so it's defensible, and we never mutate beyond that documented footprint.
6. Three logs that must reconcile: Falcon's RTR audit log, the orchestrator's run log (hosts, versions, hashes, outcomes), and the human authorization record — plus retained AI transcripts, because an AI-assisted conclusion may have to be explained later to a client or a court.
7. Secrets. API clients are scoped per tenant, vaulted, and rotated on a cadence. The MCP server holds credentials; the model sees data, not keys.

One naming point, because it's easy to conflate: this is a bring-your-own-model approach over the open MCP standard, complementary to CrowdStrike's own Charlotte AI, not a replacement claim. And "official open-source" refers to the falcon-mcp project itself — nothing here implies partnership with or endorsement by CrowdStrike.

Where to Start

If you run IR and want to try this without betting the incident on it:

1. Stand up falcon-mcp with read-only scopes. One API client, minimum READ scopes, one server per tenant.
2. Keep execution in a separate, reviewed code path with its own RTR credential — never in the AI's environment.
3. Pre-stage and version your collector. No ad-hoc scripts on endpoints mid-incident.
4. Make every wave a human decision against a host list a person can read, canary first.
5. Parse before you analyze. Deterministic parsers index the artifacts; the AI queries the parsed layer, with citations.

This is how QMasters approaches incident response and DFIR, managed detection and response, and CrowdStrike partnership services: AI as leverage for senior judgment, with the guardrails built into the credential model — not promised in a prompt. It's the same principle behind QMasters Agentic SOC. If you're working out where AI fits in your own IR, that's a conversation we're glad to have as peers.

Because at fleet scale, in the middle of the night, the most reassuring sentence a CISO can hear is the one this architecture is built to guarantee: the AI never holds the shell.

Frequently Asked Questions

Can an AI run CrowdStrike RTR commands on endpoints?

Not the ones that change anything. A read-only credential cannot retrieve files, run scripts, or remediate — those require CrowdStrike's RTR Admin tier. Even read-only RTR is capped at look-only commands like ls, ps, and cat. In a sound architecture, execution uses a separate credential, a human authorizes every wave, and pre-reviewed orchestration code — not the AI — runs the collection on hosts.

Is CrowdStrike's falcon-mcp server read-only?

Yes, by design. The API client is granted READ scopes only. Even falcon-mcp's own RTR module is capped at read-only commands — ls, ps, cat, filehash, reg, single-host — and its documentation states it "does not expose admin or remediation commands." State-changing RTR lives in the separate RTR Admin tier, outside the AI's reach.

How do you collect triage data from 100+ endpoints with RTR?

With batched RTR sessions that launch a detached collector on each host, then poll for a completion marker before retrieving. Retrieval is per host and cloud-queued (get to the CrowdStrike cloud, then download), and every archive is SHA256-verified on the host and again after download. Re-runs are idempotent, so only failed or offline hosts are retried.

Does the AI analyze the 100GB of collected data directly?

No. Deterministic parsers index the collected artifacts, and the AI queries and synthesizes over that parsed layer — with every conclusion cited back to specific hosts and files. The AI never ingests raw 100GB archives.

Is it safe to connect AI to incident-response data and live endpoints?

It can be, if the architecture enforces the guarantees rather than trusting the model: read/execute separation by credential scope, human authorization per action, treating all telemetry and collected artifacts as untrusted (prompt-injection-aware), full audit logging, and chain of custody with hash verification.

How is this different from CrowdStrike Charlotte AI?

Charlotte AI is CrowdStrike's built-in assistant. This is a bring-your-own-model approach over the open Model Context Protocol plus your own hardened RTR orchestration. They're complementary — one doesn't replace the other.

---

Gregori Nazarovsky is CTO of QMasters, where he leads the engineering behind the company's SOC, MDR, and incident-response practice. The falcon-mcp deployment and the RTR collection orchestrator described here were built and operated in-house. This is Part 2 of a series on AI in security operations; Part 1 covered MCP and the SIEM.

References

• falcon-mcp — CrowdStrike (GitHub, MIT)
• PSFalcon — CrowdStrike (GitHub)
• Real Time Response API — CrowdStrike Developer Center
• Real Time Response Admin API — CrowdStrike Developer Center
• Falcon MCP — RTR module — CrowdStrike Developer Center
• The Power of Real Time Response — CrowdStrike Tech Hub
• Model Context Protocol — modelcontextprotocol.io