Database connector — for operators

The database connector lets FixControl look at a Postgres database of yours while it works on a BUG ticket, so its reasoning can start from the real shape of your data instead of only the ticket text. This page explains what that means for you as an operator. Connecting the database is described in the admin guide.

What has to be on

Two switches, both off by default, have to be on before the AI gets anything from a database:

1. The connector itself — a setting for the whole FixControl deployment, switched on by whoever runs your FixControl. While it is off, no database context reaches the AI, whatever you configure.
2. Allow AI database context — a switch per connection on Settings → Channels → Database (read-only). A connection also needs status connected and at least one schema on its allowlist; with an empty schema allowlist the AI may read nothing.

Managing connections and approvals needs the admin or manager role.

Connect with a database role that can only read. FixControl runs everything inside a read-only transaction and checks every query, but a read-only role is the safeguard you control yourself. Test connection on the connection's card shows Read-only verified ✓ when Postgres refused a test write; Read-only not verified means that check has not passed yet, and you should fix the role before you rely on the connection.

What the AI gets today

When both switches are on and a patch is checked on a BUG issue, FixControl adds a short note to the context of that check:

• that a database connector is available, with the connection's name;
• the schemas on the allowlist that the AI may read;
• up to 20 table names from the first of those schemas.

That is all, for now. No queries run against your database today. The flow in which the AI proposes its own diagnostic queries is not switched on yet: nothing in FixControl proposes queries at the moment, so no query results reach the AI and nothing appears in the approval queue during normal use. The connector is additive: if it is off, finds nothing, or fails, work on the ticket continues without it.

The query approval queue

The approval flow for queries already exists, so it is ready once query proposals are switched on. You find it under Settings → Channels → Database (read-only) → Pending approvals →, on the page Query approvals.

How it is meant to work:

• An approval covers a query shape: the structure of the query, with literal values blanked. Once you approve SELECT id, status FROM orders WHERE id = $1, the same query with any other id runs without asking again.
• Each row shows the reason given for the query, the tables it touches, the shape itself, and the first 12 characters of the shape hash. A table name that suggests sensitive data (users, customers, payments, tokens and similar) adds an amber warning.
• Use the pending, active and revoked tabs to switch lists. Approve moves a pending shape to active. Revoke stops an active shape; you can give a reason, which is kept for audit.

When reviewing, don't approve queries on tables you would not paste into a chat with a junior developer, SELECT * on wide tables, or anything that crosses boundaries you keep inside the database.

Auto read-only diagnostics (skip per-shape approval) on a connection removes the per-shape approval step for that connection. Every other safeguard below still applies, and every query is still audited. Leave it off unless you have a clear reason.

What the connector can never do

Whatever is switched on:

• No writes. Everything runs in a read-only transaction, and the SQL guard refuses anything that is not a single read query. Your read-only database role is the extra layer underneath.
• Nothing outside the allowlists. Schemas and tables that are not on the connection's allowlists cannot be read.
• Limited results. At most 50 rows and 64 KB per query, with a 5-second time limit, and a short lock timeout so a query never holds up your own traffic.
• Sensitive columns are hidden. A column is returned as [redacted] when a part of its name is a sensitive term such as email, phone, password, secret, token, api_key, ssn, iban or card_number. The match is on name parts, so email, customer_email and user_password are all hidden, while a name that merely contains the letters, such as tokenizer, is not.

When to step in

• The AI never mentions your database → check that whoever runs your FixControl has switched the connector on, that Allow AI database context is on, that the connection is connected, and that at least one schema is on the allowlist. Remember that only BUG issues use the connector.
• Read-only not verified → have an admin connect with a role that cannot write, then click Test connection again.
• A shape you approved earlier no longer looks right → revoke it on Query approvals.

Everything the connector does is recorded in the audit log: assembling database context (database.context.assembled), approvals (database.approval.*) and, once queries run, every query (database.query.*) with the issue, shape hash, redacted columns and duration.

Related

• Database connector — admin guide — connecting the database and setting the allowlists.
• Approvals — the other approval flows in FixControl.