Policies

The Policies page is where security engineers turn organizational requirements into rules the proxy enforces inline. Every change here lands in PostgreSQL and is picked up by every proxy instance on its next request.

The policy list

The list shows every policy in the tenant with its name, action (ALLOW/FLAG/DENY), priority, scope (which agents it applies to), and fire count for the selected window. Sorting by fire count is the fastest way to find policies that are actually doing work versus dead rules.

Authoring

Click New policy to open the builder. The form has four parts that mirror the policy model:

1. Match conditions: pick from agent, action type, upstream, prompt content, headers, tool name. Conditions stack with AND.
2. Action: ALLOW, FLAG, or DENY.
3. Priority: integer; lower fires first.
4. Scope: tenant-wide by default, or restricted to a chosen set of agents.

A live JSON preview on the right shows what will be saved.

Versioning

Every save creates a new version. The History tab on each policy shows all versions with the operator, timestamp, and a diff. Rolling back is one click and creates a new version pointing at the earlier definition, the audit chain stays intact.

Disabling vs deleting

Policies can be disabled without being deleted. Disabled policies stop firing immediately but remain visible for context (and to make audit trails interpretable). Delete only when you are sure the policy will never be relevant again.

The test playground

The Test tab lets you paste a sample request body and see:

• Which policies match, in priority order.
• The first matching policy and its action.
• Which DLP detectors would fire on the body.

This is the recommended way to validate a policy before flipping it from disabled to enabled in production.

Common patterns

A few patterns we see often:

• High-priority deny rules for credential leakage (a DENY at priority 10 matching prompt content like aws_secret_access_key).
• Mid-priority flag rules for sensitive intents (a FLAG at priority 50 matching keywords like salary, customer list, production database).
• A default allow rule at priority 1000 so the policy outcome is always explicit, never the implicit tenant default.

Where to go next

• Proxy: policies: the underlying model.
• DLP: content-based blocking that runs alongside policies.
• Audit log: who changed what, when.