CrowdStrike Charlotte AI Integration Guide

Overview

Charlotte AI is CrowdStrike's generative-AI security analyst. It can triage detections, summarize cases and incidents, analyze command lines, and answer free-form security questions via an LLM completion interface.

The key constraint: Charlotte AI is not exposed through CrowdStrike's public OAuth2 API. There is no charlotte resource or endpoint you can call directly from a CrowdStrike Integration Node. The only supported way to invoke Charlotte programmatically is to:

1. Wrap a Charlotte AI action inside a CrowdStrike Fusion SOAR workflow, and
2. Start that workflow with an inbound webhook trigger.

Your NINA workflow then calls that webhook to start Charlotte, and polls the workflow's execution status until Charlotte has answered — at which point it reads the completion from the execution result.

This guide documents that end-to-end pattern. It builds on:

• CrowdStrike Platform Integration Guide — the workflows resource used to poll execution status
• Webhook Node Guide — used to call the remote trigger
• Loop Node Guide and Scripting Agent Node Guide — used to poll and parse the result

Architecture

The integration spans two systems. Charlotte runs asynchronously inside CrowdStrike, so the call is not request/response — it is trigger, then poll.

On the CrowdStrike side, a Fusion SOAR workflow pairs an inbound webhook trigger with a Charlotte AI action. A POST to the webhook starts the workflow and returns 200 immediately; Charlotte then runs in the background and writes its answer into that workflow execution.

On the NINA side, a Webhook Node calls the remote trigger to start Charlotte, then a while loop repeatedly queries workflow_executions_combined and checks the latest execution's status — continuing while it is in progress and exiting once it is Completed, at which point Charlotte's answer is read from the execution result.

CrowdStrike (Fusion SOAR workflow)
  ┌─────────────────────┐      ┌──────────────────────────┐
  │ Trigger:            │ ───▶│ Action:                  │
  │ Inbound webhook     │      │ Charlotte AI –           │
  │ (POST, Basic auth)  │      │ LLM Completion           │
  └─────────────────────┘      └──────────────────────────┘
            ▲                              │ writes result into
            │ (1) POST starts workflow     │ the workflow execution
            │     returns 200 immediately  ▼
─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
            │
NINA workflow
  ┌──────────────┐   ┌─────────────────── Loop (While) ─────────────────────┐
  │ Webhook Node │─▶│  ┌─────────────────────┐   ┌────────────────────┐    │
  │ calls remote │   │  │ CrowdStrike Platform│   │ Scripting Agent    │    │
  │ trigger URL  │   │  │ workflows /         │─▶│ check latest       │    │
  └──────────────┘   │  │ workflow_executions │   │ execution status   │    │
                     │  │ _combined           │   └────────────────────┘    │
                     │  └─────────────────────┘             │               │
                     │        ▲   continue while status     │               │
                     │        └─── is "in progress" ────────┘               │
                     └──── exit when status = "Completed", with Charlotte's─┘
                                          answer

Part 1 — CrowdStrike side: build the Charlotte workflow

You build this once in the CrowdStrike Falcon console. It exposes a single Charlotte action behind a webhook URL.

1. Create the Fusion workflow and add the inbound webhook trigger

1. In the Falcon console, go to Fusion SOAR → Workflows and create a new workflow.

