Was KIFF Cloud signiert, speichert und wofür es einsteht.

Sicherheitslage

KIFF löst das Problem von Protokoll und Governance, nicht das ganze Problem, ein Geschäft zu modellieren. Das Geschäft des Kunden muss in geregelten Artefakten ausgedrückt sein, Entitäten, Ereignisse, Zustände, Aktionen, Berechtigungen, Genehmigungsregeln, Ausführer, Belege. KIFF ist der Koordinationskern, der gegen diese Deklarationen läuft; der Kunde legt fest, was geregelt wird, und KIFF regelt es.

KIFF Cloud verwahrt Audit-Aufzeichnungen, Nutzungszähler und Mandantendaten für Kunden, die geregelte Abläufe mit KI-Agenten betreiben. Audit-Aufzeichnungen werden im Framework nur angehängt, und auf der Ebene der Cloud sind Manipulationen an ihnen erkennbar: Belege werden beim Schreiben mit einem Wallet signiert, das die Cloud verwahrt, und ein zusammenfassender, manipulationserkennbarer Hash über den Audit-Stapel jedes Mandanten wird in einer Transaktion auf einer öffentlichen Chain festgeschrieben, sodass sich die Festschreibung außerhalb der eigenen Datenbank der Cloud prüfen lässt.

Die Verwahrung von Signaturschlüsseln je Mandant, bei der jeder Mandant einen eigenen Schlüssel hat, mit dem die Cloud signiert, und wahlweise einen Weg, dem Mandanten den Schlüssel selbst zu übergeben, steht unten auf der Roadmap und ist heute nicht vorhanden. Bis dahin ist die Cloud die benannte dritte Partei hinter jeder signierten Aufzeichnung.

Die Authentifizierung der Nutzer übernimmt Clerk (E-Mail, Social Login, MFA). Wahlweise lässt sich ein Wallet verknüpfen: Das hängt eine Wallet-Adresse zur Zuordnung an die Akteursidentität eines Nutzers; es ist keine Anmeldemethode.

Was KIFF durchsetzt

Klar gesagt: KIFF gibt eine Entscheidung zurück; deine Integration führt die Wirkung aus. KIFF ist die Schranke, nicht der Ausführende. So arbeitet jede Policy-Engine, eine Berechtigungsbibliothek, ein Policy-Server, eine API gegen Betrug oder für Moderation: Sie geben ein Urteil zurück, und das aufrufende System hält sich daran. Die Durchsetzung greift wirklich, und dieser Abschnitt sagt genau, wo.

An der Schranke blockiert KIFF. Läuft die Aktion eines Agenten durch den Guard, hält jedes Ergebnis, das nicht allowed ist, die Ausführung zurück, dieses Zurückhalten ist die ausfallsichere Zusage des Guards. Und über jede folgenreiche Aktion wird anhand deiner deklarierten Richtlinie und des Zustands der Entität entschieden, und sie wird als Beleg festgehalten, an dem Manipulationen erkennbar sind, bevor sie läuft. Das Produkt ist diese Entscheidung und diese nachweisbare Aufzeichnung, nicht die Behauptung, Codepfade physisch abzufangen, die wir nicht ausführen.

Die Durchsetzung ist eine Einstellung, die du steuerst, je Workspace, und sie ist standardmäßig streng. Du betreibst eine Kontrolle in enforce (der Standard, jede Entscheidung ist bindend, das Zurückhalten oben gilt) oder in observe (nur beratend, KIFF entscheidet und zeichnet genau gleich auf, kennzeichnet die Entscheidung aber als beratend, sodass deine Integration weiterläuft, während du siehst, was die Durchsetzung gestoppt hätte). Observe gibt es nur auf Wunsch, und wir setzen es auf deine Anfrage hin, nie der Agent und nie als Standard, ein Workspace ist nie aus Versehen nur in observe. Es ist der Einstieg: Sieh dir die Entscheidungen der Schranke an echtem Verkehr an, dann schalte enforce ein.

Was KIFF stoppt und was nicht

Die Schranke schwerer umgehbar machen

Die Durchsetzung wird stärker, je enger du die Schranke in den Pfad setzt. Du wählst die Stufe, die dein Risiko und dein Integrationsaufwand rechtfertigen.

Observe, nur beratend, vorhanden

Der Einstieg. KIFF entscheidet über jede Aktion und zeichnet sie auf, kennzeichnet sie aber als beratend, sodass deine Integration unverändert läuft, während du siehst, was die Durchsetzung erlaubt, blockiert oder zurückgehalten hätte. Nur auf Wunsch, und wir setzen es auf deine Anfrage hin; ein Workspace ist nie standardmäßig nur in observe. Schalte enforce ein, wenn die Entscheidungen stimmen.

