Secure your AI workflows with CrowdStrike AIDR Guardrails and Bifrost

See how Bifrost and CrowdStrike AIDR secure enterprise LLM traffic: AIDR handles detection, Bifrost enforces policy inline before any prompt reaches a model.

Enterprise AI deployments run into the same set of security issues within a few months of going live. A support rep pastes a full customer record into a summarization tool, and the prompt leaves your network for a third-party API with its own retention policy. A retrieval agent ingests a vendor PDF with instructions hidden in white-on-white text and quietly calls an internal tool it was never meant to touch. A coding assistant surfaces a live credential straight from the repository context it was handed, and it lands in a chat log nobody is scrubbing.

The firewall did not catch any of this, the SIEM did not catch any of this, and the DLP rules did not catch any of this, because none of them were built to inspect natural language flowing into and out of a language model. Bifrost, the open-source AI gateway from Maxim AI, integrates with CrowdStrike AI Detection and Response (AIDR) to put a guardrail layer in place using the same security policy already deployed across the rest of the enterprise.

How the Bifrost Gateway Acts as an AI Security Layer

The reason these problems slip past existing controls is that the risk lives in what goes into the model and what comes back out, and nothing in the traditional stack sits in that path. The gateway does. Bifrost terminates every LLM call an application makes, so every prompt passes through it on the way to a provider and every completion passes through it on the way back to a user. That single inline position is what turns the gateway into a place where AI security can be enforced rather than just observed after the fact: the traffic is already there to inspect, before it reaches a model and before it reaches a user.

Because the gateway sits inline, inspection attaches to it as configuration rather than application code. A guardrail rule is scoped with a CEL expression and bound to an input, output, or both phase, and it runs on every matching call regardless of which application issued it or which provider served it. When a rule matches, Bifrost pulls the text-bearing fields and tool context out of the payload (chat messages, Responses API objects, text completions, rerank queries, image prompts) and runs them through the checks the rule references. The application keeps talking to a single endpoint; validation, monitoring, and logging happen at the gateway.

The same inline position carries the operational and governance properties an enterprise expects. Bifrost keeps traffic flowing when a provider degrades, attributes every call to a team or environment for budgets and access control, and writes an audit trail that maps to SOC 2 Type II and HIPAA evidence. A security policy applied here inherits that surface, so it runs with the same scoping, logging, and request-level visibility as the rest of the gateway, rather than as a bolt-on with its own blind spots. Latency is the usual objection to inline inspection, but the gateway itself adds roughly 11 microseconds of overhead per request, which leaves the cost of a guardrail call dominated by the provider round trip, not by Bifrost.

What the gateway does not do on its own is decide what counts as a violation. It can intercept a prompt, extract the text, and act on a verdict, but the verdict has to come from a detection engine that knows what prompt injection, data exfiltration, or a policy breach actually looks like. That is the piece CrowdStrike AIDR provides.

What CrowdStrike AIDR Detects in LLM Traffic

CrowdStrike AIDR is the AI security module of the CrowdStrike Falcon platform. It runs on the same model as the rest of Falcon: a managed detection engine, ongoing updates to detection logic, and telemetry that flows into the same console security operations already lives in. For LLM traffic, AIDR detects:

• Prompt injection, including indirect injection via documents and tool outputs
• Jailbreak attempts targeting the system prompt
• Sensitive data and PII exposure in prompts or completions
• Credential and secret leakage
• Custom entities defined in the AIDR policy
• Tool definitions, assistant tool calls, and tool results in agent flows
• Application Monitoring and Application Protect policies of CrowdStrike include for continuous runtime data flow tracking, automated API vulnerability scanning, and real-time behavioral threat blocking across cloud workloads.

What matters for enterprises already standardized on Falcon is that none of this forks off into a separate vendor with separate workflows. The policy lives in CrowdStrike. The findings show up in the CrowdStrike console. AI security incidents are correlated against the rest of the security telemetry. The relevant subscription for application and agent traffic is AIDR for Agents; for region, collector, and policy specifics, see the CrowdStrike AIDR documentation.

