For CrowdStrike · Charlotte AI · Agentic SOAR · AgentWorks · Falcon Foundry

Every Charlotte and Falcon agent action,
independently judged before it executes.

Three response actions below are shaped exactly as they leave the Falcon platform — an Agentic SOAR workflow step, a Falcon Foundry function, an MCP tool call — and each one goes through the live Veridect system on this page. On your side the integration is one workflow action, one function, or a URL change. Behind it is the whole control plane: consensus from frontier models across independent vendors, deterministic policy classes, risk routing, a hash-chained ledger, and an Ed25519-signed decision record you can verify right here.

Open the full live tour
3 seams
a workflow step, a Foundry function, or one MCP URL — your agents, playbooks and models stay exactly as they are
1 judgment
POST /pre-action — behind every path (the MCP gateway makes that call for you); the answer is a verdict plus a signed record
1 record each
every decision — pass, hold or refusal — is a signed record, exportable as newline-delimited JSON into the SIEM you already run
0 trust required
every decision re-derives from its recorded inputs and verifies against a published key — try it below
Where it sits

Between the agent’s recommendation and the response action.

CrowdStrike runs the agent: Charlotte AI triages and investigates; Agentic SOAR and Falcon Fusion carry the response workflows; AgentWorks builds mission-specific agents; Falcon Foundry hosts custom apps and functions beside the data. Veridect sits at the one moment none of those were built to own: the instant before a response action with consequences executes — a containment, a policy change, a credential reset, a detection closed — when an independent judgment — not the model that proposed the action, not the platform that hosts it — decides whether it goes, waits for a person, or never happens, and signs the record either way.

Your agent on Falcon

Proposes an action

  • Charlotte AI and AgentWorks agents proposing response actions
  • Agentic SOAR and Falcon Fusion workflows that contain, remediate, reset or close
  • Any MCP tool an agent reaches — in either direction
Veridect · live control plane

Judges it before it runs

  • Deterministic scope check against the agent’s configured authority
  • Policy classes in code — money thresholds, protected data, regulated data, cumulative exposure
  • Multi-vendor model consensus with calibrated confidence and a dissent register
  • Risk routing: greenlight, escalate to a named human queue, or block
  • Hash-chained, Ed25519-signed record — written whether it passes or not
Outcome

Three doors, one record

greenlightthe response action runs or the tool call is forwarded; the verdict and record id travel with it
escalateheld for a person in the queue the policy names — the workflow notifies, the function returns the verdict, the tool call waits
blocknever executes — and the refusal is on the ledger too
Three thin paths

The integration is thin. The system behind it is not.

Each path maps the call your agent was already making onto one judgment — POST /api/ai/consensus/pre-action, made by your workflow step, your function, or the MCP gateway on your behalf: the verb, the target object, the fields, which agent is asking, and what that agent is authorized to do. Nothing about the agent, the model, or the playbook changes. The verdict decides whether the original action proceeds.

PATH 01 · AGENTIC SOAR · WORKFLOW STEP

A judgment step before the response action

Falcon Fusion SOAR workflows call out to external services over HTTP. Make the Veridect call the step before any action with consequences — contain, disable, reset, close — and a condition lets the action run only on a greenlight; otherwise the workflow notifies with the verdict and the record id. Every playbook an agent can trigger is covered; the agent and its model do not change.

2 steps · one HTTP action + one condition · no code

Fail-closed by construction: a failed, timed-out or malformed call never satisfies the condition, so the response action does not run. The Veridect key sits in the workflow’s credential store, never in the playbook.

