AI-Database-Proxy: Ein Gateway für KI-Agenten und Ihre Datenbanken
Ein AI-Database-Proxy sitzt zwischen KI-Agenten (Claude Code, Cursor, Codex, OpenCode, eigene MCP-Clients) und Ihren Datenbanken. Er erzwingt Maskierung, Query-Guardrails, Identität und Audit bei jedem Aufruf — Agenten bleiben produktiv, ohne dass eine Fehlbedienung Ihre kritischen Datenbestände beschädigt.
Was ist ein AI-Database-Connection-Proxy?
Ein AI-Database-Proxy ist ein Dienst, der jeden Datenbankaufruf eines KI-Agenten vermittelt — und das Muster ablöst, bei dem jeder Agent seine eigenen Datenbank-Zugangsdaten hält. Er nimmt Queries entgegen (SQL, Mongo, Redis-Befehle, Elasticsearch DSL, ChromaDB), bewertet sie gegen Policies, führt sie auf der echten Datenbank aus und liefert verarbeitete Ergebnisse an den Agenten zurück.
Der Database-Proxy ist der Ort, an dem Sie die Kontrollen platzieren, die die Datenbank selbst nicht ausdrücken kann:
- Eigene Identität pro Agent statt geteilter DB-Zugangsdaten, mit agentenspezifischem Widerruf und Audit-Zuordnung.
- Query-Guardrails, die ein Statement vor der Ausführung als low / medium / high risk klassifizieren — nicht erst danach.
- Feldebene-Maskierung auf dem Agenten-Ergebnispfad — sensible Werte werden durch stabile, secret-basierte pseudonyme Hash-Werte ersetzt, bevor die Zeile an MCP-/Skill-/CLI-Aufrufer zurückgeht.
- Lokale, hash-verkettete Audit-Logs (mit eingebautem
audit verify-CLI), die beantworten: „Welcher Agent hat was, wann ausgeführt und warum war es erlaubt?“. Nur lokale Verifikation — siehe Trust und Limitations für den Umfang.
Warum KI-Agenten einen Proxy brauchen
Einem LLM rohe Verbindungs-Secrets zu übergeben ist schnell aufgesetzt — und leicht zu bereuen. Sechs Risiken zeigen sich in Produktion:
- Destruktive Queries. Agenten halluzinieren. Aus „alte Zeilen aufräumen“ wird
DELETE FROM users, ohne dass jemand wach genug ist, es abzufangen. - Credential-Leaks. Connection-Strings landen in Prompts, Logs und Trace-Exports — und schließlich in den Trainingsdaten anderer.
- PII an Drittanbieter-Modelle. Kundennamen, Kartennummern und biometrische Daten werden in Prompts serialisiert und an das jeweils genutzte LLM gesendet.
- Kein Audit-Trail. „Ein Agent war's“ ist keine Antwort, die Ihr Incident-Review oder Compliance-Prüfer akzeptieren wird. Sie brauchen wer, was, wann und warum-erlaubt — schriftlich an einem Ort, den Sie später verifizieren können.
- Jeder Agent hat zu weitreichende Rechte. Agenten erben Entwickler-Credentials — meist Lese-/Schreibrechte auf jeder Tabelle. Das Least-Privilege-Prinzip gilt nicht mehr, wenn ein Chatbot
TRUNCATE/DELETEausführen kann. - Umgekehrt: jeder Agent hat zu enge Rechte. Sind die Rechte jedes Agenten zu schmal, kommt die Automatisierung nie aus den Startlöchern: Aufgaben hängen an manuellen Freigaben statt durchzulaufen.
Wie FutrixData den Proxy implementiert
Jede Datenbankoperation läuft über einen einzigen Execution-Manager. Statische Regeln und datenbankspezifische Probes bewerten sie, bevor der Datenbank-Adapter überhaupt läuft.
Der vollständige Ablauf:
- Der Agent sendet eine Query über MCP, Skill oder CLI.
- FutrixData löst die Datenquelle auf, parst das Statement und gleicht es gegen statische Regeln ab.
- Für SQL, MongoDB und D1 prüft eine vorgelagerte
EXPLAIN-Probe Scan-Zeilen, Index-Nutzung und Joins. Für Elasticsearch, ChromaDB, DynamoDB und Redis greift eine statische Risk-Engine-Analyse. - Das kombinierte Risiko-Level (allow / warn / require_approval / block) wird mit dem Trust-Modus pro Quelle (Approval / Cautious / Trusted / Danger) abgeglichen.
- Der Datenbank-Adapter führt aus, Ergebnisse werden Feld für Feld maskiert, und ein Audit-Eintrag wird geschrieben.
CLI, MCP, Skill und der In-App-AI-Chat teilen sich alle dieselbe Service-Layer-Policy — sie können nicht auseinanderlaufen.
Was FutrixData auf der Proxy-Ebene erzwingt
| Risiko | Mechanismus |
|---|---|
| Credential-Exposition | Connection-Strings liegen auf dem FutrixData-Host. Agenten sehen sie nie. |
| PII in Prompts | L1–L5-Sensitivitätsklassifikation + secret-basierte deterministische HMAC-Maskierung auf dem Agenten-Ergebnispfad. |
| Destruktive Queries | Eingebaute Block-Regeln pro Datenbank (SQL, Mongo, Redis, ES, DynamoDB). |
| Breite Queries | Vorgelagertes EXPLAIN eskaliert das Risiko bei Full-Table-Scans, fehlenden Indizes und tiefer Paginierung. |
| Identität | Access-Keys pro Agent; Widerruf erfolgt sofort und bewahrt die Historie. |
| Audit | Jeder Aufruf protokolliert Agent, Quelle, Ziel, Statement, Ergebnis und passende Regel. |
Unterstützte Datenbanken
FutrixData proxyt MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, ChromaDB, DynamoDB und Cloudflare D1 über eine einzige Schnittstelle. Jeder Datenbanktyp hat seinen eigenen Parser, Regelsatz und Probe — Redis wird nicht als SQL mit ersetzten Strings behandelt.
Beispiele
{
"mcpServers": {
"futrixdata": {
"command": "futrixdata",
"args": ["mcp"],
"env": {
"FUTRIXDATA_AGENT_KEY": "fxd_live_..."
}
}
}
}Häufig gestellte Fragen
Was ist ein AI-Database-Proxy für intelligente Agenten?
Ein Dienst, der jeden Datenbankaufruf eines KI-Agenten abfängt, organisationsweite Policies (Maskierung, Guardrails, Identität, Audit) anwendet und nur die sicheren Operationen an die zugrundeliegende Datenbank weiterleitet. Der Agent sieht den Proxy; die Datenbank sieht nur den Proxy.
Warum sollten KI-Agenten sich nicht direkt mit meiner Datenbank verbinden?
Sie können — aber dann werden sie früher oder später eine Tabelle DROPpen, einen Connection-String leaken, PII an OpenAI oder ein anderes LLM senden oder durch Prompt-Injection an Angreifer preisgeben. Direkte Verbindungen geben Agenten alle Rechte, die der Entwickler hat — ohne agentenspezifische Identität, ohne feingranulare Kontrolle der ausgeführten Statements, ohne Ergebnismaskierung und ohne zentralen Audit-Trail. FutrixData ist der Ort, an dem die Kontrollebene sitzt, die die Datenbank selbst nicht abbildet. Siehe Trust für die Datenpfade und Limitations für das, was das Gateway nicht abdeckt.
Ist FutrixData ein MCP-Server?
FutrixData spricht MCP, Skill und CLI. Aus Sicht von Claude Code oder Cursor sieht es wie ein MCP-Server aus. Intern ist es ein vollwertiges Daten-Gateway — die MCP-Oberfläche ist einer von mehreren Eintrittspunkten, die alle dieselbe Risk-Engine und dieselbe Audit-Pipeline nutzen.
Erzeugt der Proxy Latenz?
Bei einem indizierten Point-Read gegen MySQL oder PostgreSQL wird der Overhead von Parsing und Regel-Matching dominiert — typischerweise wenige Millisekunden. Das vorgelagerte EXPLAIN läuft nur bei SQL-/Mongo-/D1-Reads, bei denen der Zugriffspfad relevant ist; Redis-Befehle erhalten lediglich eine statische Prüfung gefährlicher Commands. In der Praxis ist das Latenz-Budget gegenüber dem ohnehin teuren LLM-Round-Trip vernachlässigbar.
Welche KI-Agenten funktionieren mit FutrixData?
Claude Code, Cursor, Codex (CLI), OpenCode, Windsurf und jeder eigene MCP-/Skill-kompatible Agent. Eingeschlossen sind LangChain-basierte Stacks und maßgeschneiderte Automatisierungs-Agenten.
Kann ich es im internen Netzwerk selbst hosten?
Ja. Die FutrixData Enterprise Edition läuft als ein einziges Docker-Image innerhalb Ihres Netzwerks — keine Datenbank-Credentials verlassen Ihren Produktionsrahmen. Siehe self-hosted für Deployment-Details.
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.