Put the two together and the division of labor is clean. AIDR owns detection: the engine and the policies your security team already maintains in Falcon. Bifrost owns enforcement: the rule evaluation, the request and response interception, and the action taken on every matching LLM call. CrowdStrike decides what a violation is; Bifrost makes that decision happen inline, before a prompt reaches a model and before a response reaches a user. An AI security policy that previously lived in the Falcon console becomes inline policy across every provider and model routed through the gateway, with no change to application code. The next section walks through that call path end to end.

How CrowdStrike AIDR Runs Inside Bifrost

Inside Bifrost, CrowdStrike AIDR is registered as a third-party guardrail provider. The configuration model has two pieces. A Profile holds the AIDR provider settings: collector token, base URL, optional app ID for log attribution. A Rule decides when that profile runs and on which phase, input, output, or both. Rules are written in CEL, so they can be scoped to specific models, traffic patterns, or headers. Multiple profiles can chain on the same rule for layered checks.

When a request enters the gateway, input rules run first. If a rule matches, Bifrost extracts the message content and any tool context from the request, packages it into an OpenAI-shaped guard_input payload, and posts it to AIDR. AIDR evaluates the payload against the policy assigned to the collector and returns one of three responses:

• Blocked. Bifrost returns HTTP 400 with type: "guardrail_intervention" and the request never reaches the model. The error message comes from AIDR's policy decision.
• Transformed. AIDR returns rewritten text (for example, with PII redacted) and Bifrost forwards the rewritten version instead of the original.
• Allowed. The original content goes through unchanged.

The output phase runs the same flow in reverse with event_type: "output" and the model's completion as the payload. For streaming responses, input guardrails run before the streaming request leaves Bifrost. Streaming output redaction is not supported today, so output checks against AIDR currently apply to non-streaming responses.

What You Get by Implementing AI Security Guardrails at the Gateway

The integration solves two problems that do not have clean answers when handled separately.

The first is consistent policy across an inconsistent stack. Most enterprises have AI traffic spread across multiple providers: Anthropic for reasoning, OpenAI for tool use, AWS Bedrock for compliance-sensitive workloads, a self-hosted model for cost. Writing the same security policy in each application, against each provider's SDK, against each model's quirks, is a losing exercise. With this integration the AIDR policy lives in CrowdStrike, Bifrost applies it uniformly across every provider routed through the gateway, and the application code does not need to know any of it.

The second is security team ownership without engineering bottlenecks. The security team owns the AIDR policy inside Falcon, where it already works. Engineering owns the Bifrost configuration. Neither side waits on the other to roll out a change. A new detection rule in AIDR takes effect on the next request through Bifrost. A new traffic scope in Bifrost (only production keys, only external users) does not require touching the AIDR policy.

Beyond those two, the concrete benefits include:

• Inline enforcement, not after-the-fact alerting. AIDR's verdict happens before the request reaches the model and before the response reaches the user.
• Telemetry where the security team already looks. Findings flow into the AIDR console alongside the rest of Falcon's telemetry, so the AI security view sits next to the endpoint security view.
• Multi-provider coverage from a single policy. The same configuration applies to every provider routed through Bifrost.
• Layered detection. AIDR can run on the same rule as Bifrost's native guardrails (Secrets Detection, Custom Regex), so deterministic checks for known credential patterns or internal project codenames run alongside AIDR's policy engine.
• Scoping that controls cost and latency. CEL rules send only the traffic that matters to AIDR. Sampling rates and per-rule timeouts give a second dial for high-throughput endpoints.
• Agent and tool-call inspection. For chat-based agent traffic, tool definitions, tool calls, and tool result IDs all flow to AIDR alongside the prompt content.

