Policies and enforcement

A policy says what should happen when an agent's action matches a condition. Bairav evaluates policies for every governed action and records the decision.

Four actions

Action	Effect	Mode
block	The action is refused	Enforcing
require_approval	The action is gated until a reviewer approves or denies it	Enforcing
flag	The action proceeds and is marked for review	Monitor-only
notify	The action proceeds and someone is told	Monitor-only

When several policies match one action, one decision is made with a fixed precedence: block, then require_approval, then flag, then notify. If nothing matches, the action is allowed with the reason "no matching policy". Each decision records the agent, the policy, a plain-language detail and how long evaluation took.

Four kinds of definition

A policy's definition has one of four kinds.

Kind	What it matches
conditions	A scope: an AND/OR tree over agent attributes such as data sensitivity, risk tier, capabilities, entity type, autonomy, external exposure, trust and model, and over request fields. The fields are listed by GET /api/policies/fields. An empty value matches everything.
guardrail	Runtime checks on each call: patterns in prompts, denied tools, and optionally redaction of PII and secrets in prompts or responses
behavior	A behaviour judged by the AI judge at run time
trigger	A named runtime event rather than a scope match

A guardrail looks like this:

{
  "guardrail": {
    "deny_prompt_patterns": ["(?i)ignore (all )?previous instructions"],
    "deny_tools": ["delete_customer"],
    "message": "This request was blocked by policy."
  }
}

Guardrail policies attached to an agent are enforced by the gateway on every call and delivered to the sensor for on-host enforcement.

Work with policies

Task	Call
List, create, change, delete	GET/POST /api/policies, PATCH/DELETE /api/policies/{id}
See which agents a policy would match, with up to six names	POST /api/policies/preview
Check a new policy against existing ones	POST /api/policies/conflicts
Version history	GET /api/policies/{id}/versions
Draft, transition, publish	PUT/DELETE /api/policies/{id}/draft, POST /api/policies/{id}/transition, POST /api/policies/{id}/publish
Attach or detach on one agent	POST/DELETE /api/agents/{id}/policies
Apply a ready-made set	GET/POST /api/policy-packs, POST /api/policy-packs/{id}/apply
Write a policy in plain English	Policy authoring
See the effect before you change anything	Try it out

Creating and changing policies needs the admin or reviewer role. A preview that matches zero agents does not stop you saving.

Approvals

Every gated decision creates exactly one pending approval, deduplicated per policy and agent while it is pending, with a plain-language ask naming the agent and the policy. Reviewers decide with Approve or Deny; a denial needs a note while that tenant setting is on. The outcome (allowed or blocked) is written back to the enforcement feed and the Audit ledger.

• GET /api/approvals lists them, sorted by priority, flagging those past the SLA (default 24 hours, configurable to 4, 8, 24, 48 or 72).
• POST /api/approvals/{id}/decide decides one.
• GET /api/enforcement is the feed of decisions.
• GET /api/policy-evaluations/{id}/explain explains one recorded decision.