The rules run before the model does.
Watching what your AI did is not the same as governing what it can do. This is the half that happens first.
Six questions your organisation gets to answer.
They live in one Policy Center rather than scattered across six product screens, so every rule is findable, and therefore auditable, in one screen.
What each source may expose
Per field, per connector: tokenized, masked, or in the clear because reasoning needs it. Anything undeclared is masked.
Which models may be used
An allowlist per host and per job, including which models may run on your own hardware and which may never leave it.
What an agent may spend
Ceilings per agent, per job and per day, checked before the call rather than totalled after it.
Which actions wait for a person
The consequential ones. Sending, writing back to a system of record, spending, held as a card until someone says yes.
Who may change any of it
Policy editing is a named role; the console shows who holds it and what they changed.
Rules only you have
Policies you author yourself will run in the same versioned and audited model as the built-in ones, because no vendor ships your regulator’s rulebook. Today the families above are the ones the console configures.
Limits are checked before the call runs.
Budget caps refuse the run
The ceiling is enforced before the model is invoked, so an over-budget run is refused up front instead of surfacing later as an invoice.
Approval gates hold the action
The consequential step waits as a card with the full context, and the job continues only after a person decides. A rejected hold never rehydrates the real data.
Undeclared means masked
An unclassified field is masked. An unknown category is refused. Fail-closed is the default on every path.
Every edit to a rule is itself an event.
Policies are versioned; an edit made against a stale version is rejected rather than silently overwriting someone else’s; and each change lands on the same append-only ledger as the work it governs. So “who loosened this, and when?” is a question with an answer.
Every skill update waits for your approval.
Agent skills are instructions and scripts written by someone else, and the industry’s habit is to pull the newest version automatically. That is a supply chain running straight into your tenant. Here every skill is admitted the way an employee’s laptop software is: reviewed, approved, and pinned until somebody decides otherwise.
Anthropic, OpenAI, NVIDIA, and your own authenticated sources. You decide which registries exist at all.
Imported content lands in a holding area that is structurally incapable of reaching a prompt: the separation is compiled into the product, so no runtime setting can bridge it.
Every byte is checked for prompt injection and for scripts that do more than they say. A dangerous verdict on community or custom content is blocked in code, before any policy setting is consulted, so no setting, however permissive, can let it through.
When a skill you installed changes upstream, your installed copy stays byte-identical. The new version re-enters the same queue as a new arrival, gets scanned again, and waits for approval.
When you check for updates, everything that comes back clean can be approved together, each install audited on its own. Anything that does not come back clean simply stays pending.
Registries are a source like any other. See everything it connects to →