Wie Sie ein SOC-2-Audit bestehen, wenn Sie KI-Agenten einsetzen

Die gute Nachricht: Die Trust Services Criteria (TSC) von SOC 2 sind technologieneutral. Nichts im Standard besagt „Sie dürfen keine KI verwenden“. Die Kriterien interessieren sich für Kontrollen und Nachweise, nicht dafür, welche Art von Prozess die Aktion ausführt. Die schlechte Nachricht: Die Standardhaltung der meisten LLM-Agenten-Stacks — undurchsichtiges Reasoning, unstrukturierte Logs, keine Durchsetzung — besteht diese Kontrollen von Haus aus nicht. Dieser Leitfaden zeigt genau, was zu ändern ist.

Was ein Prüfer tatsächlich fragt

Ein SOC-2-Type-II-Audit prüft, ob Ihre Kontrollen über einen Zeitraum (typischerweise 6–12 Monate) wirksam funktioniert haben. Der Prüfer stellt keine abstrakten Fragen zur „KI-Sicherheit“. Er stellt konkrete Fragen, meist zugeordnet zur Common-Criteria-Reihe (CC):

• CC6.1 (logischer Zugriff): Wer oder was hat diese Aktion ausgelöst? War der Auslöser autorisiert? Wie wird diese Autorisierung durchgesetzt?
• CC7.2 (Systemüberwachung): Wie würden Sie erkennen, dass ein Agent eine unbefugte oder anomale Aktion ausgeführt hat?
• CC7.3 (Incident Response): Wenn ein Agent sich fehlverhält, wie wird er eingedämmt, untersucht und gemeldet? Zeigen Sie mir die letzten drei Vorfälle.
• CC8.1 (Change Management): Wie werden Agentenrichtlinien, Prompts und Tool-Berechtigungen geändert? Wer genehmigt? Wo wird das festgehalten?

Jede Frage braucht eine Antwort, die durch Artefakte belegt ist — Logs, Tickets, Freigaben —, die eine unabhängige Person stichprobenartig prüfen und verifizieren kann.

„Das Modell hat es getan“ ist keine Audit-Antwort

Die größte Einzelquelle für SOC-2-Reibung bei KI-Agenten-Teams ist die Versuchung, das Modell als Akteur darzustellen. Das ist es nicht. Das Modell ist ein Subsystem innerhalb Ihres Dienstes, betrieben im Auftrag eines Prinzipals (eines Nutzers, eines Dienstkontos, einer Organisation). Dieser Prinzipal ist es, der den Prüfer interessiert. „Das LLM hat entschieden, die E-Mail zu senden“ ist ein Eingeständnis des Geltungsbereichs, keine Kontrolle. Jede Aktion, die ein Agent ausführt, muss auf einen autorisierten Prinzipal zurückführbar sein, unter einer Richtlinie ausgeführt und in einem append-only-Audit-Log festgehalten werden. Fehlt eine dieser drei Eigenschaften, haben Sie eine Beanstandung.

Die vier Nachweis-Artefakte

Streicht man die framework-spezifische Sprache, lässt sich SOC 2 für KI-Agenten auf vier Artefakte herunterbrechen. Wenn Sie diese auf Anfrage liefern können, ist das Audit eine Formalität.

1. Richtlinien-Entscheidungsprotokolle

Jeder Tool-Aufruf, den ein Agent versucht, muss eine Richtlinien-Engine durchlaufen, und jede Auswertung muss protokolliert werden: welche Richtlinie ausgelöst wurde, mit welchen Eingaben, wie die Entscheidung lautete und warum. Dies ist die Kontrolle, die CC6.1 (Autorisierung) erfüllt, und das Rückgrat jedes anderen Artefakts. Das Protokoll sollte nach Agent, Richtlinie, Zeitraum und Ergebnis (Erlauben / Verweigern / Freigabe erforderlich) abfragbar sein.

