Audit-Log

Eine reine Anfüge-Aufzeichnung mit Manipulationsnachweis über jede zustandsändernde Aktion in deinem Bereich, mit Vorher-Nachher-Vergleichen auf Feldebene und niemals offengelegten IP-Adressen.

Das Audit-Log beantwortet eine einzige Frage über deinen Bereich: wer was wann und woran getan hat. Jede zustandsändernde Aktion, einen Agenten erstellen, die Rolle eines Mitglieds ändern, eine Integration verbinden, Wissen löschen, schreibt einen unveränderlichen Eintrag. AnyBot erkennt 559 Aktionen plattformweit, die Abdeckung ist also die gesamte Oberfläche, keine Auswahl der Höhepunkte.

Anatomie eines Eintrags

Jede Zeile erfasst dieselbe Struktur, sodass sich jede Aktion gleich liest:

Feld	Was es erfasst
Akteur	Das Mitglied, das sie ausgeführt hat, oder der Agent / das System bei automatisierten und per Callback ausgelösten Ereignissen
Zeitstempel	Wann es passiert ist
Geltungsbereich	Der Bereich und der spezifische Agent, wenn die Aktion einen Agenten betrifft
Aktion	Ein kanonisches `namespace.verb` (z. B. `space.member_updated`) plus eine Bezeichnung in einfacher Sprache
Entität	Was betroffen war, ein Agent, ein Mitglied, eine Integration, ein Lead, eine Datei
Änderung	Ein Vorher-/Nachher-Vergleich auf Feldebene, nur die Namen der Felder und sichere Werte
Sensibilität	`high` · `med` · `low`, sodass du nach den Aktionen filtern kannst, die zählen
Ergebnis	`success` · `failed` · `denied` · `neutral`
Client	Eine grobe Zusammenfassung von Browser / OS / Gerät, nur für Eigentümer und Administratoren sichtbar

Was es abdeckt

Aktionen sind in Domänen gruppiert, nach denen du filtern kannst: Agenten, Wissen, Integrationen & Kanäle, Posteingang & Unterhaltungen, CRM & Leads, Social, Produkte, Meetings, Telefonie, Kalender, Landingpages und Governance (Mitglieder, Rollen, Bereiche, Abrechnung, Sicherheit, Exporte). Wenn eine Operation den Zustand ändert, erstellen, aktualisieren, löschen, gewähren, widerrufen, verbinden, veröffentlichen, anmelden, ein Passwort ändern, ist sie darauf ausgelegt, eine Spur zu hinterlassen. Diese Abdeckung wird im Code erzwungen: Eine neue zustandsändernde Aktion, die ohne einen Audit-Eintrag ausgeliefert wird, fällt bei einer internen Prüfung durch.

Wie die Teile zusammenhängen

Jede Aktion gehört zu einer Entität und jede Entität zu einer Domäne. Sensibilität und Ergebnis werden aus der Aktion selbst abgeleitet, nicht lose gespeichert, sodass derselbe Klassifikator die Bezeichnungen, die farbigen Stufen und die Filter steuert. Deshalb liefert das Filtern nach „hohe Sensibilität, Ergebnis verweigert, Governance“ genau die sicherheitsrelevanten Ereignisse und nichts anderes.

Manipulationsnachweis

Das Log ist mehr als nur anfügbar. Jeder neue Eintrag wird in eine Hash-Kette versiegelt: Sein Hash ist sha256(entry-contents | previous entry's hash). Weil jeder Eintrag den vorhergehenden einbettet, ändert das Bearbeiten oder Löschen einer beliebigen historischen Zeile ihren Hash und bricht jeden Hash danach, was eine Integritätsprüfung erkennt und genau lokalisiert. Das Versiegeln ist fail-open: Es kann die aufzuzeichnende Aktion niemals blockieren oder verlangsamen, und Einträge, die vor der Einführung der Ketten-Funktion geschrieben wurden, werden ehrlich als pre-chain gemeldet, statt ihnen stillschweigend zu vertrauen.

Datenschutz: was geschwärzt wird

Das Audit-Log ist so gebaut, dass es sicher zu lesen ist:

IP-Adressen werden nie offengelegt über die Audit-API, absichtlich so, nicht einmal gegenüber Eigentümern und Administratoren. Sie werden für den Datensatz erfasst, aber nicht angezeigt.
User Agents werden reduziert auf eine grobe Bezeichnung von Browser / OS / Gerät. Kein Fingerabdruck.
Geheimnisse und PII gelangen nie in einen Eintrag. Eine Passwortänderung, ein Token, eine API-Anmeldeinformation oder ein Einwilligungsdatensatz wird per Feldname und einem sicheren Vergleich protokolliert, niemals der Wert.

Praxisbeispiel

Ein Teammitglied befördert ein anderes Mitglied von Mitglied zu Administrator. Es wird ein Eintrag geschrieben:

Aktion, space.member_updated · Bezeichnung „Rolle/Berechtigungen eines Mitglieds geändert“
Sensibilität, high · Ergebnis, success
Akteur, das befördernde Mitglied · Entität, das beförderte Mitglied
Änderung, role: member → admin
Zeitstempel + grober Client (Ansicht Eigentümer/Administrator)

Später öffnet ein Operator diesen Datensatz über die Administrationskonsole. Weil er hochsensibel ist, wird das Ansehen selbst protokolliert (audit_log.viewed), das Log prüft seine eigenen Prüfer. (Diese Selbstprotokollierung wird im Operator-/Administrator-Panel ausgelöst, nicht in der Audit-Ansicht innerhalb des Bereichs.)

Wer es lesen darf

Das Lesen des Audit-Logs wird durch die Berechtigung view_audit_log geregelt. Eigentümer und Administratoren haben sie immer; Mitgliedern und Betrachtern kann sie einzeln über die Berechtigungsmatrix gewährt werden, ein häufiges Muster für einen Compliance-Prüfer, der die Spur benötigt, aber keine weitere Administratorbefugnis.

FAQ

Kann ein Eintrag bearbeitet oder entfernt werden? Nein. Das Log ist nur anfügbar, und die Hash-Kette macht jede nachträgliche Änderung erkennbar.

Warum kann ich nicht sehen, wer etwas vor unserem Beitritt getan hat? Einträge, die der aktuellen Kette vorausgehen, sind als pre-chain gekennzeichnet; die Manipulationsnachweis-Garantie beginnt beim ersten versiegelten Eintrag nach der Bereitstellung der Funktion.

Erscheint der Agent als Akteur? Ja, automatisierte und per Callback ausgelöste Ereignisse werden dem Agenten/System statt einer Person zugeschrieben, sodass durch KI-Agenten ausgelöste Änderungen nie mit menschlichen verwechselt werden.