Policy & enforcement

This is the operator's control room for what runs automatically, what asks first, and what's forbidden. It lives in one place: the Security tab of Oversight, read top to bottom — your posture, what your agents can do, guardrails (the never / ask-first rules), approvals (what runs without asking), and team permissions. Every control has an i with a plain-English explanation and an example, and every change saves automatically.

Posture — your starting point#

Each workspace has one policy object covering approval tiers, capabilities, visibility, limits, and agent lifecycle. Pick a posture to set sensible defaults in one choice: Regulated (maximum oversight), Standard (recommended for most teams), or Open (light oversight). Tune anything afterward; once you do, the posture reads Custom and a preset is one click away to reset. You can also set posture during onboarding.

Ceiling — Capability enforcement is seeded-gated: it stays off until an operator explicitly saves a policy, so a fresh install never breaks itself by enforcing an implicit default. Members see the Security surface read-only; only operators edit it.

Approvals — what runs without asking#

In the Approvals section you set the ceiling an employee can self-approve (Safe / Moderate / Destructive) and what always escalates to you. Below that, auto-approved actions turn repeated approvals into standing decisions — they build themselves as you tick "Always allow" on a real approval, and read in plain English ("Create folders", "Delegate to COO"). They're scoped per-agent or workspace-wide; per-agent rules win, first match wins.

Ceiling — Creating a rule ("Always allow …") is operator-only. And a core set of action types — editing an agent's prompt, installing a skill, changing trust, merging code, creating a rule — can never be auto-approved, no matter the rule.

Trust Mode — break glass#

Per-agent Trust Mode bypasses the allow/ask rules for one agent — a deliberate break-glass for an agent you fully trust.

Ceiling — Trust Mode does not bypass an enforcing deny rule, and it does not unlock the never-auto-approve types. A CISO's hard "never" outranks an operator's convenience toggle.

The enforcement kernel — allow / ask / deny#

One engine applies your rules across every surface — the in-product approval flow, the coding-agent gate, and the MCP gate — so there's one accountable place that governs an action. Rules carry an effect (allow / ask / deny), a mode (shadow or enforcing), a scope, a pattern, and optional conditions.

Ceiling — On cooperative surfaces (the coding and MCP gates) enforcement is best-effort on a tamper-evident record — not containment. Real containment is the enterprise tier. The honest label per surface is on the security model.

Conditions#

Conditions make a rule contextual — "deny writes to the main branch" (an action condition), or "ask if this session already touched a secret" / "after hours" (a session condition). A malformed or unevaluable condition makes a rule fail safe — it simply doesn't fire, never fires blindly.

Guardrails: shadow mode, the library & named lists#

Guardrails are the never and ask-first rules, checked before anything else, under the Guardrails section (the everyday library up front, the exact rules and lists under Advanced).

• A prebuilt library of house rules (deny secret writes, deny protected-branch writes, ask on an unknown host, …) gets you started; tick one on and it lands in shadow first.
• New rules default to shadow — they log what they would do without enforcing, so you can watch a rule for real before turning it on. A 30-day simulation replays history through a candidate rule.
• Named lists are the fill-in-the-blanks a guardrail reuses: allowed hosts, protected branches, sensitive paths. Edit a list once and every guardrail that uses it updates.

Prove it fires — the guardrail check#

At the top of Guardrails, Run guardrail check fires a curated set of actions your guardrails should block through the real enforcement kernel and confirms each returns deny — then re-runs the environment case with the connection to any central service cut and confirms it still blocks. It records one entry in Trace per run and fires on a daily tick, so "guardrails verified" is a fact, not a slide.

Ceiling — Nothing is actually executed — the check asserts the verdict, it never runs the command. A pass proves your guardrails fire on a tamper-evident record; it is not proof of containment.

Next#

• AI usage, budgets & access — limits and per-agent scoping.
• Governing AI you don't run — the coding and MCP gates.