Hat Ihr KI-Agent bereits auf die Produktivumgebung zugegriffen? So bauen Sie reproduzierbare Sicherheitsprüfung und einen nachweisbaren Audit-Trail vor dem ersten Vorfall

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio liefere ich produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der kritische Moment beginnt nicht, wenn ein KI-Agent Text erzeugt oder einen Ablauf vorschlägt, sondern dann, wenn er erstmals Schreibzugriff auf Produktivdaten, Berechtigungen oder externe APIs mit fachlichen und rechtlichen Folgen erhält.

Wenn an dieser Stelle keine reproduzierbare Sicherheitsprüfung und kein nachweisbarer Audit-Trail vorhanden sind, entsteht ein Problem lange vor dem ersten echten Vorfall. Nach einer strittigen Aktion müssen Sie vier Fragen belegen können: Was hat der Agent gesehen, welche Entscheidung wurde getroffen, welche Regelversion galt, und warum wurde die Aktion zugelassen oder blockiert?

Was ein reproduzierbarer Prüfpfad leisten muss

Viele Teams protokollieren nur das Ergebnis: „Datensatz geändert“ oder „Workflow ausgeführt“. Für agentische Systeme reicht das nicht. Sie benötigen einen Prüfpfad, der sich in einer isolierten Umgebung mit denselben Eingaben und denselben Regeln erneut ausführen lässt.

Ich sichere dafür pro sensibler Aktion mindestens 5 Artefakte.

1. Normalisierte Eingaben

Dazu gehören Prompt-Felder, Mandantenkennung, Werkzeugparameter, Benutzerkontext und gegebenenfalls ausgewählte Datensätze. Ohne diesen Kontext bleibt unklar, ob der Fehler im Modell, in der Orchestrierung, im Abrufkontext oder in der Rechtevergabe lag.

2. Versionsstand der Regeln

Entscheidend ist nicht nur, dass eine Prüfung stattgefunden hat, sondern unter welcher Version. Ich speichere deshalb Commit-Hash, Regelkonfiguration oder Allowlist-Stand direkt am Ereignis. Ohne diese Angabe ist eine spätere Wiederholung unzuverlässig.

3. Strukturierte Entscheidungsdaten

Ich protokolliere keine frei formulierten Gedankengänge, sondern einen knappen Entscheidungsdatensatz: angeforderte Aktion, Risikoklasse, blockierende Regel, zulassende Regel und gegebenenfalls Prüfbedarf durch eine Person.

4. Tatsächliche Wirkung

Hierzu gehören SQL-Abfragen, API-Anfragen, Antwortcodes, Anzahl geänderter Zeilen, Laufzeit und Rücksetzungsstatus. Wenn n8n beteiligt ist, sollte die Ausführungskennung mitgeführt werden.

5. Wiederholbarkeit

Reproduzierbarkeit bedeutet, dass Sie ein Ereignis aus der Vergangenheit anhand derselben Eingangsdaten und Regelversion noch einmal prüfen können. Für ISO 27001, BSI-Grundschutz oder NIS2-nahe Nachweisführung ist genau diese Nachvollziehbarkeit entscheidend.

Warum Eingabeaufforderungen keine Sicherheitsgrenze sind

Eine gute Eingabeaufforderung kann Fehlverhalten reduzieren, ersetzt aber keine technische Durchsetzung. Sobald ein Agent Werkzeuge aufrufen, Daten ändern oder externe Nebenwirkungen auslösen kann, liegt die eigentliche Kontrolle in Richtlinien, Bereichsbegrenzungen und Protokollierung.

OWASP benennt in den Top 10 for LLM Applications 2025 unter anderem Excessive Agency und Insecure Output Handling als praktische Risiken für Systeme mit Handlungsspielraum: https://genai.owasp.org/. Auch Anthropic empfiehlt in der Dokumentation zur Werkzeugnutzung eine Begrenzung verfügbarer Werkzeuge, Eingabevalidierung und menschliche Freigaben für sensible Vorgänge: https://docs.anthropic.com/.

Für regulierte DACH-Umgebungen kommt ein weiterer Aspekt hinzu: DSGVO, EU AI Act und interne Kontrollsysteme verlangen keine perfekte Theorie, sondern belegbare Zuständigkeit, Protokollierung und Begrenzung von Risiken im Produktivbetrieb.

Eine kleine, aber tragfähige Architektur in Postgres

Sie brauchen dafür keine große Spezialplattform. In vielen Fällen genügt ein sauberes Ereignismodell in Postgres, ergänzt durch Ihre Orchestrierung in n8n und gegebenenfalls Supabase für Oberflächen oder Freigaben.

create table agent_audit_events (
  id uuid primary key,
  created_at timestamptz not null default now(),
  tenant_id text not null,
  actor_type text not null,
  actor_id text not null,
  action_name text not null,
  input_hash text not null,
  policy_version text not null,
  risk_class text not null,
  decision text not null,
  requires_review boolean not null default false,
  execution_ref text,
  payload jsonb not null,
  outcome jsonb
);

