Skip to main content

Authentication

Clients authenticate to Sentinel, not directly to the upstream model provider.

Client authentication model​

Sentinel expects a Sentinel-issued key on incoming requests. In the common case, that means:

Authorization: Bearer sp_live_...

The gateway authenticates the key, loads the associated control-plane context, and then applies endpoint restrictions, routing, policy, budgets, and limits before any upstream provider call is made.

Provider authentication model​

Provider credentials are managed by Sentinel as provider secrets and provider configs. They should not be supplied by end-user clients.

Sentinel then injects the correct upstream auth on the provider-facing side:

  • OpenAI-compatible upstream auth for OpenAI-like providers
  • x-api-key and version headers for Anthropic
  • x-goog-api-key for Google native routes

SDK-specific caveats​

Different official SDKs need different client configuration in order to authenticate correctly to Sentinel:

  • OpenAI SDK works naturally with apiKey + baseURL
  • Anthropic SDK should use authToken + baseURL, not apiKey, because client auth to Sentinel is Bearer-based
  • Google GenAI SDK needs httpOptions.baseUrl plus an injected Bearer Authorization header even though the SDK still expects an apiKey value

Key scoping​

Keys should be scoped as narrowly as practical:

  • per environment
  • per service or application boundary where possible
  • with explicit endpoint restrictions where needed
  • with budgets and rate limits aligned to the consumer

Security defaults​

  • keep provider secrets in Sentinel-managed encrypted storage
  • avoid embedding provider credentials in application code
  • treat Sentinel keys as customer-facing credentials and rotate them
  • prefer environment separation over shared broad keys across dev and production