Guard an der Nahtstelle, vorhanden

Die Aktionen deines Agenten laufen über den Guard, der KIFF um die Entscheidung bittet und alles zurückhält, was nicht freigegeben ist. Governance ist der Standardpfad, kein zusätzlicher Schritt. Umgehen lässt sie sich dann nur noch über deinen eigenen, nicht geregelten Code.

Inline-Proxy, geplant

KIFF sitzt vor der API der Aktion und leitet den Aufruf erst nach einer freigebenden Entscheidung weiter, sodass Entscheiden und Ausführen ein Schritt werden, den ein Agent nicht trennen kann. Umgehen lässt es sich dann nur noch, indem man „die echte API ohne den Proxy aufruft“, und das kann eine Netzwerkrichtlinie verschließen.

Tool-Schranke, geplant

Der einzige Weg des Agenten zur Aktion ist ein Tool hinter KIFFs Schranke, sodass das Modell die Wirkung nicht auslösen kann, ohne die Schranke zu passieren, die Schranke ist die Tool-Oberfläche.

Nichts hier behauptet, KIFF verhindere physisch eine Aktion, die es nicht selbst ausführt. Was es an der Schranke verhindert, welche Aufzeichnung es hinterlässt und wie sich diese Schranke enger setzen lässt, steht oben, nichts, was an einer harten Frage zerbrechen dürfte.

Aktuelle Betriebspraktiken

Verwahrung des Signatur-Wallets

Das Wallet, das Belege signiert und die Festschreibungen auf der öffentlichen Chain einreicht, liegt in unserer Infrastruktur unter Zugriffskontrollen, die von den Anwendungsentwicklern getrennt sind. Der Codepfad der Anwendung signiert über eine Dienstschnittstelle; er kann den Schlüssel nicht auslesen. Die Verwahrung von Signaturschlüsseln je Mandant (ein Wallet je Mandant, mit einem Weg zur Übernahme durch den Mandanten) steht unten auf der Roadmap.

Festschreibung außerhalb des Hauptpfads

Der Job, der die Transaktionen mit den Festschreibungen auf der öffentlichen Chain einreicht, läuft getrennt vom Pfad, auf dem über Vorschläge entschieden wird. Ein Ausfall oder eine Kompromittierung der Anwendungsebene blockiert keine Festschreibungen, die schon gesendet wurden, und spielt sie nicht erneut ab.

Mandantentrennung

Die Daten jedes Mandanten liegen in einem eigenen Postgres-Schema (kiff_t_<id>), und der search_path des Verbindungspools ist je Mandant festgelegt. Mandantenübergreifende Abfragen sind vom Laufzeitpfad aus durch die Architektur ausgeschlossen.

Verschlüsselung

TLS 1.2+ für den Datenverkehr. Postgres ist im Ruhezustand mit den Standardschlüsseln des verwalteten Anbieters verschlüsselt; eine Kundenverschlüsselung je Zeile steht unten auf der Roadmap.

Speicherort der Daten

eu-west-1 (Irland): KIFF Cloud, der tafs-Dienst und planque, mit ihren Datenbanken, Backups, Secrets und Logs.

Unterauftragsverarbeiter

Anbieter, die in unserem Auftrag Mandantendaten verarbeiten. Die offizielle Liste, mit den Daten, die jeder berührt, steht unter /subprocessors. Wir aktualisieren sie innerhalb von 30 Tagen nach jeder Änderung.

Der öffentliche, nachprüfbare Pfad ist kein Unterauftragsverarbeiter: Er erhält nur zusammenfassende Hashes und keine personenbezogenen Daten.

Reaktion auf Vorfälle

Melde ein vermutetes Sicherheitsproblem an security@kiff.dev. Wir wollen den Eingang innerhalb eines Arbeitstags bestätigen und innerhalb von fünf Arbeitstagen eine erste Einschätzung nachreichen.

Vorfälle, die Mandantendaten betreffen, lösen innerhalb von 72 Stunden nach ihrer Bestätigung eine schriftliche Benachrichtigung der betroffenen Kunden aus, und sobald die unmittelbare Reaktion abgeschlossen ist, folgt ein öffentlicher Bericht zum Vorfall. Das vollständige Runbook ist intern; die Richtlinie oben ist die Zusage gegenüber Kunden.

Sicherheitsupdates

