Eigene Identität pro Agent, gescopter Zugriff und ein verifizierbarer Audit-Trail
Jeder KI-Agent, der sich mit FutrixData verbindet, erhält einen eigenen Access-Key, gescopte Berechtigungen und einen lokalen, hash-verketteten Audit-Trail. Jeder Tool-Call protokolliert Agent, Quelle, Ziel, Statement, Ergebnis und passende Regel — geschrieben in eine Kette, die Sie End-to-End mit einem CLI-Befehl verifizieren können.
Eigene Identität pro Agent statt geteilter Credentials
Das Standardmuster bei rohem Datenbankzugriff ist „der Connection-String des Entwicklers“. FutrixData stellt für jeden Agenten einen eigenen Schlüssel aus: Jede Skill-Installation, jeder MCP-Client und jede CLI-Sitzung ist eindeutig identifizierbar. Der Proxy validiert den Key bei jedem Aufruf; Aufrufe ohne Key werden abgelehnt; Aufrufe mit widerrufenem Key werden abgelehnt und protokolliert.
Gescopter Zugriff
Der Zugriff eines Agenten ist auf drei Achsen eingeschränkt:
- Datenquelle. Welche Datenbanken der Agent überhaupt sehen darf.
- Risiko-Aktion. Was der Agent tun darf (read-only, write mit Approval, write auto).
- Sensitivitätsbereich. Welche Klassifikationsstufen der Agent im Klartext erhält (Standard L1–L3; L4–L5 maskiert).
Trust-Modi (Approval / Cautious / Trusted / Danger) überlagern die Risikopolitik pro Quelle, ohne den eigenen Scope des Agenten zu berühren.
Felder im Audit-Log
Jede Ausführung — erfolgreich, fehlgeschlagen, blockiert oder approval-pflichtig — erzeugt einen Audit-Eintrag mit:
- Agenten-Identität (welcher Key, welcher Kanal — MCP / Skill / HTTP / CLI).
- Datenquelle und Ziel (Tabelle, Collection, Index, Key-Pattern).
- Dem Statement bzw. Request, geparst und normalisiert.
- Ergebnis (allowed / warned / approved / blocked).
- Passende Regel und Risiko-Quelle — ob eine spezifische Userregel oder eine systemweite Approval-Policy ausgelöst wurde.
- Liste maskierter Spalten, falls Egress-Maskierung griff.
- Zeitstempel und Approval-Begründung, sofern vorhanden.
Sofortiger Widerruf
Der Widerruf schneidet einem Agenten den künftigen Zugriff sofort ab. Bestehende Audit-Historie bleibt erhalten — Widerruf ist keine Löschung. In Kombination mit Per-Agent-Keys gibt das dem Security-Team eine saubere Antwort auf „Credentials rotieren, wenn X geht“ oder „diese Skill-Installation ist kompromittiert“.
Was das Gateway einem Security-Reviewer liefert
FutrixData ist keine Zertifizierung, und wir behaupten nicht, dass es allein irgendein spezifisches Kontroll-Framework erfüllt — Ihre Organisation verantwortet ihr SOC-2-, ISO-27001-, DSGVO- oder HIPAA-Programm. Was das Gateway bei jedem Datenbankaufruf produziert:
| Reviewer-Frage | Was FutrixData liefert |
|---|---|
| „Wer war das?“ | Eigener Access-Key pro Agent mit Kanal, Label und Widerrufstatus — bei jedem Aufruf protokolliert. |
| „Worauf wurde zugegriffen?“ | Datenquelle, Ziel (Tabelle / Collection / Index / Key-Pattern) und das geparste Statement. |
| „War es erlaubt — und warum?“ | Ergebnis (allow / warn / approve / block) plus die getroffenen Regel(n) und die Risiko-Quelle. |
| „Was ist rausgegangen?“ | Die Liste der Spalten, die auf dem Agenten-Ergebnispfad maskiert wurden, bevor die Zeile das Gateway verließ. |
| „Wurde das Log editiert?“ | Lokale SHA-256-Hash-Kette über die Audit-Zeilen. futrixdata-cli audit verify --json erkennt modifizierte, gelöschte, eingefügte oder umsortierte Zeilen. Nur lokale Verifikation — siehe Limitations. |
Für Umgebungen, die stärkere Garantien als lokale Verifikation brauchen, können Sie Agent-Tool-Events in einen append-only externen Store Ihrer Wahl spiegeln — z. B. Postgres mit WAL-Archivierung, ein Object-Store mit Object-Lock oder ein write-only Sink in einem anderen Netzwerk. Externes Immutable-Anchoring ist heute nicht im Gateway eingebaut; es steht auf der Enterprise-Roadmap (siehe Capability-State-Tabelle auf Trust). Siehe Trust und Limitations für die vollständige Datenpfad-Karte und das, was das Gateway nicht abdeckt.
Beispiele
{
"audit_id": "audit_01HQ8R...",
"ts": "2026-04-29T14:21:08.142Z",
"agent": { "key_id": "fxd_live_a1b2", "channel": "mcp", "label": "claude-code-laptop-01" },
"data_source": "prod-postgres",
"target": { "table": "users" },
"statement": "SELECT id, email, status FROM users WHERE id = $1",
"outcome": "allow",
"rule_hits": ["sql.read.indexed"],
"masked_columns": ["email"],
"duration_ms": 18
}Häufig gestellte Fragen
Was wird in jedem Audit-Eintrag protokolliert?
Agenten-Identität (Key, Kanal, Label), Datenquelle, Ziel, geparstes Statement, Ergebnis, getroffene Regeln, maskierte Spalten, Dauer und ggf. Approval-Begründung. Sowohl erfolgreiche als auch abgelehnte Aufrufe werden protokolliert.
Wie lange werden Audit-Logs aufbewahrt?
Konfigurierbar. Standard für selbst gehostete Deployments richtet sich nach dem Storage-Backend (Persistent Volume oder externes PostgreSQL) — kein automatisches Purgen, sofern Sie keines setzen. Gehostete Tarife exponieren die Retention als Account-Einstellung.
Kann ich Audit-Logs in ein SIEM exportieren?
Noch nicht als eingebautes Feature. Audit-Einträge werden lokal als JSONL gespeichert und können mit dem audit verify-CLI geprüft werden. Wenn Sie heute Echtzeit-SIEM-Ingestion brauchen, können Sie die lokale Audit-Datei aus Ihrem Agenten der Wahl tail-en. Ein dokumentierter externer SIEM-Export landet zusammen mit dem External-Anchoring des Enterprise-Gateways — bis das ausgeliefert ist, verspricht diese Seite es nicht. Siehe Limitations.
Wer kann Audit-Logs lesen?
Workspace-Admins über die Desktop-Console; in selbst gehosteten Deployments alle mit Datenbank-Zugriff auf die Audit-Tabelle. In der Enterprise Edition gated die Admin-Console den Audit-Zugriff nach Rolle.
Ist das Log manipulationsresistent?
Innerhalb des lokalen Scopes, ja. Audit-Einträge werden in eine lokale Hash-Kette geschrieben — jede Zeile trägt den SHA-256-Hash der vorherigen Zeile — und der eingebaute Befehl futrixdata-cli audit verify --json prüft die Kette End-to-End. Der Verifier erkennt modifizierte, gelöschte, eingefügte oder umsortierte Datensätze innerhalb der Kette. Lokale Hash-Kettenverifikation erkennt Edits am bestehenden Log, aber externes Anchoring oder Immutable Storage ist für stärkeren Schutz gegen vollständiges lokales Log-Rewrite erforderlich. Für Umgebungen, die das brauchen, spiegeln Sie Events in einen append-only externen Store (Postgres mit WAL-Archivierung, Object-Store mit Object-Lock oder ein write-only Sink in einem anderen Netzwerk). Siehe 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. Das ist ein separater Pfad 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, sodass Sie nachvollziehen können, welches Schema den Host wann an welchen Anbieter verlassen hat. Siehe Trust für die vollständige Datenpfad-Karte.
Ist „RBAC“ Team-RBAC oder nur RBAC pro Agent?
Auf dem kostenlosen Desktop-Client erhalten Sie eigene Identität pro Agent, Access-Keys, Widerruf und Audit-Zuordnung — ausreichend für Einzelentwickler und kleine AI-native Teams. Team-RBAC mit Rollen, Berechtigungen, Environment-Scopes und Schema-Scopes ist ein Feature der Enterprise Edition auf dem selbst gehosteten Gateway. Wir vermeiden den unqualifizierten Begriff „Team-RBAC“ auf Free-Edition-Seiten, damit der Wortlaut ehrlich bleibt, welche Edition welchen Teil bietet. Siehe self-hosted.
Löscht der Widerruf die Historie?
Nein. Der Widerruf schneidet zukünftigen Zugriff ab; die früheren Audit-Einträge des Agenten bleiben erhalten. So beantwortet man „was hat dieser Agent gesehen, während er aktiv war“.
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.