Überblick

Das Sannvit Ledger ist ein nur-anfügbares, hash-verkettetes Audit-Protokoll für KI-Agentenaktivität. Jeder LLM-Aufruf, jede Tool-Ausführung und jeder Abruf, den ein Agent durchführt, wird in eine organisationsspezifische SHA-256-Hash-Kette versiegelt — unabhängig von jedem überprüfbar, nicht nur von dem System, das sie geschrieben hat. Es läuft vollständig innerhalb Ihrer eigenen Infrastruktur: selbst gehostet über Docker Compose oder Kubernetes, keine Daten verlassen Ihre Mauern.

Das Problem, das es löst

Anwendungslogs sind eine Behauptung, kein Beweis — ein Administrator kann eine Zeile bearbeiten, die Aufbewahrung wird in Tagen gemessen, und es gibt keine Unterscheidung zwischen dem, was eine KI behauptet hat, und dem, was unabhängig erfasst wurde. Ein Prüfer, Auditor oder die Gegenseite, die fragt „Was hat Ihre KI getan, und worauf hat sie sich gestützt?", braucht mehr als das: versiegelte Datensätze, die niemand heimlich umschreiben kann, Aufbewahrung über Jahre, und eine Beweiskette von der Entscheidung zurück zu dem, worauf sie beruhte.

Wie es funktioniert

• Erfassen — ein schlankes SDK beobachtet die Aktionen Ihres Agenten im laufenden Prozess, ohne sie zu vermitteln. Nichts steht zwischen Ihrem Code und Ihrem Modellanbieter, und das SDK kann Ihre Anwendung nicht zum Absturz bringen: Die Erfassung ist ein synchroner, nicht blockierender Push in einen Puffer, und die Zustellung an die Ledger-API erfolgt asynchron. Siehe SDKs.
• Versiegeln — die Hash-Verkettung geschieht serverseitig, in der Ledger-API, nicht im SDK — nebenläufige Schreiber können „den vorherigen Datensatz" nicht kennen, daher lebt die Single-Writer-Invariante in einer einzigen Datenbankfunktion. Jeder Datensatz versiegelt sich über den vorherigen in einer organisationsspezifischen Kette.
• Verifizieren — die Kette ist unabhängig überprüfbar: Berechnen Sie den Hash jedes Datensatzes neu und gehen Sie die Verknüpfungen durch, außerhalb des laufenden Dienstes, ohne dem Betreiber vertrauen zu müssen.
• Prüfen — ein Dashboard rekonstruiert die Beweiskette jeder Entscheidung, übernimmt Alarmierung und exportiert Beweispakete für einen Prüfer.

Architektureigenschaften

• Beobachter, keine Gateway. Das SDK steht nie im Anfragepfad — wäre das Ledger nicht erreichbar, würde Ihr Agent es nicht bemerken. Fehler werden an einen on_error-Callback gemeldet, statt weitergereicht zu werden.
• Serverseitiges Versiegeln. Datensätze werden als kanonische RFC-8785-Einträge serialisiert und per SHA-256 hash-verkettet (ein record_hash/prev_hash-Paar pro Datensatz). Das SDK meldet nur, was geschehen ist; der Server berechnet jeden Hash.
• Nie stillschweigend Datenverlust. Läuft der Ingest-Puffer über, werden verworfene Ereignisse gezählt und als lifecycle-Datensatz versiegelt eingefügt — die Lücke selbst wird Teil des Audit-Trails, statt ein stilles Loch darin zu sein.
• Selbst gehostet. Einfaches Postgres, Keycloak für die Authentifizierung und ein S3-kompatibler Blob-Speicher für Payload-Inhalte (nur Zeiger + Hash, inhaltsadressiert) — alles läuft in Ihrer eigenen VPC oder On-Premises, kein verwaltetes Backend, dem Sie vertrauen müssten.

Was im Stack steckt

Wie es weitergeht

• Erste Schritte — den Stack mit Docker Compose oder Kubernetes aufsetzen.
• SDKs — einen Agenten instrumentieren, um seine Aktivität ins Ledger zu versiegeln.