Nachweis nach einem Vorfall: wie wir die Frage „wer hat das genehmigt" beantworten

Eine hypothetische Situation, das Problem dahinter und was wir gebaut haben, damit sie sich nicht wiederholt

Die Situation

Ein Kunde kommt zu uns — kein Startup, sondern ein Unternehmen mit einem Prozess: Anträge, Freigaben, Zahlungen. Wir setzen einen Agenten ein, der einen Teil dieses Prozesses führt. Zwei Monate später ein Vorfall: Der Agent hat eine Zahlung ausgeführt, die kein Mensch freigegeben hatte.

Die Untersuchung beginnt mit einer einfachen Frage: „Zeigen Sie uns, auf welcher Grundlage er das getan hat." Und es zeigt sich: Es gibt nichts zu zeigen.

Es gibt Logs. Es gibt einen Chatverlauf. Es gibt einen CRM-Export. Aber keines dieser Artefakte beantwortet, ob der Agent in jener Sekunde das Recht zu dieser Handlung hatte und wer es erteilt hat. Die Vollmacht liegt an einer Stelle, die Entscheidung an einer anderen, der Versand an einer dritten, und die Tatsache der Ausführung beim Empfänger — und niemand hat sie je gemeinsam geprüft.

Das Problem

Wir haben es für uns so formuliert: Zwischen Vollmacht, Entscheidung, Versand und Wirkung klafft eine Lücke, und die Branche schließt sie mit Zusicherungen statt mit Nachweisen.

Attestierung und Identitätsstandards beantworten „wer ist auf der anderen Seite": welcher Workload, welcher Schlüssel. Das ist notwendig, beantwortet aber nicht „mit welchem Recht gehandelt wurde". Ein korrekt attestierter Server kann eine Handlung außerhalb des delegierten Rahmens annehmen, ohne dass eine Attestierungseigenschaft verletzt wird.

Logs beantworten „was geschehen ist", nicht „war es erlaubt". Ein Datensatz kann vollständig sein und trotzdem eine Handlung beschreiben, die niemand genehmigt hat.

Nach einem Vorfall bleibt dem Kunden also viel Daten und keine Antwort. Und dem Anbieter bleibt „bei uns wird alles protokolliert", was einer Prüfung nicht standhält.

Was wir gebaut haben

Wir haben keine weitere Agenten-Implementierung gebaut. Wir haben ein Instrument gebaut, mit dem Aussagen über Vollmachten geprüft werden können — unsere und die anderer — nach einem Regelwerk.

Ein Vergleichsvertrag. Vier Szenarien, die fast jedes Design brechen: Ablehnung am Entscheidungspunkt, Entscheidung auf veralteten Daten, nicht erreichbare genehmigende Instanz, Widerruf nach dem Versand. Vierzehn Pflichtfelder — von Vollmacht und Entscheidung über die tatsächliche Wirkung, Quittung, Aktionsdigest, Frist und Wiederholungszahl. Vier Nachweiszustände: gemessen, nicht anwendbar, nicht ausgegeben, nicht gemessen.

Der letzte ist entscheidend. Er verbietet die wichtigste Manipulation im Reporting: „wir haben es nicht gemessen" als „es ist nicht anwendbar" auszugeben.

Ein Offline-Verifizierer mit Negativkontrollen. Die Prüfung muss ein Paket zurückweisen, in dem ein Fall entfernt, ein Fall dupliziert, ein Urteil umgedreht, ein zitierter Datensatz gelöscht oder zwei Zeilen ihre Quittungen getauscht haben. Und sie muss das unveränderte Paket akzeptieren. Das klingt nach Formalie, bis es greift: In einem veröffentlichten Paket behauptete ein Datensatz, der Ausführende habe an seiner Grenze abgelehnt, während der Job-Datensatz einen hängenden Versuch und eine spätere Ablehnung beim Wiederholungsversuch zeigte. Keine Integritätsprüfung fängt das — nur der Abgleich der Behauptung mit dem Datensatz.

Offenheit. Vertrag, Fälle und Ablehnungsregeln sind veröffentlicht; die Arbeit läuft in einer offenen Arbeitsgruppe zu Identität und Vertrauen, mit Ergebnissen in einem öffentlichen Repository und einem begutachteten Paper. Wir bitten nicht um Vertrauen auf Zuruf: Jeder kann ein Paket nehmen und die Prüfung laufen lassen.

Was das dem Kunden gibt

Nach einem Vorfall — kein „Log", sondern eine Analyse: welche Vollmacht galt, welche Entscheidung getroffen wurde, was gesendet wurde, was auf der Gegenseite geschah und wo Nachweise fehlen. Vor einem Vorfall — die Möglichkeit, vorab zu vereinbaren, was als normal und was als Vorfall gilt.

Und vor allem: die Möglichkeit, uns über einen Dritten zu prüfen. Genau das fehlt üblicherweise bei „vertrauen Sie uns, alles ist unter Kontrolle".

Was wir nicht behaupten

Wir stellen keine Zertifikate aus und behaupten keine Normkonformität. Wir haben nicht bewiesen, dass ein Agent allgemein sicher ist. Wir sagen offen, dass ein Teil der Garantie beim Ausführenden und beim Ziel liegt: Wir können zeigen, dass eine Entscheidung im Rahmen der erteilten Vollmacht getroffen wurde, aber nicht allein beweisen, dass der Empfänger genau diese Handlung ausgeführt hat.

Und wir benennen die Grenzen unserer Methode: Der Vergleich erfolgt offline über aufbewahrte Datensätze; Live-Durchsetzung und Wirkungen auf der Zielseite werden nicht festgestellt.

Wie das in der Praxis aussieht

Ein Pilot: Wir sehen uns die Datensätze Ihres Agenten an, führen sie durch den Vertrag und zeigen, was sie beweisen und was nicht. Danach wird entweder die Aufzeichnung verbessert, oder die Grenzen der Vollmacht werden geändert, oder der nicht abgedeckte Teil wird ehrlich in den Vertrag geschrieben.

Wenn Sie einen laufenden Agenten haben und die Frage „was zeigen wir, wenn etwas schiefgeht" — dort fangen wir an.