# Falcon Fusion SOAR workflow — step 1 asks Veridect; the response action runs only on greenlight
trigger: Charlotte AI / AgentWorks agent proposes a response action
actions:
  - name: Veridect pre-action                              # HTTP (REST) action
    method: POST
    url: https://<your-veridect-host>/api/ai/consensus/pre-action
    headers: { Authorization: "Bearer ${credential.veridect_key}", Content-Type: application/json }
    body:
      action:            ${trigger.action}                   # e.g. "update_detection_status"
      target:            falcon:${trigger.object_type}       # e.g. "falcon:detection"
      parameters:        ${trigger.parameters}
      callingAgent:      "<agent-id>"                          # a workflow constant: the agent this workflow belongs to — not a trigger field
      callingAgentScope: "<its configured authority, in words>"  # a workflow constant set when the workflow is built — never a trigger field
    timeout_seconds: 60

  - condition: ${actions.veridect_pre_action.body.verdict} == "greenlight"   # a failed step never reaches true
    then:
      - run the response action                              # the work step — the record id goes into the comment
      - add comment: "Veridect greenlight · record ${actions.veridect_pre_action.body.auditBundleId}"
    else:
      - notify the queue: "Not executed — Veridect ${actions.veridect_pre_action.body.verdict} · record ${actions.veridect_pre_action.body.auditBundleId}"
PATH 02 · FALCON FOUNDRY · FUNCTION

One function every agent action passes through

Falcon Foundry hosts Python functions beside your data in the platform. Route agent-initiated mutations — detection updates, policy changes, identity remediation — through one Foundry function that asks Veridect first and calls the Falcon API only on a greenlight, returning the verdict and the record id either way. Agents hold no API scopes of their own.

~35 lines · one Foundry function · humans untouched

Where the authority lives: the scope string is the agent’s configured authority, looked up inside the function by the identity Falcon attached to the call — never a field in the request body. A read-only hunter that proposes to disable a prevention policy is a categorical no-authority action — the deterministic layer blocks it before any model is asked to weigh in. Watch it below. The policy classes work over field names; send values only for the fields your policy needs.

# Foundry function "governed_action" — the only path from an agent to a Falcon mutation
import os, json, urllib.request
from crowdstrike.foundry.function import Function, Request, Response
func = Function.instance()

AGENT_AUTHORITY = {                                                        # authority keyed by the agent's identity — your configuration, never a body field
    "<triage-agent-client-id>": "may update detection status and add comments; may not change prevention policies or contain hosts",
    "<hunter-agent-client-id>": "read-only: may query detections, hosts and identity events; may not modify any Falcon object",
}
ALLOWED = {"update_detection_status", "add_detection_comment", "disable_prevention_policy", "contain_host"}   # the mutations this function knows how to perform

@func.handler(method="POST", path="/governed-action")
def governed_action(request: Request) -> Response:
    b = request.body
    agent_id = caller_identity(request)                                    # the API client / app identity Falcon attached to this invocation — not b["agent_id"]
    scope = AGENT_AUTHORITY.get(agent_id)
    if scope is None or b.get("action") not in ALLOWED:
        return Response(code=403, body={"executed": False, "verdict": "unknown_agent_or_action"})   # never asked, never run
    verdict, record_id = "unavailable", ""                                 # closed until proven open
    try:
        req = urllib.request.Request("https://<your-veridect-host>/api/ai/consensus/pre-action", method="POST",
            data=json.dumps({"action": b["action"], "target": "falcon:" + b["object_type"],
                             "parameters": b["parameters"], "callingAgent": agent_id,
                             "callingAgentScope": scope,                          # its configured authority, in words
                             "department": "security_operations"}).encode(),
            headers={"Content-Type": "application/json",
                     "Authorization": "Bearer " + os.environ["VERIDECT_API_KEY"]})
        with urllib.request.urlopen(req, timeout=60) as r:
            d = json.load(r) if r.status == 200 else {}
        verdict, record_id = d.get("verdict", "unavailable"), d.get("auditBundleId", "")
    except Exception:
        pass                                                               # network, timeout, parse: all stay closed
    if verdict != "greenlight":
        return Response(code=200, body={"executed": False, "verdict": verdict, "record_id": record_id})
    result = falcon_api(b["action"], b["parameters"], comment="Veridect record " + record_id)   # the mutation, record id in its comment
    ok = result.get("status_code") == 200 and not result.get("errors")                 # Falcon's own answer decides "executed"
    return Response(code=200, body={"executed": ok, "verdict": "greenlight", "record_id": record_id, "result": result})
PATH 03 · MCP · BOTH DIRECTIONS

