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, because a rule you cannot find is a rule you cannot audit.
What each source may expose
Per field, per connector: tokenized, masked, or in the clear because reasoning needs it. Anything undeclared is masked.
In buildper-field masking is live for CRM; the unified panel is being built outWhich 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.
LiveWhat an agent may spend
Ceilings per agent, per job and per day, checked before the call rather than totalled after it.
LiveWhich 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.
LiveWho may change any of it
Policy editing is a role, not a login. The console shows who holds it and what they changed.
LiveRules 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.
PlannedA limit that is checked afterwards is a report, not a control.
Budget caps refuse the run
The ceiling is enforced before the model is invoked, so an overspend is a refusal you can see rather than an invoice you cannot.
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
A field nobody classified is masked rather than guessed, an unknown category is refused rather than allowed. Fail closed is the default everywhere, not a hardening option.
Plannedper-field structured masking is live for CRM today; the unified per-connector panel is the new pieceEvery 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.
Nothing your agents run updates itself.
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. Which registries exist at all is your decision, not a default someone else set.
Imported content lands in a holding area that is structurally incapable of reaching a prompt, not "not allowed to", unable to. That separation is enforced when the product is built, not by a runtime check someone can misconfigure.
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.
Liveupdate checking runs when you ask for it, not on a schedule
Registries are a source like any other. See everything it connects to →