Docs

Verbinde Veto mit deinem Agenten

Veto ist ein MCP-Server. Richte deinen KI-Coding-Agenten auf den Endpoint aus, und er kann vor jeder SQL-Ausführung ein deterministisches Verdict anfordern. Kein SDK, keine Datenbankverbindung, kein API-Key für den kostenlosen Tarif nötig.

MCP endpoint · Streamable HTTP · https://vetosql.com/mcp

1. Den MCP-Server hinzufügen

Veto spricht das Model Context Protocol über Streamable HTTP. Füge es mit einem einzigen Eintrag zu jedem MCP-fähigen Client hinzu (Claude Code, Cursor, Cline, …):

{
  "mcpServers": {
    "veto": { "url": "https://vetosql.com/mcp" }
  }
}

In Claude Code kannst du auch claude mcp add --transport http veto https://vetosql.com/mcp ausführen. In Cursor fügst du dasselbe JSON unter Settings → MCP hinzu. Das ist die komplette Einrichtung für den kostenlosen Tarif.

2. Das analyze_sql-Tool

Dein Agent ruft analyze_sql auf, bevor er ein Statement ausführt. Eingaben:

Es liefert ein strukturiertes Ergebnis zurück: ein Gesamt-verdict plus eine Liste von findings, jeweils mit einer stabilen punktierten ID (z. B. destructive.delete_without_where), an der deine Pipeline verzweigen kann. Dasselbe SQL ergibt immer dasselbe Verdict — es ist kein LLM im Spiel.

3. Verdicts

4. Den Check verpflichtend machen (optional)

Standardmäßig fragt dein Agent analyze_sql nach einem Verdict und entscheidet selbst, was er damit tut — Veto ist also beratend, ein deterministisches Sicherheitsnetz statt eines Interceptors im Ausführungspfad. Um es verbindlich zu machen:

• Lass deine CI bei den Finding-IDs gaten. Die IDs sind stabil (z. B. destructive.delete_without_where), sodass ein Pipeline-Schritt den Build immer dann fehlschlagen lassen kann, wenn ein Verdict block ist.
• Weise deinen Agenten an, analyze_sql vor jedem Statement aufzurufen und sich zu weigern, irgendetwas auszuführen, das als block zurückkommt.

Ein Proxy, der jedes Statement zwingend durch Veto schickt — sodass er nicht umgangen werden kann, selbst von einem fehlerhaften Agenten — ist auf der Roadmap.

5. Pro: Authentifizierung

Pro erhöht dein Rate-Limit und schaltet eigene Org-Policies frei. Authentifiziere dich, indem du deinen Key als Bearer-Token am MCP-Endpoint sendest:

{
  "mcpServers": {
    "veto": {
      "url": "https://vetosql.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_PRO_KEY" }
    }
  }
}

6. Pro: eigene Org-Policies

Die eingebauten Regeln wissen nicht, dass payments in deiner Datenbank heilig ist. Mit eigenen Org-Policies kann dein Team Regeln pro Tabelle hinzufügen, die Veto zusätzlich zu den eingebauten Regeln durchsetzt. Dein Agent kann das JSON aus einer Anweisung in natürlicher Sprache erstellen und das set_policies-Tool mit deinem Pro-Key aufrufen:

[
  { "table": "payments", "operations": ["delete", "truncate"], "action": "block",
    "message": "Never delete from payments." },
  { "table": "audit_*", "operations": ["truncate"], "action": "block" }
]

Policies werden auf deinem Key gespeichert, sodass jeder spätere analyze_sql-Aufruf mit ihm sie automatisch durchsetzt — keine Konfiguration pro Aufruf. Sie sind deklarative Daten: validiert, per Glob (nicht Regex) abgeglichen und niemals ausgeführt.

7. Gut zu wissen

• Verbindet sich nie mit deiner Datenbank. Die Kostenanalyse läuft auf einem wegwerfbaren Scratch-Postgres innerhalb einer Transaktion, die immer zurückgerollt wird.
• Deterministisch. Gleiche Eingabe, gleiches Verdict — testbar und auditierbar, ohne Model-Drift.
• Postgres-nativ. Funktioniert mit Supabase, Neon, RDS oder self-hosted, und mit jedem Migrationstool.

Mehr Hintergrund findest du in den FAQ und im Blog.