Policy and enforcement

One active policy. Versioned. Auditable. Optionally enforced at the wire.

Your org has exactly one active AI policy at a time. New policies are drafted, reviewed, then activated — at which point the previous policy becomes an archived version and the new one starts driving signals and (if enabled) enforcement.

What's on the page

The page is at AI → Governance → Policy and enforcement. Three sections, top to bottom.

Active policy card

Header shows the version number, activation date, and who approved it. The summary line is a one-paragraph description of what this policy does.

Below the summary, a list of rules grouped by ruleType:

• Rule name and the type pill (e.g. provider_allowlist, model_ban, cost_centre_routing, monthly_cap, budget_cross_provider, content_filter).
• The condition expression in human-readable form.
• The action — WARN, BLOCK, or OBSERVE.
• The scope — org-wide, or scoped to a team, cost centre, or service account.

The View audit log button opens a side drawer with every mutation against this policy version — who drafted it, who approved it, and the diff against the previous version.

Empty state

If your org has never activated a policy, the card renders an empty state with a "Draft your first policy" CTA. Drafting is gated on the AI_POLICY_ADMIN permission.

Version timeline

Below the active card, a compact timeline of every previous version. Each entry links to /version/[policyId] for full read-only inspection. Use this to:

• Compare a current rule against how it was worded six months ago.
• Trace an audit-log entry to the exact policy snapshot in force at that moment.
• Roll back by drafting a new version that copies an old one.

Drafting and activating

Click Draft new version to spawn a draft from the active policy. The draft URL is /draft/[draftId]. Drafts are scratch space — multiple admins can iterate without affecting production.

Activation is an explicit step. The activator's identity and timestamp end up on the audit log. The previously active policy becomes the most recent entry on the version timeline, with its activeFrom / activeUntil window stamped.

Drafts that are never activated stay in draft state indefinitely — they don't expire and they don't show up on the version timeline.

Observe vs enforce

Each rule carries an action: OBSERVE, WARN, or BLOCK.

• OBSERVE — log the match, no signal raised. Used for tuning a rule before promoting it.
• WARN — log the match, raise a behavioural signal at WARN severity, no request blocking.
• BLOCK — same plus the Flowstate Agent returns a 403 to the calling tool with the rule name in the response.

Enforcement only happens for BLOCK rules and only when the agent's enforcement mode is on — which is its own org-wide switch at Settings → AI → Agent Policy. See Enforcement for the rollout sequence.

WARNING

Once BLOCK enforcement is on, the agent is in the request path. Outages, latency, and rule correctness all matter to your engineers. Run rules in OBSERVE for at least two weeks before promoting.

Spend caps and aggregate budgets

Two of the most common rule types — MONTHLY_SPEND_CAP_PER_SUBJECT (per-provider) and BUDGET_CROSS_PROVIDER (aggregate across many providers) — get their own page because they're the everyday control. See Budgets and spend caps for worked examples and the per-rule params.

The audit log

Every state change against any policy — draft, activate, deactivate, edit a rule — lands in the audit log. The drawer on the active card shows the log filtered to the active version. Full audit access for any version lives at /version/[policyId].

Audit entries are append-only. They carry the actor's identity, timestamp, mutation type, and the JSON diff of what changed.

Permissions

Action	Permission
View active policy and history	AI_GOVERNANCE_VIEW
Draft a new version	AI_POLICY_ADMIN
Activate a draft	AI_POLICY_ADMIN
View audit log	AI_GOVERNANCE_VIEW

See Roles & Permissions for how these map to your role bindings.