Security scanning

Every /v1/* request runs through the BYOK security scanner before the upstream call is made. Detection is categorical only — Fire Mission returns and logs verdict codes, never the matched substrings. This is enforced by Two-Plane isolation: the data plane sees bytes, the control plane sees codes.

What the scanner catches

  • PII. Email addresses, phone numbers, SSNs, credit-card numbers, IBANs, and other common identifiers.
  • Prompt injection. Instructions inside user content that try to override the system prompt or exfiltrate tools.
  • API-key leakage. Any string matching the shape of a popular provider key (OpenAI sk-*, Anthropic sk-ant-*, AWS access keys, etc.).

What happens on detection

The request fails immediately with HTTP 400 and code security_violation. The error message identifies the verdict category but never echoes the matched content. The metadata-only audit log captures (verdict_code, request_id, user_id, api_key_id, timestamp).

What the scanner does NOT do

  • It does not store the request body.
  • It does not store the matched substring.
  • It does not attempt to redact and forward — calls fail closed.

Two-Plane isolation

The control plane (PostgreSQL) stores only metadata: SHA-256 hashes, token counts, cost cents, status code, latency, security verdicts. The data plane is ephemeral — request and response bytes live only in memory for the duration of the call. This is structural, not policy: there is no schema for raw prompt or completion bytes anywhere in the codebase.

Disabling scans

Mandatory scanning is part of the product's security model and cannot be disabled. If a particular detection produces a false positive on a legitimate workload, contact support — categorical detection rules can be tuned per-tenant.