Skip to main content

Security

Sentinel centralizes model access, which makes it part of your security posture. It gives teams a safer control point for authentication, provider credential handling, policy enforcement, and evidence around request behavior.

What Sentinel secures​

Sentinel secures the model-access layer by centralizing:

  • client authentication to the gateway
  • provider credential isolation from application clients
  • policy and endpoint restriction enforcement before provider execution
  • durable request and operator evidence through telemetry and audit

The goal is to move model-access control into one managed layer instead of scattering it across individual applications.

Trust boundaries​

Sentinel sits between:

  • applications and end-user workflows
  • provider credentials and provider APIs
  • operator control surfaces and runtime traffic

That makes the trust boundaries explicit:

  • clients trust Sentinel keys, not provider keys
  • operators manage provider secrets through the control plane
  • the gateway enforces policies and restrictions before provider execution

This separation helps teams control model access without distributing sensitive provider credentials across clients.

Client auth versus provider auth​

Clients authenticate to Sentinel. Sentinel then authenticates to providers on their behalf.

That separation is one of the core security properties of the platform.

In practice:

  • application clients should not need direct provider credentials
  • provider secrets should remain under operator control
  • SDK-specific auth quirks should be handled in the client configuration layer, not by exposing provider credentials to callers

Security priorities​

For most teams, the first priorities are:

  • encrypting and isolating provider secrets
  • scoping Sentinel keys narrowly
  • keeping production and non-production environments separate
  • retaining enough audit evidence for governance and incident review
  • validating route and endpoint restrictions as part of rollout

These controls matter because model access is both a runtime path and a governance surface.

What Sentinel is not​

Sentinel strengthens model-access governance, but it does not replace:

  • your application authorization model
  • upstream provider account hygiene
  • network perimeter or service identity controls
  • data classification policies inside your own applications

Sentinel adds a security layer around model access. It does not replace the rest of your application or enterprise security model.

To operationalize Sentinel securely:

  • rotate keys regularly
  • use separate provider configs for different environments
  • review audit and telemetry access permissions
  • document which teams own budgets, policy changes, and provider credential changes
  • define retention expectations for audit and request visibility explicitly

The goal is to make control ownership, evidence, and environment separation clear before Sentinel becomes part of critical workloads.