Policy Engine
Plain-English rules. Enforced at the gateway.
18 built-in policies cover the common cases: PII in prompts, secrets leaking out, prompt injection patterns, EU data residency, runaway agent step counts, dangerous tool calls, monthly budget caps, autonomy boundary violations, and more. A JSON DSL covers the rest, with a visual editor and a validator that won't let a bad rule ship.
What it is
One evaluator. Two enforcement points. Custom rules without code:
- 18 built-in policies. Catch PHI, PII, secrets, prompt-injection patterns, dangerous tool calls, high-cost invocations, EU data residency violations, medical decisions without HITL, monthly budget caps, autonomy boundary violations, and more.
- Gateway-mode enforcement. POST to /api/v1/gateway/check before the model call to allow, alert, or block.
- Ingest-path evaluation. Policies run on every receipt, even when gateway mode is off.
- JSON DSL custom policies. Author rules in the dashboard, validated at edit time so a bad rule can't break ingest.
- Dry-run endpoint. Replay traffic against a draft policy before flipping it on.
What it does for you
Catch the violation before the call goes out.
Gateway mode runs policies before the request reaches the model. A blocked decision is captured in the Audit Vault marked _prova_gateway, so the audit trail captures what was attempted, not just what executed.
Write custom rules without writing code.
The JSON DSL covers the cases the built-ins don't. The validator rejects bad predicates at edit time; the loader picks them up alongside the library. No deploy needed.
Audit trail of every attempted violation.
Even when a policy doesn't block, every finding is signed and stored. Quarter-over-quarter you can see the rate dropping (or not) and point at the specific policies driving the change.
Dry run before you flip the switch.
Author a policy, replay the last 30 days of receipts against it, see the would-be hit rate, then turn it on. No production surprises from a regex that was tighter than you thought.
Why a policy is different from a guardrail
A model-side guardrail lives inside the model. It's bounded to one provider, opaque about what it caught, and stops working the day you switch model vendors.
A Prova policy lives at the control plane, above the model. It produces a signed audit record. It applies to every model your enterprise uses, the same way, with the same semantics, regardless of who trained the model or what they did at training time.