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.
Sentinel may use signed runtime artifacts internally for hot-path execution, but that is not part of the public client contract. Client integrations still use the same bearer-key model.
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-keyand version headers for Anthropicx-goog-api-keyfor 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, notapiKey, because client auth to Sentinel is Bearer-based - Google GenAI SDK needs
httpOptions.baseUrlplus an injected BearerAuthorizationheader even though the SDK still expects anapiKeyvalue
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