Security Architecture

How Fire Mission protects your AI traffic

Five security pillars, enforced in the gateway middleware. Plain-language product descriptions and full architecture detail — nothing marketing-only.

Trust Center → Tier comparison → API docs →

Five Security Pillars

Every pillar is enforced in the gateway — not a policy UI. If it is listed here, it runs on every call.

🛡️ 01

AI Data Loss Prevention

Detect and block PII, credentials, and sensitive data before it reaches your AI provider.

Every request is scanned for personal identifiers (SSNs, emails, phone numbers, payment card data), embedded credentials, and proprietary patterns. Observe tier detects and logs violations. Control, Protect, and Command tiers block violations in-flight before the payload reaches the provider.

🔍 02

Behavioral LLM Verification

Verify that the model that answered is the model you requested.

When you request gpt-4o, Fire Mission verifies the response signature matches gpt-4o — not a silently substituted cheaper or older model. Substitution mismatches raise a security verdict and are written to the audit log. Providers have incentive to quietly downgrade; Fire Mission removes that incentive from the equation.

🌐 03

Supply Chain Enforcement

US-only AI provider policy enforced at the gateway level.

All approved AI providers must serve from US-based infrastructure. Foreign-jurisdiction providers are blocked by default. Label-laundering attacks — where a custom baseUrl spoofs a legitimate provider name — are detected and rejected via URL-origin checks. Provider whitelists and model denylists are enforced on every request.

📋 04

AI Audit Trail

Immutable log of every call — model, token count, cost, latency, and security verdict.

Raw prompt and completion bytes are never written to durable storage. The audit log contains only metadata: model requested, model served, token counts, inferred cost, latency, security verdict, and the SHA-256 hash of the prompt (for tamper evidence). Retention ranges from 7 days (Observe) to unlimited (Command). Export to CSV or NDJSON available on Protect and Command.

💰 05

AI Cost Governance

Per-key spend caps, budget alerts, and real-time cost analytics.

Token costs flow directly to your AI provider via your BYOK credentials — Fire Mission never touches inference billing and adds zero markup. Per-key monthly spend caps prevent runaway costs. Budget alerts notify your team before thresholds are crossed. Per-call cost attribution is logged and surfaced in the console.

Architecture Detail

Two-plane isolation

Fire Mission strictly separates the control plane (PostgreSQL holding metadata: token counts, costs, security verdicts, SHA-256 content hashes) from the data plane (the ephemeral path that prompt and completion bytes take through the gateway on the way to your selected provider).

Raw prompt and completion bytes are never written to durable storage. The control plane only ever sees what's needed to bill, alert, and audit. A breach of Fire Mission's database exposes metadata — never prompt content or completion text.

BYOK — your keys, your providers

Bring Your Own Key. Provider credentials (OpenAI, Anthropic, Google, Groq, Together AI, self-hosted) are stored AES-256 encrypted at rest and used only to forward the call to the provider you chose. Fire Mission has no provider partnerships and no revenue share on inference — there is no incentive to silently route your traffic anywhere else.

Mandatory security scanning — no off switch

Every call runs through the security scanner regardless of tier. The scanner cannot be disabled by configuration.

  • PII detection — emails, SSNs, phone numbers, payment cards, and other sensitive identifiers.
  • Prompt-injection patterns — known attack templates flagged before the call hits the provider.
  • API-key leakage — outbound prompts containing credentials are stopped at the gateway.
  • US-compliance gating — provider whitelists and supply-chain blocks enforced on every request.
DLP mode varies by tier: Observe detects and logs violations (call proceeds to provider). Control, Protect, and Command actively block violations in-flight. Prompt injection and API key leakage are hard-blocked on all tiers — these are active attacks, not data classification events.

Verification flow

📱
Your app
OpenAI / Anthropic SDK
→
🛡️
Fire Mission Gateway
Scan → Cap → Verify model → Log metadata
→
🤖
Your AI provider
BYOK credentials — your inference spend
←
✅
Verified response
Model identity confirmed → verdict logged

Prompt and completion bytes pass through. Only metadata is persisted to the control plane.

Supply chain enforcement — private host policy

The geopolitical enforcement mechanism applies supply chain blocks, provider whitelists, model denylists, compliance checks, and geo-blocking to every request. URL-origin checks are applied to all baseUrl specifications — a custom base URL pointing at a foreign-jurisdiction endpoint is blocked even if the provider name looks legitimate (label-laundering attack).

Self-hosted LLM runtimes (Ollama, LM Studio, LocalAI, vLLM) are supported with a private-host policy: restricted to specific runtime types and requiring explicit opt-in for private network access. This prevents SSRF attacks and cloud metadata exfiltration via a malicious self-hosted endpoint.

Authentication & access control

  • Self-serve signup via Google or GitHub OAuth.
  • TOTP 2FA available on all paid tiers.
  • SSO / SAML on all tiers (architectural baseline).
  • SCIM 2.0 user provisioning on Command tier (Okta, Azure AD, Google Workspace).
  • Role-based access control with strict tenant isolation between organizations.

Encryption

  • TLS 1.3 in transit.
  • AES-256 at rest for API keys and provider credentials.
  • FIPS 140-2 validated cryptographic modules for user account material.
  • API key validation cache keyed on HMAC-SHA-256 — raw key bytes never stored in memory.

What a Fire Mission breach exposes

Typical AI proxy breach exposes

  • Raw prompt and completion text
  • User conversation history
  • Embedded credentials in prompts
  • Document content (if stored)

Fire Mission breach exposes

  • Token counts, costs, latency (metadata only)
  • Security verdicts (not the flagged content)
  • Provider credentials (AES-256 encrypted at rest)
  • No prompt text. No completion text. No document content.

Current attestation status

SOC 2 Type I in progress · NIST 800-53 aligned · HIPAA-ready architecture · FedRAMP-aligned (Moderate readiness on roadmap) · PCI DSS SAQ-A for checkout. Fire Mission never claims certifications it doesn't hold.

Visit the Trust Center →

Report a vulnerability

Coordinated disclosure to mark@blackburntactical.us. We acknowledge within one business day. See /trust for current attestation status.