Database-connector — voor operators

Met de database-connector kan FixControl in een Postgres-database van jou kijken terwijl het aan een BUG-ticket werkt, zodat het redeneren begint bij de echte vorm van je data in plaats van alleen bij de tekst van het ticket. Deze pagina legt uit wat dat voor jou als operator betekent. Het koppelen van de database staat in de admin-handleiding.

Wat er aan moet staan

Twee schakelaars, allebei standaard uit, moeten aan staan voordat de AI iets uit een database krijgt:

1. De connector zelf — een instelling voor de hele FixControl-omgeving, die wordt aangezet door wie je FixControl beheert. Zolang die uit staat, bereikt er geen databasecontext de AI, wat je ook instelt.
2. Allow AI database context — een schakelaar per verbinding op Instellingen → Kanalen → Database (read-only). Een verbinding moet daarnaast de status connected hebben en minstens één schema op de allowlist; met een lege schema-allowlist mag de AI niets lezen.

Voor het beheren van verbindingen en goedkeuringen heb je de rol admin of manager nodig. De pagina's van de connector zijn nog Engelstalig; knoppen en labels staan hier daarom met hun Engelse naam.

Koppel met een databaserol die alleen kan lezen. FixControl draait alles in een read-only transactie en controleert elke query, maar een rol die alleen kan lezen is de beveiliging die je zelf in de hand hebt. Test connection op de kaart van de verbinding toont Read-only verified ✓ als Postgres een testschrijfactie weigerde; Read-only not verified betekent dat die controle nog niet is geslaagd, en dan pas je eerst de rol aan voordat je op de verbinding vertrouwt.

Wat de AI vandaag krijgt

Staan beide schakelaars aan en wordt er een patch gecontroleerd op een BUG-issue, dan voegt FixControl een korte notitie toe aan de context van die controle:

• dat er een database-connector beschikbaar is, met de naam van de verbinding;
• de schema's op de allowlist die de AI mag lezen;
• maximaal 20 tabelnamen uit het eerste van die schema's.

Meer is het op dit moment niet. Er draaien vandaag geen queries op je database. De flow waarin de AI zelf diagnostische queries voorstelt, staat nog niet aan: niets in FixControl stelt op dit moment queries voor, dus er bereiken de AI geen queryresultaten en er komt bij normaal gebruik niets in de wachtrij voor goedkeuringen. De connector is een aanvulling: staat hij uit, vindt hij niets of mislukt hij, dan gaat het werk aan het ticket zonder hem door.

De wachtrij voor query-goedkeuringen

De goedkeuringsflow voor queries bestaat al, zodat hij klaar is zodra querievoorstellen aangaan. Je vindt hem onder Instellingen → Kanalen → Database (read-only) → Pending approvals →, op de pagina Query approvals.

Zo is hij bedoeld:

• Een goedkeuring geldt voor een query-vorm (shape): de structuur van de query, met de letterlijke waarden weggelaten. Keur je SELECT id, status FROM orders WHERE id = $1 goed, dan draait dezelfde query met elke andere id zonder opnieuw te vragen.
• Elke rij toont de reden voor de query, de tabellen die hij raakt, de vorm zelf en de eerste 12 tekens van de shape-hash. Een tabelnaam die op gevoelige data wijst (users, customers, payments, tokens en vergelijkbaar) geeft een oranje waarschuwing.
• Met de tabbladen pending, active en revoked wissel je van lijst. Approve zet een openstaande vorm op actief. Revoke stopt een actieve vorm; je kunt een reden opgeven, die bewaard blijft voor audit.

Keur bij het beoordelen geen queries goed op tabellen die je niet in een chat met een junior developer zou plakken, geen SELECT * op brede tabellen, en niets dat grenzen overschrijdt die je binnen de database bewaakt.

Auto read-only diagnostics (skip per-shape approval) op een verbinding schakelt de goedkeuring per vorm voor die verbinding uit. Alle andere beveiligingen hieronder blijven gelden, en elke query wordt nog steeds vastgelegd in de audit-log. Laat dit uit tenzij je er een duidelijke reden voor hebt.

Wat de connector nooit kan

Wat er ook aan staat:

• Niet schrijven. Alles draait in een read-only transactie, en de SQL-guard weigert alles wat geen enkele leesquery is. Je databaserol die alleen kan lezen is de extra laag daaronder.
• Niets buiten de allowlists. Schema's en tabellen die niet op de allowlists van de verbinding staan, zijn niet te lezen.
• Beperkte resultaten. Maximaal 50 rijen en 64 KB per query, met een tijdslimiet van 5 seconden en een korte lock-time-out, zodat een query je eigen verkeer nooit ophoudt.
• Gevoelige kolommen zijn verborgen. Een kolom komt terug als [redacted] als een deel van de naam een gevoelige term is, zoals email, phone, password, secret, token, api_key, ssn, iban of card_number. Er wordt op naamdelen gematcht, dus email, customer_email en user_password zijn allemaal verborgen, terwijl een naam die de letters alleen bevat, zoals tokenizer, dat niet is.

Wanneer je ingrijpt

• De AI noemt je database nooit → controleer of wie je FixControl beheert de connector heeft aangezet, of Allow AI database context aan staat, of de verbinding connected is en of er minstens één schema op de allowlist staat. Onthoud dat alleen BUG-issues de connector gebruiken.
• Read-only not verified → laat een admin koppelen met een rol die niet kan schrijven en klik daarna opnieuw op Test connection.
• Een vorm die je eerder goedkeurde, klopt niet meer → trek hem in op Query approvals.

Alles wat de connector doet, komt in de audit-log: het samenstellen van databasecontext (database.context.assembled), goedkeuringen (database.approval.*) en, zodra er queries draaien, elke query (database.query.*) met het issue, de shape-hash, de verborgen kolommen en de duur.

Zie ook

• Database-connector — admin-handleiding — de database koppelen en de allowlists instellen.
• Goedkeuringen — de andere goedkeuringsflows in FixControl.