Wir liefern Sicherheitsupdates, solange wir den Dienst anbieten. KIFF Cloud, der tafs-Dienst und planque laufen auf unseren Servern, eine Korrektur erreicht also jedes Konto, sobald wir sie ausrollen, und du musst nichts installieren. Die tafs-Apps bekommen ihre über den App Store und Google Play. Ein behobenes Problem, das deine Daten betroffen hat, melden wir dir wie oben beschrieben.

Daten, die wir verarbeiten

Was KIFF Cloud empfängt, was es speichert, was es nie speichert und was vernichtet wird, wenn ein Mandant geht. Das ist die verbindliche Quelle, der unsere Implementierung entsprechen muss. Bei jedem Punkt unten steht, ob er heute verfügbar oder geplant ist.

Kennungen, die wir unverändert aufbewahren

Mandanten-ID, Akteurs-ID, Entitäts-ID, Name der Aktion, Bezeichnung der Entscheidung, Zeitstempel von Anfrage und Antwort, Hashes der Belege und die Transaktions-Hashes des öffentlichen Pfads, die diese Belege festhalten. Das ist das Minimum, das das Framework braucht, um den Zustand wiederzugeben, und die Cloud, um signierte Aufzeichnungen zuzuordnen.

Vom Mandanten gesteuerte Felder, die wir speichern

Aus dem Objekt parameters eines Vorschlags werden nur numerische Parameter (Beträge, Anzahlen) aufbewahrt, weil Limits sie zählen. Die vollständige Anfrage wird als Hash aufbewahrt, damit sich ein erneuter Versuch von einer anderen Anfrage unterscheiden lässt. Andere Parameter werden nicht gespeichert. Der Freitext reasoning_summary wird so aufbewahrt, wie er geschrieben wurde, ohne automatische Bereinigung. Eine Schwärzungskonfiguration je Domäne dafür, deklarativ keep / hash / drop: ist geplant.

Kennungen, die wir nie speichern

Rohe Prompts und Antworten des Modells. Die Cloud leitet den Inferenzverkehr an den konfigurierten Modellanbieter weiter und behält keine Kopie. Mandanten, die Prompts im Beleg haben wollen, müssen das je Domäne ausdrücklich wählen; diese Möglichkeit ist noch nicht gebaut.

Bei tafs ist es anders, weil ein taf ein Agent ist, den wir für dich betreiben: Seine Läufe und Chats, mit der Zusammenfassung eines Chats, werden 30 Tage im eigenen Speicher von tafs aufbewahrt (was deine Apps zurückgeben, nur bis der Lauf endet; in einem Chat wird das, was er nur gelesen hat, für seine nächsten Nachrichten aufbewahrt, verschlüsselt mit dem eigenen Schlüssel des Kontos, und genutzt, bis der Chat eine Stunde lang ruht, höchstens aber vier Stunden nach dem Lesen, dann automatisch gelöscht, innerhalb weniger Tage), und seine Gedächtnisnotizen, bis du den taf entfernst. Für jeden Aufruf, den ein taf über KIFF macht, bewahrt tafs KIFFs Referenz für den Aufruf und die Kennung dessen auf, worauf er gewirkt hat (zum Beispiel eine Zahlungs-ID, nie die Angaben des Kunden), und zwar 30 Tage, um ihn im Protokoll des tafs zu zeigen; der Rest der Eingabe eines Aufrufs wird nur aufbewahrt, bis der Lauf endet. Anhang 4 des AVV führt auf, was tafs aufbewahrt und wie lange.

Daten, die wir nie im nachprüfbaren Pfad veröffentlichen

Die Cloud veröffentlicht einen zusammenfassenden, manipulationserkennbaren Hash über den Audit-Stapel jedes Mandanten in einem öffentlichen, nachprüfbaren Pfad. Die Zusammenfassung schreibt die zugrunde liegenden Aufzeichnungen fest, ohne sie offenzulegen; die Aufzeichnungen selbst verlassen die Datenbank der Cloud nie. Kryptografisches Salting je Mandant ist aktiv: Jedes Blatt im Baum der Zusammenfassung ist an ein 32 Byte langes Geheimnis gebunden, das es nur für den ausstellenden Mandanten gibt, sodass zwei Mandanten mit identischen Bytes einer Aufzeichnung unterschiedliche Blätter festschreiben und sich der öffentliche Pfad nicht als Orakel nutzen lässt, das erratene, aber unbestätigte Aufzeichnungen bestätigt. Das Salt wird serverseitig beim Anlegen des Mandanten erzeugt, verlässt die Datenbank der Cloud nie und wird vernichtet, wenn die Daten eines Mandanten gelöscht werden.

Daten, die wir löschen, wenn ein Mandant gelöscht wird

