Fehlende Zurechenbarkeit und Forensik

Wenn mit einem Agenten etwas schiefgeht, ist die erste Frage immer dieselbe: Was hat er tatsächlich getan, und wer hat die Policy geändert, die es ihm erlaubt hat? Ohne eine Spur können Sie keines von beidem beantworten. Sie können einem Auditor nicht zeigen, dass eine Kontrolle am fraglichen Tag in Kraft war, Sie können einen echten Angriff nicht von einem verrauschten Falsch-Positiv unterscheiden, und Sie können den Lauf, der die Zeile geleakt hat, nicht rekonstruieren. OrcaRouter zeichnet die Antwort auf, während Sie gehen. Jeder gescreente Prompt, jeder Tool-Call, jede Freigabe und jede Policy-Bearbeitung landet in einem workspace-bezogenen, abfragbaren Datensatz — korreliert zurück zum Agentenlauf und zur Session, die ihn produziert hat. Diese Seite zeigt, wie Sie diesen Datensatz als KI-Agenten-Audit-Trail nutzen: von einem einzelnen verdächtigen Lauf bis zu einem signierten Report, den Sie einem Auditor übergeben.

​

1. Die vier Datensätze hinter einem KI-Agenten-Audit-Trail

Zurechenbarkeit kommt aus vier unabhängigen Strömen, jeder korreliert zu demselben Lauf und derselben Session, sodass Sie zwischen ihnen pivoten können: Das Bindegewebe ist die Agentenlauf- und Session-ID. Ein Guardrail-Match und ein Firewall-Event aus derselben Konversation tragen dieselbe Run-Abstammung, sodass „dieser Lauf hat eine E-Mail maskiert, dann einen Fetch versucht, den wir abgelehnt haben, dann wurde er für einen Schreibvorgang genehmigt” sich als eine Geschichte liest, statt als drei unverbundene Logs.

​

2. Guardrail-Matches — was gescreent wurde (Member)

Jedes Mal, wenn eine Guardrail-Regel feuert, schreibt das Gateway einen Match. Der Feed lebt auf der Guardrails-Seite (Matches-Tab) und ist von jedem Workspace-Mitglied lesbar. Jeder Match zeichnet den Regeltyp, die ergriffene Aktion (block / mask / flag / annotate / spotlight), die Stage (input / output), einen Detail-String und die Run-Abstammung des Requests auf, der ihn ausgelöst hat. Listen Sie ihn auf, gruppieren Sie ihn nach Guardrail oder Regeltyp, filtern Sie nach Aktion, bohren Sie in einen Match hinein oder exportieren Sie den Feed nach CSV. Eine verrauschte Regel ist ebenfalls Teil der Spur. Markieren Sie einen Match mit POST /api/guardrail/match/:id/mark-fp (Admin) als Falsch-Positiv, sodass Ihr Signal sauber bleibt und Ihre Reports nicht überzählen.

​

3. Firewall-Events & Runs — was der Agent getan hat (Developer+)

Wo Matches Text abdecken, decken Firewall-Events Aktionen ab. Jede Tool-Call-Auswertung wird mit ihrem Verdikt, ihrer Surface, ihrem Tool-Namen und — entscheidend — dem Agentenlauf und der Session, zu dem/der sie gehört, geloggt. Lesevorgänge auf Events, dem Runs/sessions-Rollup und dem Pro-Lauf-Trace erfordern Developer+; die leichteren Discovered-tools- und Anomalie-Feeds sind für jedes Member offen. Die Runs & sessions-Ansicht ist das forensische Arbeitspferd: Sie rollt Events nach Agentenlauf in eine Verdikt-Aufschlüsselung, die distinkten Tools und Modelle, die der Lauf berührt hat, und first/last-seen-Zeitstempel auf — die „was hat dieser Agent tatsächlich getan”-Antwort auf einem Bildschirm. Über statische Verdikte hinaus flaggt der Anomalie-Feed Abweichungen von der gelernten Hour-of-week-Baseline jedes Workspaces (ein gleitender 14-Tage-Durchschnitt) — Raten- und Kosten-Spikes, retry_loop und novel_path-Übergänge — sodass ein erlaubtes-aber-abnormales Pattern trotzdem im Datensatz auftaucht.

​

4. Approval-Entscheidungen — wer Ja gesagt hat (Audit-Aktion)

