SQL-Schutzschicht für KI-Agenten — Destruktive Queries vor der Ausführung blockieren
Die SQL-Schutzschicht für KI-Agenten fängt gefährliche Statements (DROP, TRUNCATE, Massen-DELETE/UPDATE ohne WHERE, Full-Table-Scans, massenhafte Datenausgaben) ab, bevor sie Ihr MySQL, PostgreSQL oder Cloudflare D1 erreichen. FutrixData kombiniert statisches Regel-Matching mit vorgelagerten EXPLAIN-Probes — derselbe SELECT kann bei einem indizierten Lookup low risk sein und medium risk, sobald der Plan einen breiten Scan offenbart (z. B. eine Abfrage über 100.000 Zeilen).
Was „SQL-Schutzschicht“ im KI-Kontext bedeutet
Datenbankrechte beantworten „wer darf sich verbinden, wer darf lesen oder schreiben“. Agenten bringen ein feinkörnigeres Problem: Unter einer Verbindung tragen verschiedene Statements stark unterschiedliches Risiko. SELECT * FROM orders WHERE id = 1001 ist ein Point-Lookup; SELECT * FROM orders ist ein Kunden-Datendump. Die Schutzschicht ist die Zwischenschicht, die beide unterscheidet.
Vier Risikokategorien
- Destruktive Operationen.
DROP TABLE,TRUNCATE,DELETE/UPDATEohneWHERE— standardmäßig blockiert. - Breite Queries. Full-Table-Scans, fehlende Indizes, hohe geschätzte Scan-Zeilen, tiefe Joins — durch die vorgelagerte
EXPLAIN-Probe eskaliert. - DDL.
ALTER,CREATE, Index-Drops — Warn oder Approval, je nach Tabelle. - Privilegien-Änderungen.
GRANT,REVOKE— sofort blockiert.
Zwei-Schichten-Bewertung: statische Regeln + vorgelagertes EXPLAIN
Statische Regeln fangen das Offensichtliche ab (kein WHERE, Zieltabelle ist audit_logs usw.). Die Probe fängt, was ein Parser nicht sieht: ob die Query tatsächlich einen Index nutzt. FutrixData eskaliert das Risiko, wenn:
- Kein Index getroffen wird.
- Scan-Zeilen den konfigurierten Schwellenwert überschreiten.
- Der Explain-Plan nicht verfügbar oder nicht verifizierbar ist.
- MySQL: Full-Table-Scan, temporäre Tabelle, filesort, abhängige Subquery, teurer Join.
- PostgreSQL: sequentieller Scan, tiefe Subpläne, Sortierung großer Result-Sets.
- D1:
SCAN-Stages, Base-Table-Scans nach View-Expansion.
Probes erhöhen das Risiko nur; sie stufen eine bereits als high risk klassifizierte Operation nicht herab.
Eingebaute MySQL-/PostgreSQL-/D1-Regeln
| Statement | Standardaktion |
|---|---|
SELECT, SHOW, DESCRIBE, EXPLAIN | allow |
INSERT, REPLACE, UPDATE … WHERE, DELETE … WHERE | warn |
UPDATE / DELETE ohne WHERE | block |
CREATE, ALTER | warn |
DROP, TRUNCATE, GRANT, REVOKE | block |
Eigene Regeln überschreiben die eingebauten kraft präziseren Scopes und höherer Priorität. Beispiel: UPDATE standardmäßig nur warnen, aber jedes DELETE auf orders in der Produktion verbieten.
Trust-Modi
Trust-Modi pro Quelle entscheiden, was programmatische Eintrittspunkte (Agent, MCP, Skill, CLI) automatisch ausführen können.
| Modus | Verhalten |
|---|---|
| Approval | Jede Ausführung erfordert menschliche Bestätigung. |
| Cautious | Standard. Nur Low-Risk-Statements werden automatisch ausgeführt. |
| Trusted | Low- und Medium-Risk auto; High Risk erfordert weiterhin Bestätigung. |
| Danger | Alles wird automatisch ausgeführt, einschließlich Operationen, die normalerweise blockiert wären. Nur für Wegwerf-Testdaten empfohlen. |
Wie Approval funktioniert
Trifft ein Agent auf ein require_approval-Ergebnis, gibt der Proxy eine strukturierte Antwort zurück, die die getroffene Regel und das geparste Statement beschreibt. Der Aufrufer muss die Anfrage mit approve: true erneut absenden. Die Approval wird auf der Eintrittsschicht verifiziert — Agenten können nicht einfach approve: true in einen beliebigen Aufruf einschleusen, um die Interception zu umgehen.
Beispiele
// Agent attempts:
DELETE FROM users;
// FutrixData response:
{
"ok": false,
"risk": "block",
"rule": "sql.delete_without_where",
"reason": "DELETE without WHERE clause on table users",
"data_source": "prod-postgres",
"audit_id": "audit_01HQ7M..."
}// Caller reissues:
{
"statement": "DELETE FROM users WHERE last_login < now() - interval '5 years'",
"approve": true,
"approval_reason": "scheduled GDPR purge, ticket OPS-2189"
}Häufig gestellte Fragen
Was blockiert FutrixData standardmäßig auf SQL-Datenquellen?
DROP, TRUNCATE, GRANT, REVOKE sowie UPDATE/DELETE ohne WHERE. Alles andere landet auf allow (Reads) oder warn (Writes / DDL); der Trust-Modus entscheidet, ob Warns Approval erfordern.
Bekomme ich False Positives auf legitimen Queries?
Die statischen Regeln sind bewusst eng gefasst — destruktive Operationen und Missing-WHERE-Muster. Die vorgelagerte EXPLAIN-Probe ist die feinere Schicht; Schwellenwerte (max. Scan-Zeilen, max. Joins) sind pro Quelle konfigurierbar (für bestimmte kleine Tabellen, bei denen der Optimizer ohnehin einen Seq Scan wählt, lässt sich eine Ausnahme für die Full-Table-Scan-Zeilenanzahl setzen).
Kann ich einen Block überschreiben?
Ja — für warn / require_approval reicht der Aufrufer die Anfrage mit approve: true und einer Begründung erneut ein, die im Audit-Log landet. Harte block-Regeln (z. B. DROP in der Produktion) erfordern eine Konfigurationsänderung, kein Per-Call-Override; das ist gewollt.
Funktioniert das mit raw SQL oder nur mit ORMs?
Raw SQL. FutrixData parst MySQL-, PostgreSQL- und D1-Syntax direkt, um Command-Typ, Zieltabelle, WHERE-Vorhandensein, Joins und Subqueries zu extrahieren. ORMs, die raw SQL emittieren, sind transparent abgedeckt.
Wie unterscheidet sich die MySQL-Behandlung von PostgreSQL?
Der statische Regelsatz ist gleich. Die Probes unterscheiden sich: MySQL inspiziert Full-Table-Scans, temporäre Tabellen, filesort, abhängige Subqueries und Join-Row-Estimates. PostgreSQL inspiziert sequentielle Scans, Join-Anzahl, Subpläne und große Result-Set-Sorts. D1 inspiziert SCAN vs SEARCH und validiert Base-Table-Scans nach View-Expansion.
Erzeugt das vorgelagerte EXPLAIN Latenz?
Ja — typischerweise ein zusätzlicher Round-Trip zur Datenbank, bevor die echte Query läuft. Bei Point-Lookups sind das Millisekunden; bei Queries, die das Explain nicht passieren, übersteigt die eingesparte Latenz die Probe-Kosten bei weitem.
Probieren Sie FutrixData mit Ihrer eigenen Datenbank aus
Kostenlose Desktop-App für macOS, Windows und Linux. Self-hosted Enterprise Edition für produktive Deployments.