2. Add a trigger and select Inbound webhook. Configure it:

   Field	Example value	Notes
   Name	test-charlotte	Becomes part of the workflow definition
   Description	test	Optional
   HTTP method	POST
   Authentication type	Basic	Generates a username/password the caller must send
   Response code	200	Returned immediately on trigger (does not contain Charlotte's answer)
   Webhook URL	https://api.eu-1.crowdstrike.com/webhooks/<id>/v1	Copy this — NINA's Webhook Node calls it

3. Optionally define a Request schema so the trigger can validate and expose the fields you POST (e.g. a prompt field).

4. Securely store the Basic-auth username and password — NINA needs them to call the webhook.

The webhook URL is region-specific (api.eu-1 above is the EU cloud). It must match the cloud region of your tenant.

2. Add the Charlotte AI action

1. Add an action node after the trigger and search for charlotte.

2. Select the Charlotte capability you want. This guide uses Charlotte AI – LLM Completion (a general-purpose LLM completion interface).

   

   Other Charlotte actions you can choose from the same picker:

   Action	Purpose
   Charlotte AI – LLM Completion	General-purpose LLM completion (used here)
   Triage Detection with Charlotte AI	Get the results of a detection triage
   Investigate with Charlotte AI	AI-powered suggestions drawing additional relationships
   Investigate case with Charlotte AI	Same, scoped to a case
   Charlotte AI – Summarize case	Natural-language summary of a case
   Charlotte AI – Summarize incident	Natural-language summary of an incident
   Charlotte AI – Analyze command line	Natural-language description of a detection's command line
   Charlotte AI Agentic Response – Get canvas	Fetch agentic response data for a given canvas/detection ID

3. Wire the action's input to the trigger's request fields (e.g. map the incoming prompt to the LLM Completion prompt).

4. Save, then enable/publish the workflow.

Each Charlotte capability is its own action. To expose more than one (e.g. both LLM Completion and Summarize case), create one Fusion workflow — each with its own inbound webhook — per capability.

Part 2 — NINA side: call Charlotte and wait for the answer

Because the trigger is asynchronous, the NINA workflow has two phases: start (call the webhook) and poll (loop on execution status until done).

Node layout

1. Webhook Node — starts the remote Charlotte workflow
2. Loop Node (While) — polls until Charlotte finishes
   • CrowdStrike Platform Integration Node — workflows / workflow_executions_combined, fetch the latest execution
   • Scripting Agent Node (e.g. Extract_latest) — read the latest execution's status
   • Loop condition: continue while status is in progress; exit when Completed
3. Downstream nodes consume Charlotte's completion text

Step 1 — Webhook Node (start the workflow)

Point the Webhook Node at the inbound webhook URL from Part 1. Send the Basic-auth credentials as an Authorization header, and put your prompt in the request body.

Property	Value
URL	https://api.eu-1.crowdstrike.com/webhooks/<id>/v1
Method	POST
Content Type	application/json
Headers	Authorization: Basic <base64(username:password)>

Request Body: add one entry per field the trigger expects, as a Key/Value pair. For the LLM Completion action, send a prompt:

Key	Value
prompt	Summarize the most relevant threats from the last 24 hours and recommend next steps.

The node serializes these pairs into the JSON body it POSTs (e.g. {"prompt": "Summarize the most relevant threats from the last 24 hours and recommend next steps."}). Values can be static text or reference upstream data — see Parameter Merging.

The webhook returns 200 as soon as the workflow is accepted. It does not return Charlotte's answer — that is produced asynchronously and must be polled for in Step 2.

Step 2 — Loop: poll the workflow execution

Inside a Loop Node configured as a while loop, add a CrowdStrike Platform Integration Node that lists recent workflow executions, newest first.

CrowdStrike Platform Integration Node:

{
  "integration_service": "crowdstrike-platform",
  "resource": "workflows",
  "operation": "workflow_executions_combined",
  "parameters": {
    "filter": "definition_name:'test-charlotte'",
    "sort": "start_timestamp.desc",
    "limit": 1
  }
}

Adjust the FQL filter to match the workflow you created — for example filter by the definition name or definition ID of your Charlotte workflow so you only get its executions. Sorting by start_timestamp.desc with limit: 1 returns the most recent run.

Step 3 — Scripting Agent: read the status

A Scripting Agent Node (named e.g. Extract_latest) reads the latest execution from the combined response and surfaces its status so the loop can branch on it:

// input = response from workflow_executions_combined
const latest = (input.resources && input.resources[0]) || {};
return {
  status: latest.status,        // e.g. "Running" (in progress) → "Completed"
  execution: latest             // full execution record, incl. result when done
};

Step 4 — Loop condition and exit

• Continue the loop while status is in progress (e.g. Running).
• Exit the loop when status is Completed — Charlotte has answered.

When the loop exits, Charlotte's output is available in the execution result. For the LLM Completion action it looks like this:

{
  "status": "Completed",
  "result": {
    "completion": "# ...Charlotte's full answer in markdown..."
  }
}

Downstream nodes can then read result.completion.

Always set a maximum iteration count (and/or a delay) on the loop. If the status string never matches your exit condition the loop would otherwise run forever. A bounded loop with a sensible cap fails safe.

Credentials and scopes

This pattern uses two independent sets of credentials:

Where	Credential	Used for
Webhook Node (Step 1)	The Basic-auth username/password generated by the inbound webhook trigger	Authenticating the call that starts the Charlotte workflow
CrowdStrike Platform Integration Node (Step 2)	The shared CrowdStrike Platform credential (OAuth2 client credentials)	Polling workflow_executions_combined for status/results

The Integration Node credential needs Workflow read scope (and the tenant must have Charlotte AI and Fusion SOAR enabled/licensed). All CrowdStrike modules share one Platform credential — see the Platform guide.

Troubleshooting

Issue	Resolution
401 from the Webhook Node	Basic-auth header is missing or wrong. Re-check base64(username:password) against the trigger's generated credentials.
404 / wrong region on the webhook	The webhook URL host must match your tenant's cloud region (e.g. api.eu-1).
Loop returns no execution	The FQL filter doesn't match your workflow. Verify the definition name/ID and that the workflow is enabled.
Loop never exits	The status string doesn't match your exit condition. Log the raw status and confirm the exact value (e.g. Completed). Keep the max-iteration cap as a safety net.
Execution completes but result.completion is empty	The Charlotte action's input wasn't mapped from the trigger payload, or the action differs from LLM Completion (other actions return different result shapes).
Charlotte action unavailable in the action picker	Charlotte AI is not enabled/licensed in the tenant, or the API client lacks the required scopes.

Limitations and notes

• No direct API. This trigger-and-poll pattern is the supported workaround for Charlotte not being on the public API. If CrowdStrike later exposes Charlotte directly, prefer that.
• One workflow per Charlotte capability. The webhook triggers exactly one configured action; expose additional capabilities with additional Fusion workflows.
• Asynchronous by design. Budget for poll latency — Charlotte responses take seconds to complete, so tune the loop delay and cap to your use case.