Wenn eine Regel zu pending_approval auflöst, wird der zurückgehaltene Aufruf zu einer Out-of-band-Überprüfung (siehe den HITL-Flow der Firewall). Die Entscheidung ist Teil der Spur: Genehmigen oder Ablehnen schreibt eine Workspace-Audit-Zeile — firewall_approval_approve oder firewall_approval_reject — die den Akteur benennt. Entscheidungen sind first-writer-wins und idempotent, und wenn die zugrunde liegende Regel nach dem Hold geändert wurde, vermerkt die Anreicherung, dass sich der Kontext verschoben hat. So ist ein zurückgehaltener-dann-genehmigter Tool-Call vollständig zurechenbar, End zu End: Das Firewall-Event zeigt den Hold, die Audit-Zeile zeigt, wer ihn freigegeben hat, und beide korrelieren zum selben Lauf.

​

5. Policy-Änderungs-Audit — wer die Regeln geändert hat

Eine Spur von Agentenverhalten ist nur vertrauenswürdig, wenn Sie auch beweisen können, was die Policy war zu der Zeit — und wer sie geändert hat. Guardrails halten eine vollständige Versionshistorie. Jedes Erstellen, Aktualisieren und Löschen schreibt eine versionierte Historienzeile in derselben Transaktion wie die Änderung. Öffnen Sie History auf einem Guardrail, um jede Version mit Autor und Zeitstempel zu sehen, zwei beliebige zu diffen und zu einer älteren zurückzureverten (ein Revert wird als neue Version aufgezeichnet — die Historie wird nie mutiert). Firewall-Policy-, Regel- und Einstellungsänderungen schreiben jeweils eine Workspace-Audit-Zeile, nachdem die Änderung committed ist — firewall_policy_update, firewall_rule_create, firewall_settings_update und so weiter — und Autonomie-Stufen-Änderungen (firewall_autonomy_applied / firewall_autonomy_undone) erfassen den Vorzustands-Snapshot, der das Ein-Klick-Undo antreibt. Secrets und Regel-Blobs werden nie geloggt.

​

6. Ein durchgearbeitetes Beispiel: einen verdächtigen Lauf nachverfolgen

Angenommen, ein Lauf wird wegen eines unerwarteten ausgehenden Aufrufs geflaggt. Aus der Konsole, mit einer Developer+-Session: Ein Lauf, vier korrelierte Datensätze, keine Log-Grep-Archäologie. Für die Exfiltrations-Verteidigungen selbst siehe Datenexfiltration und Gefährliche Tool-Calls.

​

7. Signierte Compliance-Reports — eine Spur, die ein Auditor verifizieren kann

Für externen Nachweis verwandelt die Compliance-Surface diese Spur in ein einziges Artefakt. Das Durchsuchen des Framework-Katalogs, der Packs und der Readiness ist für jedes Member offen und kostenlos; das Installieren eines Packs, das Generieren eines Reports, das Live-Gehen und das Setzen der Datenresidenz sind Workspace-Admin-Aktionen auf einem kostenpflichtigen Plan (server-gegated). Ein Compliance-Report ist Ed25519-signiert mit einem SHA256-Inhalts-Hash und ist öffentlich verifizierbar — der Empfänger prüft ihn ohne ein OrcaRouter-Konto: Reports exportieren als CSV / JSON / PDF. Frameworks umfassen soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, den EU AI Act (eu_ai_act) und die OWASP Top 10 for LLM Applications (owasp_llm), unter anderen — das Installieren eines Packs materialisiert die passenden Guardrails und Firewall-Policies, sodass die Kontrollen, über die Sie berichten, die tatsächlich durchgesetzten Kontrollen sind.

​

8. Retention und das Recht auf Löschung

Ein forensischer Datensatz ist begrenzt, nicht für immer. Request-Logs haben standardmäßig eine Retention von 30 Tagen und sind server-geklammert auf ein hartes Maximum von 180 Tagen. Wenn ein Nutzer sich selbst löscht, gilt ein 30-Tage-Gnadenfenster, nach dem seine PII geschrubbt wird und die Kaskade seine Guardrail-Matches, Request-Logs und Firewall-Events purgt — was Recht-auf-Löschung- / DSAR-Verpflichtungen erfüllt, während die aggregierte Audit-Historie intakt bleibt.

​

9. Wohin als Nächstes