Zuerst parsen
SQL wird nicht direkt an den Datenbanktreiber weitergegeben, sondern durch einen strukturierten Parser geführt.
SQL-Compiler
Behandeln Sie KI-generiertes SQL als nicht vertrauenswürdige Eingabe.
hs-sql-agent parst SQL in eine typisierte Compiler-Pipeline, validiert Quellsemantik und Richtlinien, prüft die Fähigkeiten des Ziels und erzeugt erst danach providerspezifisches SQL.
Fähigkeiten prüfen
Nicht nachweisbare Quell- oder Zielsemantik wird abgelehnt statt stillschweigend abgeschwächt.
Pro Provider kompilieren
Datenbankspezifisches Verhalten bleibt innerhalb einer klaren Ausführungsgrenze.
Generiertes SQL ist Eingabe, keine Berechtigung
Ein LLM kann SQL vorschlagen. Dass eine Datenbank dieses SQL parsen könnte, macht es aber noch nicht ausführbar. hs-sql-agent setzt zwischen Modell und Verbindung eine Compiler- und Richtliniengrenze.
Die Pipeline lehnt bei Unsicherheit ab: Eine Anweisung, die nicht sicher dargestellt oder nachgewiesen werden kann, wird zurückgewiesen und nicht nur für die Ausführbarkeit in eine andere Bedeutung umgeschrieben.
Ein typisierter Ausführungspfad
Queries durchlaufen Parsing, Binding, Validierung, Capability-Prüfung, providerspezifische Kompilierung und die Ausführung eines unveränderlichen Commands. Richtlinien können dadurch auf einer strukturierten Anweisung statt nur auf rohem SQL-Text arbeiten.
- Validierung von Queries mit genau einer Anweisung
- Tabellenautorisierung und Query-Richtlinien
- Capability-Grenzen für Quell- und Zieldialekte
- providerspezifisches Rendering erst nach erfolgreicher Validierung
SQL-Unterstützung erweitern, ohne die Sicherheitsgrenze aufzuweichen
Neue Syntax gilt erst dann als unterstützt, wenn Parser, typisiertes Modell, Validierung, Capability-Nachweise, Renderer und Tests ihre Semantik vollständig abbilden. So kann die SQL-Abdeckung wachsen, ohne das Prinzip der Ablehnung bei Unsicherheit zu schwächen.