When a BUG ticket comes in, the patch agent can ask a connected database for a few SELECTs to understand the actual state of the row a customer is complaining about. This page is what an operator (you) sees and does with that flow. The setup is in the admin guide; you only need this page once an admin has connected and enabled the integration.
The connector is read-only. It cannot write, alter, or delete; the database engine itself rejects anything that isn't a SELECT inside a READ ONLY transaction.
What you see on a BUG ticket
If the connector ran any queries during triage, the QA notes on the ticket include a section titled Database diagnostics (read-only). Each query the agent ran shows up as:
- A one-line reason — why the agent wanted that data.
- A small markdown table with up to 10 rows of result.
- Metadata: row count, whether it was
truncated(more rows existed but the 50-row / 64 KB cap fired), which columns wereredacted, and the query duration.
If a proposed query was blocked, you'll see a placeholder line instead:
(awaiting approval) <reason> — proposed query touches <tables>— the AI wants to run a new shape; it's queued for you to approve.(blocked: <code>) <sql>— the SQL guard rejected it (e.g. forbidden keyword, schema not on the allowlist). No approval will help here; the agent has to rephrase or you take it offline.(failed: <code>) <reason>— the query ran but the engine returned an error (timeout, lock, read-only violation).
The agent treats the connector as additive context. If it's gated off, returns nothing, or every query is blocked, triage continues on the rest of the ticket — no derailment.
Approving a query shape
Open Settings → Integrations → Database → Pending approvals. The queue shows every shape the AI has proposed but never had approved.
A "shape" is the structure of the query, not a specific run. Once you approve SELECT id, status FROM orders WHERE id = $1, every future query that hashes to the same shape — same SQL with any literal value — runs automatically. That's deliberate: bug triage tends to hit the same query against many different keys.
Each row shows:
- The reason the agent gave for proposing it.
- The tables the query touches.
- An amber sensitive-data hint if any touched table name matches an obvious sensitive pattern (
users,customers,payments,tokens, …). The hint is advisory; the runtime redactor catches column-level sensitive data on its own. - The full shape sample — the SQL with literals blanked. This is exactly what gets cached when you approve.
- The shape hash (first 12 chars).
Use the tabs to flip between pending, active, and revoked.
- Approve moves the row to active. The next agent run that matches this shape executes it.
- Revoke (on an active row) marks the shape revoked. Future runs of that shape will be re-queued as pending; the revoke reason you supply is preserved for audit.
What you should not approve:
- Queries that touch tables you'd never paste into a chat with a junior dev.
SELECT *against a wide table (the column-name redactor does its best, but you're better off asking the agent to name columns).- Anything that crosses tenants or trust boundaries you maintain inside the database.
What the AI cannot do
Even with the integration on and a shape approved:
- It cannot write, update, delete, or DDL — the engine-level READ ONLY transaction is the primary defence; the SQL guard is the second.
- It cannot read schemas or tables outside the configured allowlist.
- It cannot return more than 50 rows or 64 KB per query.
- It cannot see columns whose name looks like
email,phone,password,token,ssn,iban, etc. — these come back as[redacted]and the redacted column names are recorded on the audit row. - It cannot bypass the per-shape gate unless an admin has explicitly turned on Auto read-only diagnostics, which trades the human-in-the-loop step for speed but keeps every other safeguard in place.
When to step in
- The diagnostics block is full of
(awaiting approval)lines and the ticket is stuck → walk through the queue and approve or revoke each shape. - A shape you previously approved is being abused (different reason, suspicious tables) → revoke it. The agent will queue a fresh proposal next time.
- The integration shows Read-only not verified → that's an admin task; the connector won't let the AI use it until the engine confirms the role can't write.
If you want a paper trail without opening the DB, every query the connector ran appears in the audit log (event names start with database.query.) with the issue ID, shape hash, redacted column list, and duration.