Skip to content

Security model

Current state

LunarGate authenticates to upstream providers and now supports basic inbound API-key authentication for callers using the gateway.

What that means

Do not expose the gateway directly to the public internet as if it were already a finished multi-tenant API edge.

The built-in API-key layer is a good first control for trusted internal clients and service-to-service traffic. External auth backends and deeper policy controls are still a future step.

  • Enable security.provider: api_key for internal callers that should be able to reach /v1/*.
  • Keep API-key config minimal unless you need custom headers; OpenAI-style Authorization: Bearer <key> works by default.
  • Put it behind an auth-enforcing reverse proxy or API gateway.
  • Restrict inbound network access to trusted workloads.
  • Keep provider keys in server-side environment variables or secret stores.
  • Use network policy, firewall rules, or security groups to scope who can call the gateway.

Provider secrets

Provider credentials are typically injected through environment variables such as:

  • OPENAI_API_KEY
  • ANTHROPIC_API_KEY
  • DEEPSEEK_API_KEY
  • ABACUS_API_KEY

Data sharing is also a security decision

Enabling prompt or response export changes the privacy boundary of the system. Keep data_sharing.enabled, share_prompts, and share_responses aligned with your compliance and debugging needs.

Operational recommendation

Warning

If you need tenant isolation or customer-facing access control today, terminate requests at a separate gateway layer that enforces auth before traffic reaches LunarGate.