BYOK provider keys

Fire Mission is BYOK by design — you supply the upstream provider keys (OpenAI, Anthropic, Google Gemini, Groq, Together AI, AWS Bedrock, Azure OpenAI, IBM watsonx, etc.). Fire Mission encrypts them, resolves them on the hot path, and forwards your call.

Lifecycle

  1. Add a provider in the dashboard under AI Provider Management. Pick a provider, paste the upstream key, optionally set a base URL.
  2. Encrypt at rest. Keys are AES-256 encrypted with a key encryption key stored separately from the database.
  3. Resolve on call. When your SDK request arrives, Fire Mission identifies the provider from the model id (or from MoE's decision), decrypts the matching BYOK key in memory, and forwards.
  4. No persistence. The decrypted key never lands on disk and is wiped from memory after the call.

Provider routing

Models are routed to providers via inferProviderFromModel(). Most models map unambiguously (gpt-* → OpenAI, claude-* → Anthropic). For models a single id can resolve to multiple providers (e.g. Claude via Anthropic direct AND AWS Bedrock), the model id is prefixed <provider>/<model> in /v1/models.

Geopolitical authorization

Every call passes through assertProviderAuthorized() before egress. The choke point checks:

  • Provider is on the supply-chain whitelist (US / NATO / MNNA only on firemission.us).
  • Model id is not on the denylist.
  • The resolved baseUrl origin matches the declared provider — no label-laundering.
  • Self-hosted runtimes match the private-host policy (no SSRF, no cloud-metadata exfiltration).

Per-request key override

You can pass an upstream key per request via standard provider headers if you prefer not to store it server-side. Fire Mission still runs the security and authorization checks; it simply skips BYOK key resolution.

Key rotation

Rotate provider keys in the dashboard at any time. Active in-flight calls finish on the old key; new calls use the new key. There is no downtime window. Audit logs capture every rotation with actor and timestamp.