Setting Up CrowdStrike AIDR Guardrails in Bifrost

Setup happens in two places: the AIDR collector inside Falcon, then the matching guardrail profile and rule inside Bifrost.

Prerequisites

• Bifrost Enterprise with the guardrails plugin enabled
• A CrowdStrike Falcon tenant in US-1, US-2, or EU-1
• An AIDR for Agents subscription
• A Falcon user with AIDR Admin permissions
• Network egress from Bifrost to the AIDR API over HTTPS

Step 1: Create the AIDR collector

In the Falcon console, open AI Detection and Response > Collectors and create an Application collector for Bifrost (or open an existing one). Set the name, logging mode, and policy. If no policy is assigned, AIDR provides visibility but will not return block or redaction decisions for Bifrost to enforce. From the collector's Config tab, copy the API token and base URL. US-1 tenants use https://api.crowdstrike.com/aidr/aiguard; US-2 and EU-1 tenants use the regional URLs shown in the collector configuration.

Step 2: Add the CrowdStrike profile in Bifrost

In the Bifrost dashboard, go to Guardrails > Providers, select CrowdStrike AIDR, and click Add Configuration. Enter a name (for example, crowdstrike-aidr-prod), set the collector token (using an environment variable like env.CS_AIDR_TOKEN is preferred for production), set the base URL, optionally set the app ID and collector instance ID for log attribution, and save.

The same configuration over the management API:

curl -X POST <http://localhost:8080/api/guardrails/crowdstrike-aidr> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "crowdstrike-aidr-prod",
    "enabled": true,
    "config": {
      "api_key": "env.CS_AIDR_TOKEN",
      "base_url": "env.CS_AIDR_BASE_URL",
      "app_id": "bifrost-production",
      "collector_instance_id": "prod-us-east-1",
      "timeout": 30
    }
  }'

Step 3: Attach the profile to a rule

Go to Guardrails > Configuration and create a rule that links the CrowdStrike profile. The simplest configuration runs AIDR on every input and output:

The same configuration over the management API:

curl -X POST <http://localhost:8080/api/guardrails/rules> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "crowdstrike-aidr-all-chat",
    "enabled": true,
    "celExpression": "true",
    "applyTo": "both",
    "samplingRate": 100,
    "timeout": 60,
    "maxTurnsToSend": 8,
    "selectedGuardrailProfiles": ["crowdstrike-aidr:12"]
  }'

For higher-traffic deployments, CEL expressions scope the evaluation to the traffic that matters most:

• External-user traffic only: headers["x-user-type"] == "external"
• Production virtual keys: headers["x-bf-vk"] == "prod"
• Specific provider or model: provider == "openai" && model.startsWith("gpt-4")

The maxTurnsToSend setting limits how much conversation history is forwarded to AIDR, which is useful when long chat histories would otherwise add latency or hit AIDR timeouts.

Verifying enforcement

When AIDR blocks a request, Bifrost returns:

{
  "type": "guardrail_intervention",
  "status_code": 400,
  "error": {
    "type": "guardrail_intervention",
    "message": "Blocked by CrowdStrike AIDR policy: Malicious Prompt was detected and blocked."
  }
}

For input guardrails, the LLM request is never sent. For output guardrails, the response is replaced with this error. AIDR metadata (policy name, detector count, detector names, block status, transform status) is recorded in Bifrost logs for correlation against the AIDR Findings page.

Getting Started

CrowdStrike AIDR and Bifrost give enterprises a clear split: AIDR handles detection, Bifrost handles enforcement, and both meet at the gateway on every LLM request. The security team keeps its existing tools and the policy it already maintains in Falcon. Engineering keeps its existing gateway. The AI security layer does not fork off into a separate system that nobody owns.

For the full integration reference, see the Bifrost CrowdStrike AIDR setup guide in the docs. To see how this works across an enterprise LLM stack, book a demo with the Bifrost team.