01
Governance
Five layers, each assuming the one above it failed. The strongest is the database: a prompt can be talked around, a missing permission cannot.
In plain words
An agent runs only with a registered owner, risk tier and tool grant. Remove the row and it stops.
The model is offered only its granted tools; anything else is refused and logged as a blocked step.
Agents connect as desk_agent, which has no permission on refunds, outgoing messages or decisions. The forbidden write has no code path, and a test proves the database refuses it.
Deterministic checks on the output, against the database rather than against what the model claims it saw.
The only path that refunds or sends. Re-validates, locks the row, records who decided.
Who may touch what
The real permissions, table by table. Red is the point of the design: the agents cannot move money or send anything.
| Table | Agents (desk_agent) | API and approvals (desk_api) | Dashboard (anon) |
|---|---|---|---|
customers, orders the store | read | read | no access |
refunds money out | read only, ✕ no write | read · write | no access |
outbound_messages replies sent | ✕ no access | read · write | no access |
proposals what agents want | create · update own | approve · reject | read |
tickets incoming messages | create · update own | read · write | read |
jobs the queue | create · update own | read · write | read |
runs, run_steps what agents did | read · write | read | read |
audit_log who decided what | create · update own | read · write | read |
Defined in supabase/migrations/ and proven by tests/test_governance.py, which connects as the agents' role and checks that the database refuses every forbidden write.