A write reaches your database only when the server allows writes, the caller's grant allows this query, the values pass their checks, and the SQL is the kind of write the key may do. An agent's write also waits for a person to approve it. Any one of them can refuse, before the database is touched.
Run history: every write, with its key, its rows, and for an agent approved_byWrite requests: each agent request, kept 30 daysAudit log: approvals, rejections and every grant change
Stablecompatibility promiseExpmay change in a minor releaseSaving a write query needs no permission; running one does.
Who writesPartners, signed-in people, AI agentsA partner's key, a person's sign-in token, or an agent over MCP, each calling one saved write query.
↓
The governed coreServer → grant → values → SQL guardWrites are off until the server allows them. A grant opens one query for one caller, the values are checked and bound, and the SQL must be the kind of write the key may do. Any one refuses, before the database is touched.
↓
Only for agents StableA person approvesAn agent's first call writes nothing. Someone else approves the exact arguments, within 15 minutes, and the write runs once, rolled back past its row ceiling.
↓
Your databaseThe write commits
↓
The recordRun history, write requests, auditEvery write with its key; an agent's with who approved it.
whokey acme-ordersdoorPOST /q/acme_submit_orderserver allows writes ✓this one query only ✓sku, qty typed and bound ✓dataPostgreSQL · shop
For operational workflows
Let a partner or a form write, through one approved query
Sometimes the job is putting data in: a partner submitting orders, a form filing a request, a support lead correcting a record. Writing is off by default at every level, and you open one query, for one caller, and nothing else.
✓QUERYAPIGATE_ALLOW_WRITES is the server-wide ceiling: until it is set, nothing writes, whatever a key says.
✓A key or role writes only with allow_writes, which allowed_write_ops can narrow to insert, update or delete.
✓Or make exactly one saved query writable for one key. Every other query, and ad-hoc SQL, stays read-only.
✓Values are typed and bound, never SQL, and every write is in the run history. For AI agents, each write waits for a person to approve it.
The example APIs ship with a generated database and one scoped key per scenario, so you can try each of these in a few minutes without connecting anything of your own.