Governance
Policies are versioned records holding rules evaluated against AI activity. Guardrails run on both sides of the model. Access is a combination of role, scope, workspace, visibility and policy.
Policies
A rule names what it matches, how severe a match is, and whether it is active. Policies move through draft, active and deprecated states, and every version is retained — so you can show which rule was in force when an action was taken.
Governance
Policies
Sensitive data policy
Activev3
Owner
Platform governance
| Rule | Expression | Severity | Outcome |
|---|---|---|---|
| Block payment card data | pii.credit_card | Critical | Block |
| Block credentials in prompts | secrets.api_key | Critical | Block |
| Require approval off-region | data.residency != region | High | Require approval |
Interface shown with illustrative data.
Controls
Every check produces an outcome — pass, warn or block — against a named guardrail type, on the request and on the response. Results are visible individually and in aggregate, so you can see which controls actually fire.
Policies are enforced: block, warn, require approval, or log. They cover data loss, personal data, payment data and secrets. Guidelines are advisory — engineering standards that shape output without stopping the work.
Role, plus authority scope — self, team or organization — plus workspace membership, plus resource visibility, plus policy. Workspaces, teams, roles, permissions, API keys and invitations are managed in one place, and changes to them are auditable.
A violation becomes an event with a severity, a status, an owner and an SLA. Events can be assigned by rule, triaged, investigated and resolved with the breach clock visible — and exported.
Next step
Request a demo based on your use case, deployment environment and governance requirements.