2. Freigaben mit Nutzeridentität

Wenn eine Agentenaktion eine menschliche Freigabe erforderte, muss das Protokoll zeigen, welcher Mensch sie zu welchem Zeitpunkt und auf Basis welcher Informationen genehmigt hat. Prüfer ziehen Stichproben bestimmter Freigaben und fragen nach der Kette: die ursprüngliche Anfrage, die Richtlinie, die eine Freigabe erforderte, die menschliche Entscheidung, das Ausführungsergebnis. Eine Slack-Nachricht mit einer Emoji-Reaktion zählt nicht; die Freigabe muss dauerhaft und an eine authentifizierte Identität gebunden sein.

3. Vorfall-Zeitleisten

CC7.3 will sehen, dass Sie bemerken, reagieren und dokumentieren, wenn etwas schiefgeht. Bei Agentensystemen bedeutet „etwas geht schief“: blockierte Aktionen stiegen sprunghaft an, ein Injection-Versuch wurde erkannt, eine Richtlinie wurde verletzt, ein Kostenbudget wurde überschritten. Jeder Vorfall braucht eine Zeitleiste (erstes Signal → Triage → Eindämmung → Behebung), einen Verantwortlichen und eine Nachbetrachtung. Prüfer erwarten keine null Vorfälle; sie erwarten einen rigorosen Umgang mit denen, die auftreten.

4. Aufbewahrung von mindestens 1 Jahr

Ein SOC-2-Type-II-Audit blickt über ein Fenster von 6–12 Monaten zurück. Wenn Ihre Richtlinien-Entscheidungsprotokolle, Freigabeaufzeichnungen und Vorfall-Artefakte nach 30 oder 90 Tagen gelöscht werden, kann der Prüfer keine Stichproben ziehen. 365 Tage Aufbewahrung sind das effektive Minimum und gehören zu den ersten Dingen, nach denen beim Audit-Kickoff gefragt wird. Manche Prüfer akzeptieren eine kürzere Aufbewahrung für unkritische Telemetrie, wenn Sie nachweisen können, dass kritische Aufzeichnungen anderswo erhalten bleiben — es ist jedoch weit einfacher, die vollständige Spur aufzubewahren.

Zuordnung der Trust Services Criteria zu Plattform-Funktionen

Ein 90-Tage-Plan zur Prüfungsreife

Angenommen, Sie starten bei „Wir haben Agenten in der Produktion, aber noch keine formalen Kontrollen“ — hier ist ein realistischer Wochenplan für ein Team von 2–4 Engineers.

Wochen 1–2: Inventarisierung

Listen Sie jeden KI-Agenten in der Produktion auf. Für jeden: Was tut er, welche Tools kann er aufrufen, welche Daten liest er, welcher Prinzipal betreibt ihn, wo liegen heute seine Logs? Dies ist die Geltungsbereichsdefinition, mit der Ihr Prüfer arbeiten wird. Jeder Agent, der nicht auf der Liste steht, taucht später als Beanstandung auf.

Wochen 3–4: Instrumentierung

Leiten Sie jeden Agenten durch ein Governance-SDK, sodass jeder Tool-Aufruf beobachtet und jede Richtlinien-Entscheidung protokolliert wird. In dieser Phase kann die Durchsetzung noch permissiv sein (alles erlauben, nur beobachten) — das Ziel ist eine vollständige, strukturierte Audit-Spur. Stellen Sie sicher, dass Sie die letzten N Agentenaktionen nach Prinzipal, Tool und Ergebnis abfragen können.

Wochen 5–6: Richtlinien

Schreiben Sie zuerst Richtlinien für die risikoreichsten Tool-Aufrufe: alles, was Geld, externe Kommunikation, Datenlöschung oder erhöhte Privilegien betrifft. Stellen Sie die Durchsetzung dafür von permissiv auf blockierend um. Fügen Sie dort, wo sinnvoll, menschliche Freigabe-Gates hinzu. Versionieren Sie Richtlinien — Prüfer fragen nach der Änderungshistorie.

