Ein sicherer Datenbank-Client für Teams (und KI-Agenten)
Die meisten Datenbank-Clients sind für einzelne Entwickler entworfen. FutrixData ist so gebaut, dass ein Team jederzeit zwei Fragen beantworten kann: „wer hat was ausgeführt“ und „wer hat welche Daten gesehen“. Dieselbe Policy gilt für Engineers in der Desktop-App und für KI-Agenten, die über MCP rufen.
Was „sicher“ bei einem Datenbank-Client bedeutet
Für ein Team, das einer Datenschutzbehörde, einem Security-Engineer oder einem internen Review Rede und Antwort stehen muss, läuft „sicherer Datenbank-Client“ auf vier Eigenschaften hinaus:
- Per-Identity-Zuordnung. Jede Query ist an einen realen User oder Agenten gebunden, nicht an einen geteilten Service-Account.
- Maskierung auf Feldebene auf dem Agenten-Ergebnispfad. Sensible Spalten werden durch stabile, secret-basierte pseudonyme Hashes ersetzt, bevor die Zeile an MCP-, Skill- oder CLI-Aufrufer zurückgeht. Die Console (autorisierter Mensch) liefert by design Rohzeilen.
- Serverseitige Guardrails. Destruktive Operationen werden durch Regeln auf dem Gateway gesteuert — nicht durch clientseitige Dialoge, die der User wegklicken kann. Konservativ auf dem Agentenpfad: Parser-Failures, Multi-Statement-Edge-Cases und unbekannte Statements eskalieren auf Approval statt auf Auto-Allow.
- Lokales hash-verkettetes Audit. Jede Zeile trägt den Hash der vorherigen Zeile; ein eingebauter
audit verify-CLI erkennt modifizierte, gelöschte, eingefügte oder umsortierte Zeilen in der Kette. Nur lokale Verifikation — siehe Limitations dafür, was nicht erkannt wird.
FutrixData liefert alle vier ab Werk.
Die Kontrollfläche
| Risiko | Mechanismus |
|---|---|
| Credential-Exposition | Connection-Strings liegen auf dem FutrixData-Host. Engineers und Agenten authentifizieren sich; sie sehen die rohen Credentials nie. |
| PII am Bildschirm / in Prompts | L1–L5-Sensitivitätsklassifikation + secret-basierte deterministische HMAC-Maskierung auf dem Agenten-Ergebnispfad. Die Console liefert Rohzeilen für autorisierte Menschen. |
| Destruktive Queries | Regelsätze pro Datenbank — DELETE/UPDATE ohne WHERE, DROP, TRUNCATE, FLUSHALL, dropDatabase, _delete_by_query usw. |
| Breite Queries | Pre-Flight-EXPLAIN auf SQL/Mongo/D1 eskaliert das Risiko bei Full-Scans, fehlenden Indizes und tiefer Paginierung. |
| Per-Identity-Zugriff | Per-User-Keys, Per-Agent-Keys; Widerruf erfolgt sofort und bewahrt die Audit-Historie. |
| Audit | Jeder Aufruf protokolliert Identität, Quelle, Ziel, Statement, Ergebnis und passende Regel. |
Compliance-Fit
FutrixData ist keine Zertifizierung — Ihre Organisation verantwortet weiterhin ihr SOC-2-, ISO-27001-, DSGVO- oder HIPAA-Programm — aber das Gateway liefert konkrete Artefakte, die die meisten Datenbank-Clients nicht produzieren:
- Ein lokales hash-verkettetes Audit-Log jedes Datenbank-Reads und -Writes, mit Identität und passender Regel, vom CLI verifizierbar. Nur lokale Verifikation — für stärkere Zusicherung in einen externen append-only Store spiegeln. Siehe Limitations.
- Dokumentierte Maskierung auf Feldebene auf PII-Spalten, standardmäßig auf dem Agenten-Ergebnispfad (MCP / Skill / CLI) angewandt; die menschliche Console bewahrt Rohwerte für autorisierte Inspektion (pro Datenquelle konfigurierbar).
- Ein Zugriffsmodell mit Identitäts-Widerruf pro User/Agent und Environment-Scoping. Team-RBAC mit Rollen, Environment- und Schema-Scopes ist ein Feature der Enterprise Edition.
- Eine selbst gehostete Deploy-Option, sodass Produktionsdaten kein Vendor-Netzwerk durchqueren.
Siehe Trust für die Datenpfad-Karte und den Capability-Status, und Limitations dafür, was das Gateway nicht ist.
Dasselbe Gateway, dieselben Guardrails — kalibriert für Menschen vs. Agenten
Die Desktop-Console (Menschen) und die MCP-/Skill-/CLI-Calls (KI-Agenten) treffen dasselbe Gateway, dieselben Query-Guardrails und dasselbe lokale hash-verkettete Audit-Log. Der einzige Punkt, an dem sich das Verhalten by design unterscheidet, ist die Maskierung:
- Console (menschliche Ad-hoc-Queries) — Rohwerte bleiben erhalten, unter der Annahme, dass ein autorisierter Engineer an der Tastatur sitzt. Die Console existiert, um echte Daten zu inspizieren.
- Agenten-Ergebnispfad (MCP, Skill, CLI) — sensible Ergebniswerte werden durch stabile, secret-basierte pseudonyme Hashes ersetzt, bevor sie an den Aufrufer zurückgehen. Schema-Metadaten sind ein separater Pfad mit eigenem Per-Datenquellen-Toggle und eigenem Audit-Record (siehe Trust).
Sie können Maskierung pro Datenquelle straffer ziehen oder lockern. Es gibt keinen separaten „AI-Modus“ mit schwächeren Guardrails — Maskierung ist der einzige Punkt, an dem sich Menschen- und Agentenpfad unterscheiden, und sie unterscheidet sich in die sicherere Richtung.
Häufig gestellte Fragen
Ersetzt das meinen bestehenden Datenbank-Client?
Für Ad-hoc-Queries, Schema-Browsing und teamweiten Query-Zugriff auf unterstützten Datenbanken — ja. Wenn Sie auf erweitertes GUI-Tooling wie ER-Diagramm-Erstellung oder vendor-spezifische Server-Admin-GUIs angewiesen sind, können Sie einen bestehenden Client neben FutrixData behalten.
Welche Datenbanken werden unterstützt?
Aktuell unterstützt: MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, ChromaDB, DynamoDB und Cloudflare D1.
Wo liegen die Credentials?
Auf dem FutrixData-Host — der Desktop-Maschine bei Soloeinsatz oder dem Gateway-Server bei Team-/Enterprise-Deployments. Sie werden nicht in geteilten Config-Files, Agenten-Prompts oder Drittanbieter-LLM-Kontext gespeichert.
Ist das Audit-Log manipulationsresistent?
Innerhalb des lokalen Scopes, ja. Das lokale Audit-Log ist hash-verkettet, und der eingebaute Befehl futrixdata-cli audit verify --json erkennt modifizierte, gelöschte, eingefügte oder umsortierte Datensätze innerhalb der Kette. Lokale Hash-Kettenverifikation erkennt Edits am bestehenden Log; externes Anchoring oder Immutable Storage ist für stärkeren Schutz gegen vollständiges lokales Log-Rewrite erforderlich. Siehe Limitations.
Kann ich das vollständig in meinem eigenen Netzwerk betreiben?
Ja. Die FutrixData Enterprise Edition ist ein Docker-Image (Compose oder Kubernetes), das Sie in Ihrer VPC betreiben. Keine Datenbank-Credentials oder Query-Bodies verlassen Ihren Perimeter. Siehe selbst gehostetes Gateway.
Wie funktioniert PII-Maskierung auf Result-Sets?
Die Standardklassifikation reicht von L1 (Public) bis L5 (Credentials / Zahlung / hochsensible personenbezogene Daten). Auf dem Agenten-Ergebnispfad (MCP / Skill / CLI) werden L4-/L5-Felder durch stabile, secret-basierte pseudonyme Hashes ersetzt, bevor die Zeile das Gateway verlässt — Analysten und Agenten sehen konsistente Hashes, ohne je Rohwerte zu sehen. Der HMAC-Schlüssel wird aus einem im OS-Secret-Store abgelegten lokalen Secret abgeleitet. Die Desktop-Console bewahrt Rohwerte standardmäßig für autorisierte Menschen. Stufen-Namen, Beschreibungen, Beispielfelder und der pro Agent zugängliche Bereich sind alle anpassbar — einschließlich des Definierens zusätzlicher Stufen über das Standard-L1–L5 hinaus. Siehe PII-Maskierung und Maskierungs-Limitations.
Sendet FutrixData Schema-Metadaten an LLM-Anbieter?
Es kann — auf den Pfaden AI-Chat, Schema-Knowledge, ER-Assistance. Schema-Metadaten können Tabellennamen, Spaltennamen, Typen, Indizes und Kommentare enthalten — ein separater Datenpfad von den Query-Result-Zeilen. Die Result-Maskierung deckt Schema-Metadaten nicht automatisch ab. Die Desktop-App exponiert pro Datenquelle einen Schalter für die Schema-an-LLM-Übermittlung, und jede Übermittlung wird als eigenes Audit-Event protokolliert. Siehe Trust für die vollständige Datenpfad-Karte.
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.