Policies
Policies let Sentinel apply governance before a provider request is executed. For most teams, policy is the product surface that turns model access from a direct provider call into a managed platform capability.
What policy can do
Depending on the configured rules and route shape, Sentinel can:
- inspect supported request text
- allow or block a request
- annotate and log policy outcomes
- emit telemetry and audit signals around policy decisions
Operators usually manage policy from the Sentinel console, then verify policy behavior through request visibility and audit trails.
Inspection boundaries matter
Policy behavior depends on what can be inspected safely and reliably.
In practice:
- chat and responses routes provide meaningful text inspection surfaces
- embeddings and text-generation workflows are more straightforward than binary routes
- file, audio, and image workflows expose narrower inspectable fields
- some routes, such as moderation-style workflows, need explicit handling so the governance layer does not interfere with the purpose of the endpoint
The key idea is that policy coverage depends on the route shape, not just on the existence of a route.
What policy should not do
Sentinel policy should not be thought of as a generic payload transformation system.
In most cases, policy is a pre-execution control and decision layer. Its job is to evaluate supported request content, enforce governance intent, and record policy outcomes, not to become a general-purpose request rewriting engine.
Operating guidance
Start with a small, reviewable policy set.
A good first policy rollout usually means:
- keeping the initial rule set limited and easy to verify
- testing allow and block paths intentionally
- confirming policy decisions are visible in telemetry and audit
- documenting exceptions for routes with special semantics
The goal is to make policy behavior understandable and operationally trustworthy before adding more complexity.