One MCP URL, whichever way the call flows

Agents on the Falcon platform can reach external tools over MCP, and external agents can reach Falcon tools the same way. Either way, register the real server as a Veridect upstream once and point the client at Veridect instead. Every tools/call is judged in flight; tools/list, initialize and everything else pass straight through. A refused call is never forwarded.

0 lines of agent code · one registration, one URL

Identity on the wire: the agent’s identity, workflow id and business context ride in params._meta["veridect/…"] — unsigned, that is the caller’s own claim, and the decision record marks it as such; a tenant can require a signed Ed25519 identity envelope on every call, and an unsigned call is then refused inside the protocol. Both outcomes run live below.

# 1) once — register the real tool server as an upstream (admin call)
POST /api/ai/consensus/mcp/upstreams/{tenant}
{ "upstreamId": "falcon-tools-prod", "url": "https://<your-tool-server>/mcp", "enabled": true }

# 2a) a Falcon agent reaching an external tool server — the MCP server URL in its configuration
before:  https://<your-tool-server>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/falcon-tools-prod

# 2b) an external agent reaching Falcon tools — the same change, the other way round
before:  https://<your-falcon-mcp-server>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/falcon-mcp-prod
HEADERS = {
  "Authorization":            "Bearer <VERIDECT_API_KEY>",            # your Veridect tenant
  "X-Upstream-Authorization": "Bearer <Falcon OAuth2 token>",         # forwarded to the upstream as Authorization
}

# 3) what the agent sees on a greenlight: the upstream's own result, plus
#    result._meta["veridect/verdict"] and result._meta["veridect/bundleId"]
#    on escalate / block: a JSON-RPC error (-32003 / -32004) carrying the
#    verdict and the record id — and the server never receives the call.
Run it live

Four Falcon-shaped actions, through the live system, now.

Each card sends the exact request the workflow step, the Foundry function, or the MCP connection would send, to the live Veridect system on a shared sandbox tenant. The verdicts are real multi-model decisions made while you wait; the records are written to the ledger and signed; the Verify button re-derives the verdict from the recorded inputs and checks the signature against the published key. Expected outcomes are stated in advance — the engine decides.

Ready. Each decision takes a few seconds while the model roster deliberates.
LIVE 01 · PATH 01 · AGENTIC SOAR WORKFLOW

Mark a detection in progress and assign it to Tier 2

A Charlotte triage agent proposes update_detection_status on a credential-dumping detection: status in progress, assigned to the Tier 2 queue, with a comment. Its configured authority: “may read detections and may triage them: set status, severity and assignee.”

Expected: greenlight — inside authority, no policy class fires, the roster agrees. The condition is true, the response action runs, and the record id lands in the detection comment.

Waiting. Request shape: the workflow step’s body, verbatim.
LIVE 02 · PATH 02 · FOUNDRY FUNCTION

A read-only hunter tries to disable a prevention policy

A hunt-summary agent proposes disable_prevention_policy on Workstations — Default after judging it responsible for a false-positive storm. Its configured authority: “read-only: may read detections, hosts and threat intelligence to draft hunt summaries.”

Expected: block — a read-only agent proposing a policy change is a categorical no-authority action; the deterministic scope check decides, the models are consulted for the record, and the function returns the verdict without calling the Falcon API.

Waiting. Request shape: the Foundry function’s body, verbatim.
LIVE 03 · PATH 02 · FOUNDRY FUNCTION

Reset a compromised user’s recovery factors

An identity-remediation agent, inside its authority (“may read identity risk and may update credentials and recovery factors of identities flagged compromised”), calls update_recovery_factors for a flagged user with a new phone_number and email_address.

Expected: escalate — the deterministic protected_personal_data_modification policy class fires on the field names alone — the values are never inspected — and routes the action to the queue the policy names. Authorized but consequential actions escalate to a person; they are never silently blocked and never silently allowed.

Waiting. Request shape: the Foundry function’s body, verbatim.
LIVE 04 · PATH 03 · MCP

The same tools/call, two tenants, two outcomes