Wichtig ist, dass das Ereignis vor der eigentlichen Ausführung geschrieben wird. Andernfalls besteht ein Zeitfenster, in dem der Agent bereits gehandelt hat, ohne sauber erfasst zu sein.

Beispiel für einen Ereignissatz vor der Ausführung

import hashlib
import json
import uuid
from datetime import datetime, timezone

def build_audit_event(tenant_id, actor_id, action_name, payload, policy_version):
    raw = json.dumps(payload, sort_keys=True).encode()
    return {
        "id": str(uuid.uuid4()),
        "created_at": datetime.now(timezone.utc).isoformat(),
        "tenant_id": tenant_id,
        "actor_type": "ai_agent",
        "actor_id": actor_id,
        "action_name": action_name,
        "input_hash": hashlib.sha256(raw).hexdigest(),
        "policy_version": policy_version,
        "risk_class": "high",
        "decision": "pending",
        "payload": payload
    }

Der input_hash ist besonders wertvoll. Selbst wenn Inhalte aus Datenschutzgründen später gekürzt oder pseudonymisiert werden, bleibt der Bezug zum ursprünglichen Ereignis erhalten.

So strukturiere ich die Sicherheitsprüfung vor produktiven Agentenaktionen

Ich trenne die Prüfung in 3 Stufen: vor der Ausführung, während der Freigabe und nach der Ausführung.

1. Vorprüfung statischer Artefakte

Wenn ein Agent Code, SQL oder Konfiguration erzeugt, lasse ich diese Artefakte zunächst durch feste Prüfer laufen. semgrep, bandit und gitleaks sind dafür ein pragmatischer Start.

#!/usr/bin/env bash
set -euo pipefail

target_dir="${1:-./candidate}"
semgrep --config=p/owasp-top-ten "$target_dir"
bandit -r "$target_dir" -f txt
gitleaks dir "$target_dir" --no-banner

echo "static checks passed"

Das verhindert nicht jeden Fehler, fängt aber wiederkehrende Muster früh ab: Geheimnisse im Code, unsichere Dateizugriffe, problematische SQL-Konstrukte oder fragwürdige Standardbibliotheksnutzung.

2. Richtliniengesteuerte Ausführung

Jeder Werkzeugaufruf wird über eine Richtlinienschicht geführt. Ich unterscheide dabei in der Regel zwischen Lesezugriff, Schreibzugriff im engen Mandantenkontext und externen Nebenwirkungen wie Zahlungen, Benachrichtigungen oder Berechtigungsänderungen.

3. Nachprüfung der Wirkung

Nach der Ausführung prüfe ich Fachinvarianten: Anzahl geänderter Zeilen, Einhaltung der Mandantengrenzen, zulässiger Ressourcentyp und Möglichkeit zur Rücknahme. Auffälligkeiten entstehen oft nicht im Modell, sondern in fehlenden Prüfungen der umgebenden Anwendung.

Typische Fehlerbilder in DACH-Projekten

Gerade blockierte Aktionen sind wertvoll. Sie zeigen, an welcher Stelle Ihr Agent wiederholt versucht, eine Grenze zu überschreiten, die Ihr System nur unvollständig modelliert hat.

FAQ

Muss der vollständige Prompt gespeichert werden?

Nicht zwingend. In DSGVO-sensiblen Umgebungen ist oft eine gekürzte Darstellung plus strukturierter Kontext und Hash des Originals sinnvoller. Für Wiederholbarkeit reicht das häufig aus.

Reicht die Ausführungshistorie von n8n?

Nein. Sie ist nützlich, ersetzt aber keine getrennte Dokumentation von Richtlinienentscheidung, Risikoklasse und Freigabestatus. Ich betrachte n8n als Teil des Audit-Trails, nicht als dessen vollständige Umsetzung.

Braucht jede Schreibaktion eine menschliche Freigabe?

Nein. Niedrigrisikofälle in eng begrenztem Mandantenkontext können automatisiert laufen. Datenlöschung, Rechteänderungen, mandantenübergreifende Zugriffe oder zahlungsrelevante Vorgänge sollten deutlich strenger abgesichert werden.

Was ist der Unterschied zwischen Protokollierung und Wiederholung?

Die Protokollierung zeigt, was geschehen ist. Die Wiederholung zeigt, ob unter denselben Eingaben und denselben Regeln dieselbe Entscheidung erneut entstehen würde. Für die Vorfallanalyse ist das ein wesentlicher Unterschied.

Ist das nur für große Unternehmen relevant?

Nein. Gerade kleinere Teams profitieren davon, weil sie weniger Zeit für manuelle Aufklärung haben und bei ersten Unternehmenskunden weniger Spielraum für Fehler besteht.

Wenn Ihr KI-Agent bereits auf Produktivdaten zugreift oder Änderungen ausführen kann: An welcher Stelle Ihrer Pipeline würden Sie die nächste strittige Aktion zuerst erkennen — bei der statischen Prüfung, in der Richtlinienschicht zur Laufzeit oder erst nach einer Kundenmeldung? Diese Antwort interessiert mich wirklich.
I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.