Das Urteil vor der Query.

Nein. Veto verbindet sich nie mit deiner Produktiv-Datenbank. Kosten- und Plan-Schätzungen laufen auf einem wegwerfbaren Scratch-Postgres innerhalb einer Transaktion, die immer zurückgerollt wird.

Nein. Das Urteil wird von deterministischen Regeln und Query-Plan-Analyse erzeugt — nicht von einem Modell. Gleicher Input liefert immer das gleiche Urteil.

Verbinde dich über MCP unter /mcp und stelle das analyze_sql-Tool bereit. Dein Agent fragt ein Urteil an, bevor er irgendein Statement ausführt.

Beides — es kommt darauf an, wie du es einbindest, und das sagen wir lieber offen. Das Urteil ist deterministisch: gleiches SQL liefert immer dasselbe ok / warn / block, ohne LLM im Loop. Standardmäßig ruft dein Agent analyze_sql auf und entscheidet selbst, was er mit der Antwort macht — also ist es beratend, ein deterministisches Sicherheitsnetz, kein Interceptor im Datenpfad. Um es verbindlich zu machen: lass deine CI bei den stabilen Finding-IDs gaten (Build bei einem block fehlschlagen lassen) und weise deinen Agenten an, immer zuerst zu prüfen. Ein Proxy, der jedes Statement zwingend durch Veto schickt — nicht umgehbar, selbst von einem fehlerhaften Agenten — ist auf der Roadmap. Veto ist genau so verbindlich wie der Schritt, in den du es einbaust.

Dein SQL — und dein Schema-DDL, falls du es für die Kostenanalyse angibst — wird über TLS an den gehosteten Endpoint gesendet, im Speicher analysiert und verworfen. Wir speichern nur Analytics-Metadaten: das Urteil, welche Regel-IDs ausgelöst haben, ob ein Schema angegeben wurde und die Latenz. Niemals dein SQL, dein Schema oder deine Tabellennamen. Self-Hosting, das Egress vollständig eliminiert, ist auf der Roadmap.

Destruktive Statements (ungescopte DELETE/UPDATE, DDL-Drops, in CTEs versteckte Anweisungen), Korrektheitsfallen (NULL-Vergleiche wie = NULL, NOT IN mit einer Subquery, LEFT JOINs, die still zu Inner Joins werden) und Kostenrisiken (große Sequential Scans, fehlende Indizes). Der Scope ist bewusst eng und zuverlässig statt breit und schwammig.

Nein. Die Regeln sind reines Postgres — jede Datenbank (Supabase, Neon, RDS, self-hosted) und jedes Migrations-Tool. Auf echten Migrationen getunt: Routine-DROP POLICY / DROP INDEX / DROP FUNCTION und lock-leichte ALTERs (RLS aktivieren, eine nullable Spalte hinzufügen) kommen als ok oder warn zurück — nur echter Datenverlust (DROP TABLE, TRUNCATE, ungeschütztes DELETE/UPDATE) blockt. Ein Schutzmechanismus, den du tatsächlich eingeschaltet lässt.

Ein Pro-Feature, das Veto von einem Linter zu einer Governance-Schicht macht. Die eingebauten Regeln sind für alle gleich — sie wissen nicht, dass payments in deiner Datenbank heilig ist. Benutzerdefinierte Policies lassen dein Team eigene Regeln hinzufügen ("niemals DELETE aus payments", "kein TRUNCATE auf audit_*"), und Veto setzt sie zusätzlich zu den eingebauten durch. Policies sind deklarative Daten — validiert, nie ausgeführt — damit das Sicherheits-Tool nicht selbst zum Injection-Loch wird.

Sag es deinem Agenten in einfacher Sprache, und er erzeugt das deklarative JSON und ruft das Tool set_policies mit deinem Pro-Key auf. Richtlinien werden am Key gespeichert, sodass jeder spätere analyze_sql-Aufruf mit diesem Key sie automatisch durchsetzt — kein Web-Login, keine Konfiguration pro Aufruf.