A JSON-RPC tools/call for lookup_policy_limit goes through the live Veridect MCP gateway to a sample tool server that counts what it actually receives. First on the shared sandbox tenant; then on a tenant that requires a signed identity envelope, sent without one.

Expected: first call forwarded, the tool’s own hit counter goes up by one and the result carries _meta["veridect/bundleId"]; second call refused inside the protocol (-32004 identity_not_presented), counter unchanged, refusal on the ledger.

Waiting. Request shape: JSON-RPC 2.0, verbatim.

What on this page is live, and what is illustrative

Live: every verdict, confidence, dissent register, policy class, escalation route, ledger write, hash chain, Ed25519 signature, MCP forwarding decision and verification result above comes from the production Veridect system on a shared sandbox tenant — the same endpoints an integrator calls. The consensus roster is four frontier providers from independent vendors with a decisive-verdict early stop, so a decision on this surface typically records three; the models are named in each record’s dissent register. The protected-data classes are this sandbox tenant’s policy; in your tenant every threshold is yours.

Illustrative: the agent side. No Charlotte AI session, Fusion workflow or Foundry function executes from this page; each card sends the exact request the workflow step, the function or the MCP connection would send, so what you watch is the decision those integrations would receive. The MCP calls in Live 04 leave this browser as a standard MCP client; a Falcon agent’s MCP connection was not exercised here. The code above is written against the documented Falcon Foundry function SDK for Python and the shape of a Fusion SOAR workflow with an HTTP action; workflow syntax is shown schematically, and the tool-server URL is a placeholder for your own. The integration is demonstrated wiring, not a CrowdStrike-certified, Marketplace-listed or endorsed solution.

Verification proves that the enforcement decision re-derives from the recorded inputs and that the record is unmodified and signed by the published key. It does not re-run the models: the consensus summary is attested through the recorded dissent register and verifier-text hash, and disclosed as such in the proof itself.

CrowdStrike, Falcon, Charlotte AI, Falcon Fusion, Falcon Foundry and other CrowdStrike marks are trademarks or registered trademarks of CrowdStrike, Inc. Veridect is an independent company and is not affiliated with or endorsed by CrowdStrike.

Five questions, answered for a CrowdStrike team

The short version.

How does this help?

It lets Charlotte and Falcon agents into the response actions that carry consequences — containment, policy changes, credential resets, identity records — because an independent judgment stands in front of each action and a signed record stands behind it. The model that proposes the action is never the one that approves it.

How do I integrate it?

One of the three paths above: a step in the workflow, a Foundry function in front of mutations, or one MCP URL. Your agents, playbooks and models stay as they are. The decision records export as newline-delimited JSON into the SIEM you already run. It runs where you say, on your keys.

How long does it take?

The system is live today. A private sandbox on your own policy thresholds in a day once you say go; production typically about two weeks, with the pace set mostly on your side — security review, keys, access. Ours is ready on day one.

How does this make money?

Three levers, none of them invented here: revenue held back because agents could not be trusted with the consequential step; cost stopped on human review of actions a signed record now settles; losses not taken on the actions that should never have executed. Your own number comes out of the sandbox.

Why you and not a big well-known company?

Because the judgment has to be independent of the model and of the platform to be worth anything to an auditor. The Falcon platform’s own controls are the platform’s view of its agents; a platform grading its own agents is self-governance. Veridect is a separate control plane with its own ledger and keys, validated by an external red team on scope-violation semantics, and verifiable offline. Try to forge a record on the live tour; the engine refuses it.

Test-drive it yourself.

Run the four actions above, verify the records, then take the full live tour — identity envelopes, delegation chains, cross-agent exposure, the fleet layer, and the forgery the engine refuses. Seven minutes, open access.

Prefer to see it on your own scenarios? Paste one on the pre-action console — or write to lrussell@veridect.ai and a scoped production sandbox on your own thresholds and your own tenant follows in a day.

The same control plane, built the same way for Snowflake, Microsoft, AWS, ServiceNow, Rubrik, Salesforce, Databricks, Okta and Google Cloud — one engine behind all ten pages, each run live. All ten platforms →