Ein Antrag auf Löschung eines Mandanten entfernt das Postgres-Schema des Mandanten, seine Audit-Aufzeichnungen, API-Schlüssel und die Verweise auf Signaturschlüssel. Hashes, die schon im öffentlichen, nachprüfbaren Pfad veröffentlicht sind, bleiben, weil dieser Pfad unveränderlich ist; die Vernichtung des Salts des Mandanten macht diese veröffentlichten Hashes dauerhaft nicht rekonstruierbar. Ein Angreifer außerhalb der Chain, der nur die Daten des Pfads und eine mögliche Aufzeichnung hat, kann nicht mehr prüfen, ob diese zum gelöschten Mandanten gehört, das Salt, das den zusammenfassenden Hash an die Aufzeichnung band, ist weg, und das Urbild, aus dem der Hash entstand, lässt sich nicht mehr nachbilden.

Heute löst unser Team die Löschung aus: Mandanten, die ihre Daten entfernt haben wollen, schreiben an privacy@kiff.dev, und wir folgen unserem dokumentierten internen Verfahren innerhalb der Monatsfrist aus Artikel 12 Absatz 3 DSGVO. Eine CLI und eine Dashboard-Oberfläche, mit denen Mandanten selbst löschen, stehen unten auf der Roadmap.

Daten über die Personen, die sich anmelden

Wenn sich ein Nutzer anmeldet, speichert die Cloud die Kennung, die der vorgelagerte Authentifizierungsdienst vergibt, und die E-Mail-Adresse, mit der er sich anmeldet. Die E-Mail-Adresse liegt derzeit im Klartext vor; geplant ist, nur einen HMAC der E-Mail-Adresse und eine geschwärzte Anzeigeform zu speichern. Abläufe zur Wiederherstellung eines Kontos, die die ursprüngliche E-Mail-Adresse brauchen, lesen sie beim vorgelagerten Identitätsanbieter, nicht in unserer Datenbank.

Pseudonymisiert, nicht anonymisiert

KIFF Cloud pseudonymisiert die Kennungen der Mandanten: Direkte Kennungen werden durch stabile, opake Token ersetzt, aber die Daten beziehen sich weiter auf eine Person, und die Datenschutzregeln der EU gelten weiter. Das Produkt anonymisiert Audit-Daten nicht, weil die deterministische Wiedergabe die Funktion ist, die wir verkaufen. Braucht ein Mandant anonymisierte Exporte für Analysen, ist das eine eigene Fähigkeit, die wir nicht gebaut haben.

Was KIFF von einem Aufruf aufbewahrt

Nur, was nötig ist, um eine Card durchzusetzen und zu prüfen:

• Aufbewahrt: wer gefragt hat (Agent und Schlüssel), die Aktion, die Entität, das Ergebnis und seine Gründe, die geltende Card und numerische Parameter (Beträge, Anzahlen), die von Limits gezählt werden. Daraus werden die Aufzeichnung der Entscheidung und ihr Beleg gebaut.
• Gehasht: die vollständigen Argumente eines Aufrufs, damit sich ein erneuter Versuch von einer anderen Anfrage unterscheiden lässt. Über das KIFF-Gateway auch der Wert des Arguments, auf das ein Aufruf wirkt (etwa eine Zahlungs-ID), damit das Protokoll des Inhabers und der Beleg jemandem, der diesen Wert hat, zeigen können, um welchen es ging.
• Verworfen: andere Parameter werden nie gespeichert. Über das KIFF-Gateway werden die Argumente eines Aufrufs nur aufbewahrt, bis er gesendet oder abgelehnt ist, und das Ergebnis des Tools 24 Stunden, damit ein erneuter Versuch dieselbe Antwort bekommt.

Was wir heute nicht tun

• Keine automatische Schwärzung des Freitexts reasoning_summary des Agenten: Er wird so aufbewahrt, wie er geschrieben wurde, damit der Genehmiger und das Audit die eigene Darstellung des Agenten sehen. Schreib keine personenbezogenen Daten hinein.
• Kein automatisches Hashen der E-Mail-Adressen in der Tabelle mit den Metadaten der Authentifizierung. Geplant.

Für künftige Datenbestände, die mandantenübergreifend abgeleitet werden, wird eine eigene Zusage zur Datenminimierung gelten. Stand v0.1 gibt es keinen abgeleiteten Datenbestand.

Dieser Abschnitt beschreibt, wie die Cloud mit Daten umgeht; er ist weder eine Datenschutzerklärung noch ein Auftragsverarbeitungsvertrag. Mandanten in regulierten Branchen sollten vor der produktiven Nutzung mit einem eigenen, unterzeichneten AVV rechnen.