Free Store
Get started

Policies

Rules, stored on your server, that deny an action or hold it for a person.

Maturity: Beta. Every statement on this page was traced to the enforcing code in QuoxCORE on 2026-10-29: the policy store, the server policy gate, the chat-window gate and the quox governance policy commands.

At a glance
What it isRules for your organisation that decide whether an agent action may go ahead, must wait for a person, or is refused.
Where it runsOn your QuoxCORE server. Policies are stored per organisation and checked by the server's policy gate before an agent action runs.
When to reach for itYou want a standing rule, such as "never run this kind of command" or "always ask me first for that".
How to startquox governance policy list shows the policies in force.

How a policy works

A policy has a scope (which agents or teams it covers), conditions (what it matches) and an effect. The server's policy gate checks the matching policies before an action runs:

  • deny: the action is refused;
  • require approval: the action waits for a person to approve it.

If the gate cannot evaluate a policy, it fails closed: the action does not run.

The built-in system policies cannot be edited or deleted.

Manage policies from the CLI

bash
quox governance policy list
quox governance policy get <id>
quox governance policy create --effect require_approval --scope '{"agents":["*"]}' --conditions '<json>' --reason "why"
quox governance policy update <id> --enforce-4eyes
quox governance policy delete <id>
quox governance policy validate
quox governance policy history

Ready-made sets of policies are available as templates: quox governance policy template list.

Reviewing policy changes

Changing a policy can go through an optional second-approver review (off by default; forced for agent-initiated changes). Ask for it on an update with --enforce-4eyes; the change is then held until it is approved, and quox governance policy pending-approvals lists what is waiting.

Every policy change is kept in the policy history and recorded as an audit event.

Extra checks in the chat window

When you use chat in the dashboard, your browser runs a few quick checks before a message is sent:

  • Rate limits: 30 messages a minute and 300 an hour, counted in that browser tab.
  • Content checks: messages that look like destructive database commands (DROP TABLE, DELETE FROM, TRUNCATE), rm -rf or sudo rm, or pasted secrets (password:, secret=, api_key=) are blocked. Others, such as sudo or chmod 777, add a warning.
  • Agent scope: a message outside an agent's usual area adds a warning; it is not blocked.

These checks apply to the dashboard chat only. Commands from the CLI, the API and other channels are governed by the server policy gate above.

The kill switch and DEFCON

Stopping agents is a separate control, set on the server by an admin. See DEFCON levels.

Limits

  • The chat-window checks cover dashboard chat only, and their rate limits are per browser tab.
  • Second-approver review is optional. It is off by default for changes made directly.
  • No time-of-day rules. Policy scope covers agents, teams and your organisation.
  • quox policy compile and arm are not yet enforced. Use quox governance policy for rules that apply today.
  • Safety: what needs approval, and how approvals work.
  • DEFCON levels: holding or halting autonomous work.
  • QuoxCLI: the command line.

Last verified 2026-10-29 against QuoxCORE origin/main (policy store, server policy gate, chat gate and quox governance).