Wie FutrixData mit Ihren Daten umgeht

Datenpfade auf einen Blick

FutrixData hat drei Datenpfade. Sie sind absichtlich getrennt und verhalten sich unterschiedlich:

• Console (autorisierter Mensch). Die Desktop-Console ist, wo Engineers Ad-hoc-Queries gegen ihre Datenbanken fahren. Standardmäßig werden Rohzeilen zurückgegeben — der Mensch an der Tastatur ist der autorisierte Inspektor.
• Agenten-Ergebnispfad (MCP, Skill, CLI). Wenn ein KI-Agent FutrixData via MCP, Skill oder Agent-CLI ruft, werden sensible Ergebniswerte durch stabile pseudonyme Hashes ersetzt, bevor sie an den Aufrufer zurückgehen. Hier sitzt der Maskierungs-Guardrail.
• Schema-Metadaten-Pfad. Schema-Wissen — Tabellennamen, Spaltennamen, Indizes, Kommentare, Typen — kann an den in AI-Chat / Schema-Knowledge / ER-Assistance konfigurierten LLM-Anbieter gesendet werden. Das ist ein separater Pfad von den Result-Zeilen. Die Result-Maskierung deckt Schema-Metadaten nicht automatisch ab. Siehe Abschnitt Schema-an-LLM unten.

Wo Credentials und Secrets liegen

Datenbank-Credentials, Datenquellen-Definitionen, Agenten-Identitäten, Sensitivitätsregeln, AI-Provider-Keys und die Agent-Audit-Historie werden lokal gespeichert. Vom ersten Start an nutzt der Daemon einen lokalen verschlüsselten Store, gestützt durch einen OS-Keyring-Root-Key — diese Dateien sind also schon vor dem ersten Login at rest verschlüsselt. Wenn der OS-Keyring auf einer Plattform nicht verfügbar ist, gibt der Daemon eine Plaintext-Fallback-Warnung aus, statt still zu degradieren.

Keiner dieser Werte wird auf FutrixData-Server hochgeladen. Das Hosted-Gateway und der Lizenzserver sehen nur, was für Billing und Lizensierung nötig ist — keine Datenbank-Credentials oder Query-Bodies. Siehe Limitations für die Umkehrung: die Dinge, gegen die FutrixData nicht schützt.

Result-Maskierung ist secret-basiert, deterministisch und einseitig

Auf dem Agenten-Ergebnispfad werden sensible Werte durch stabile pseudonyme Hashes ersetzt. Die Substitution ist ein deterministischer HMAC, gestützt durch ein im OS-Secret-Store abgelegtes lokales Secret. Der Hash für eine bestimmte Eingabe ist innerhalb einer Installation stabil (Analysten und Agenten sehen also konsistente Werte über Calls hinweg), aber ohne dieses lokale Secret nicht umkehrbar.

Deterministische Maskierung reduziert die Leak-Fläche — sie ist keine vollständige Anonymisierung. Zwei Aufrufer mit demselben Secret sehen denselben Hash; ein Angreifer mit voller lokaler Host-Kontrolle kann Hashes für bekannte Eingaben neu berechnen. Siehe Maskierungs-Limitations.

Lokales Hash-Chain-Audit und der Verify-Befehl

Jeder Agent-Tool-Call schreibt einen Eintrag ins lokale Agent-Audit-Log. Neue Einträge sind hash-verkettet: Jede Zeile trägt den SHA-256-Hash der vorherigen Zeile, plus einen Payload-Hash und eine Chain-Version. Ein eingebauter CLI-Befehl verifiziert die Kette End-to-End und erkennt modifizierte, gelöschte, eingefügte oder umsortierte Datensätze innerhalb des verketteten Bereichs.

Verifier ausführen:

Was der Verifier meldet

Der JSON-Output enthält, ob die Verifikation passte, wie viele Datensätze verifiziert wurden, wie viele Legacy-(Pre-Chain-)Datensätze gefunden wurden, die erste fehlerhafte Position bei Verifikationsfehler und den erwarteten vs. tatsächlichen Hash an dieser Position. Der Verifier ist vollständig lokal — er braucht keine Netzwerkverbindung, keinen Account und nicht die Desktop-App.

Local-only-Scope. 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. Die Kette beweist Konsistenz der Datei, wie Sie sie jetzt lesen; sie kann nicht beweisen, dass ein Angreifer mit voller lokaler Filekontrolle nicht die gesamte Datei neu geschrieben und alle Hashes neu berechnet hat. Für höhere Zusicherung können Sie Agent-Tool-Events in einen separaten append-only Store spiegeln, den Sie kontrollieren (z. B. Postgres mit WAL-Archivierung, 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 unten).

Failure-Verhalten der Risk-Engine auf Agentenpfaden

Agenten-Tool-Calls laufen durch dieselbe Risk-Engine wie Console-Queries: Regeln klassifizieren jedes Statement als low / medium / high risk und entscheiden, ob allow, warn, require approval oder block. Auf dem Agentenpfad ist die Engine fail-closed-orientiert: Wenn der SQL-Parser keine Risikofakten extrahieren kann, wenn eine Probe fehlschlägt oder wenn ein Multi-Statement-Input sichere und unsichere Operationen mischt, fordert der Agentenpfad Approval, statt auto-allow. Der Console-(Mensch-)Pfad kann auf denselben Edge-Cases by design permissiver sein — siehe RBAC und Audit für die vollständige Regelliste.

Schema-Metadaten an LLM-Anbieter

Die Features AI-Chat, Schema-Knowledge und ER-Assistance von FutrixData können Schema-Metadaten — Tabellennamen, Spaltennamen, Indizes, Kommentare, Typen — in Prompts an den von Ihnen konfigurierten LLM-Anbieter aufnehmen. Das liegt auf einem separaten Pfad von den Query-Result-Zeilen. Die Result-Maskierung deckt Schema-Metadaten nicht automatisch ab, weil das Schema die Frage ist, nicht die Daten.

Die Desktop-App exponiert eine explizite Einstellung, um die Schema-Metadaten-Übermittlung pro Datenquelle zu aktivieren oder zu deaktivieren. Jede Schema-an-LLM-Übermittlung wird protokolliert, sodass Sie auditieren können, welches Schema Ihre Maschine wann an welchen Anbieter verlassen hat. Siehe FAQ unten dafür, was zu prüfen ist, bevor Sie FutrixData auf Datenbanken richten, deren Schema selbst sensibel ist.

Capability-State

Das ist der aktuelle Implementierungsstand der Sicherheits-Capabilities, auf die der Rest der Marketing-Site verweist. Wir aktualisieren diese Tabelle, wenn Capabilities ausgeliefert werden.