AgentGuard · Vertrauen
Wir sind ein kleiner Anbieter aus Chemnitz. Deshalb steht hier nicht, dass ihr uns vertrauen sollt, sondern was ihr selbst nachsehen könnt: wo die Daten liegen, was bei einem Ausfall passiert, wofür wir haften und wie ihr eure Aufzeichnung ohne uns nachrechnet.
Für euch richten wir AgentGuard auf einer eigenen Kundeninstanz ein: einem virtuellen Server nur für euch, bei IONOS SE oder netcup GmbH, Rechenzentrum in Deutschland, oder auf einem Server in eurem Netz. Dort läuft er in einem Container ohne Administratorrechte und mit schreibgeschütztem Dateisystem. Die Aufzeichnung liegt in einer Postgres-Datenbank auf derselben Instanz. Der Datenbankbenutzer von AgentGuard darf in die Aufzeichnung nur schreiben und lesen, nicht ändern und nicht löschen.
Aufgezeichnet werden Aktionstyp, Ziel, Betrag, Agent, Urteil, Grund und Zeitpunkt. Den Text, den ein Agent verschicken will, prüft AgentGuard im Arbeitsspeicher und verwirft ihn danach; in der Aufzeichnung steht nur, welche Art von Fund es gab.
Wer die Daten gar nicht bei einem Hoster haben will: AgentGuard gibt es auch als Paket für den eigenen Server, ohne Internetzugang installierbar. Dann liegt alles bei euch.
Einen Vertrag zur Auftragsverarbeitung nach Artikel 28 DSGVO schließen wir mit jedem Kunden, so steht es in § 12 unserer AGB. Den AVV gibt es auf Anfrage. Unser Muster wird gerade anwaltlich geprüft; solange veröffentlichen wir es nicht.
Eure Agenten laufen weiter. Unsere Bausteine für Python und TypeScript melden bei Zeitüberschreitung, fehlendem Netz oder Serverfehler „unbekannt“ und werfen keinen Fehler; der n8n-Baustein lässt den Lauf weitergehen. Für die Zeit des Ausfalls fehlen dann die Einträge, und das sieht man in der Aufzeichnung.
So, wie ihr es einstellt. Ohne weitere Einstellung entscheidet euer Code, was bei „unbekannt“ passiert; unser Beispiel führt dann nicht aus. Mit der Einstellung „streng“ wirft der Baustein einen Fehler. Kann AgentGuard eine Entscheidung nicht in die Datenbank schreiben, wird eine erlaubte Aktion eines scharf geschalteten Agenten abgelehnt: ohne Aufzeichnung keine Erlaubnis.
Im Protokoll lehnt AgentGuard aus eigener Bewertung nichts ab, auch nicht, wenn eine Prüfung anschlägt; das steht dann als „hätte abgelehnt“ in den Daten. Zwei Dinge halten einen Agenten trotzdem an, weil sie Entscheidungen von Menschen sind: ein Not-Aus, den eine berechtigte Person setzt, und ein Köder, den ihr selbst hinterlegt habt und den ein Agent verwendet.
Es gelten unsere AGB (Stand 26. Oktober 2026), und wir versprechen hier nichts darüber hinaus. Kurz gefasst: Für Vorsatz, grobe Fahrlässigkeit und Schäden an Leben, Körper und Gesundheit haften wir unbeschränkt (§ 9 Abs. 1). Bei leicht fahrlässiger Verletzung wesentlicher Vertragspflichten ist die Haftung auf den vertragstypischen, vorhersehbaren Schaden begrenzt, höchstens auf den Auftragswert, und auf 50.000 € je Schadensereignis und 200.000 € je Versicherungsjahr (§ 9 Abs. 2).
Für die Entscheidungen eurer Agenten haftet euer Unternehmen. Dass KI-Ausgaben vor einer folgenreichen Verwendung geprüft werden, stellt ihr durch eigene Maßnahmen sicher (§ 10 Abs. 2); AgentGuard ist ein Werkzeug dafür, keine Übernahme dieser Pflicht. Maßgeblich ist der Wortlaut der AGB, nicht diese Zusammenfassung.
Jeder Eintrag trägt den Hash des vorherigen, je Mandant eine eigene Kette, und jede Zeile ist mit unserem Ed25519-Schlüssel signiert. Das Nachweis-Archiv aus der Konsole lässt sich damit auf eurem Rechner prüfen: Python 3 genügt, keine Zusatzpakete, kein Internet.
unzip agentguard-pruefen.zip
sha256sum agentguard-pruefen.py
e5eb366f0480d637e41a07f674588013e0b0742b67bdf3512f58f62ed3aac6fe
python3 agentguard-pruefen.py agentguard-nachweis.zip --schluessel 171de16810b1a6cc --anker 3130636896ab836dd2b5ea9227e6c9feb651c06b7137390fc2be6d7e6eeff160
Unsere veröffentlichten Werte
Fingerabdruck des Prüfschlüssels: 171de16810b1a6cc
Öffentlicher Schlüssel (Ed25519): 2d539528d79e60d06b1acb115fcae0a3a2610157462eefadea2eb5e7d0b982c5
Fixpunkt, an dem die Mandantenketten hängen: 3130636896ab836dd2b5ea9227e6c9feb651c06b7137390fc2be6d7e6eeff160
Stand 30. Oktober 2026. Wechselt der Schlüssel, steht der neue hier.
Das Skript prüft vier Dinge: die Unterschrift über alle Dateien des Archivs, die Kette eures Mandanten Zeile für Zeile, die Signatur jeder Zeile und die signierten Checkpoints. Wir haben es am 30. Oktober 2026 an einem echten Archiv unseres eigenen Mandanten laufen lassen: 3.201 Zeilen aus drei Tagen, alle vier Prüfungen bestanden.
Weil wer ein Archiv fälscht, auch das beigelegte Prüfskript austauschen kann, gegen eines, das immer „in Ordnung“ sagt. Die Datei von dieser Seite liegt getrennt vom Archiv, ihr Hash steht daneben. Noch besser: ihr legt euch beim Start eine Kopie ab und nehmt immer diese.
Dass das Archiv so von unserem Schlüssel unterschrieben wurde, mit allen Feldern jeder Zeile, und dass die Einträge eures Mandanten im Ausschnitt eine lückenlose Kette bilden. Sie beweist nicht, dass die Datenbank vor dem Export unverändert war. Dafür gibt es die signierten Checkpoints, die das Skript ebenfalls prüft, und den Vergleich mit einem früheren Archiv.
Die zweite Signatur jeder Zeile (HMAC). Dafür bräuchte man unseren geheimen Schlüssel, und der gehört nicht in ein Archiv, sonst könnte jeder neue Zeilen signieren. Das Ergebnis dieser Prüfung steht im Archiv in integritaet.json, gerechnet von AgentGuard beim Export.
Die Demo läuft in eurem Browser, mit ausgedachten Agenten. Das Beispielarchiv dazu prüft ihr mit diesem Skript. Echte Agenten hängt ihr erst an, wenn AgentGuard auf eurer eigenen Instanz läuft.