Wochen 7–8: Incident Response

Definieren Sie, was ein „Agenten-Vorfall“ ist (eine blockierte gefährliche Aktion, ein Injection-Versuch, eine Budgetüberschreitung), verdrahten Sie Alarme mit einem Oncall-Kanal, dokumentieren Sie das Runbook. Führen Sie einen Game-Day durch: simulieren Sie einen Vorfall, gehen Sie Erkennung, Triage, Eindämmung und Nachbetrachtung durch. Sichern Sie die Artefakte.

Wochen 9–10: Aufbewahrung und Export

Bestätigen Sie, dass Richtlinien-Entscheidungsprotokolle, Freigaben und Vorfälle mindestens 365 Tage aufbewahrt werden. Üben Sie den Export-Pfad: erzeugen Sie einen Compliance-Bericht für ein Beispiel-Fenster von 30 Tagen und gehen Sie ihn durch, als wären Sie der Prüfer. Schließen Sie die Lücken, bevor es das echte Audit tut.

Wochen 11–13: Tabletop und Puffer

Führen Sie ein Mock-Audit durch. Idealerweise mit jemandem außerhalb des Teams, der naive Fragen stellen und die Lücken aufspüren kann. Beheben Sie, was auftaucht. Planen Sie das echte Engagement erst, wenn das Mock-Audit nichts Substanzielles mehr zutage fördert.

Anhang: Prüfer-Q&A

Fünf Fragen, die Sie in den ersten zehn Minuten des Engagements beantworten können sollten, mit dem Artefakt, dem jede zugeordnet ist:

1. „Zeigen Sie mir eine einzelne Aktion, die ein Agent letzten Dienstag ausgeführt hat, und führen Sie mich durch, wie sie autorisiert wurde.“ → Den Trace abrufen, den auslösenden Prinzipal zeigen, die ausgelöste Richtlinie zeigen, das Entscheidungsprotokoll zeigen.
2. „Wie würden Sie erkennen, dass ein Agent begonnen hat, ein Tool aufzurufen, das er nicht aufrufen darf?“ → Die Allowlist in der Richtlinie zeigen, den Alarm für die blockierte Aktion und den Vorfall, der sich öffnen würde.
3. „Wer hat die letzte Richtlinienänderung in der Produktion genehmigt?“ → Richtlinien-Versionshistorie mit Identität des Genehmigenden und Zeitstempel.
4. „Zeigen Sie mir jeden Vorfall des letzten Quartals und wie er behoben wurde.“ → Vorfall-Liste, nach Datum gefiltert, mit Zeitleiste und Nachbetrachtung je Eintrag.
5. „Wie lange bewahren Sie diese Aufzeichnungen auf?“ → 365 Tage, dokumentiert in der Datenaufbewahrungsrichtlinie, auf Plattformebene durchgesetzt.

Die Abkürzung

Jede Kontrolle oben lässt sich von Grund auf selbst bauen. Die meisten Teams sollten das nicht. Richtlinien-Engines, Audit-Pipelines, Freigabe-Workflows, Incident-Management und Aufbewahrungsinfrastruktur sind monatelange Engineering-Arbeit, die nichts zu dem Produkt beiträgt, für das Ihre Kunden bezahlen. Der Sinn einer Governance-Plattform besteht darin, alle vier Nachweis-Artefakte — Richtlinien-Entscheidungen, Freigaben, Vorfälle, Aufbewahrung — ab Tag eins zu liefern, sodass es im Audit um Ihre Geschäftslogik statt um Ihre Infrastruktur geht.

Weiterführende Lektüre: Was ist KI-Agenten-Governance? und Prompt-Injection-Angriffe auf KI-Agenten. Die vollständige Zuordnung von TSC → Kontrollen finden Sie auf der Compliance-Seite.