Geben Sie KI-Agenten keine Produktionsschlüssel: neue Control Planes und Freigabe-Gates für nicht rückgängig zu machende Aktionen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und self-hosted Postgres. Der kritische Moment im Produktivbetrieb ist nicht die mittelmäßige Antwort eines Agenten, sondern der Augenblick, in dem derselbe Agent einen echten Produktionsschlüssel besitzt und nur noch einen Werkzeugaufruf davon entfernt ist, Datensätze zu löschen, Kunden anzuschreiben, Berechtigungen zu ändern oder Auszahlungen auszulösen.

Wenn die Laufzeitumgebung Ihres Agenten direkten Zugriff auf Produktionsgeheimnisse hat, haben Sie Denken und Entscheidungsbefugnis in einer Komponente zusammengelegt. Genau dort beginnt das Problem. Viele Teams bemerken es erst nach den ersten erfolgreichen Vorführungen: Der Agent wirkt nützlich, kann “selbstständig” handeln, und dann versucht man, das Risiko mit längeren Systemanweisungen zu begrenzen. Das reicht nicht. Ein Prompt ist keine Sicherheitsprüfung und kein Berechtigungskonzept.

Das eigentliche Problem ist Berechtigung, nicht Modellqualität

Sprachmodelle wählen aus vorhandenem Kontext den wahrscheinlichsten nächsten Schritt. Sie sind keine Richtlinien-Engine und kein Ersatz für Freigabeprozesse. OWASP benennt in der LLM Top 10, Ausgabe 2025, ausdrücklich excessive agency und insecure output handling als reale Risiken für Systeme, in denen Modellausgaben direkt produktive Aktionen auslösen: https://genai.owasp.org/llm-top-10/

Für die Praxis ist außerdem die Dokumentation von Anthropic zu Tool Use und Systemgrenzen relevant. Der wiederkehrende Grundsatz lautet: Werkzeuge eng einschränken, außerhalb des Modells prüfen und das Modell als Planer behandeln, nicht als letzte Instanz. Quelle: Anthropic Docs, 2025, https://docs.anthropic.com/

Wo direkte Schlüssel im Betrieb scheitern

Der Grundsatz ist klar: Ein Agent darf eine Aktion vorschlagen, aber nicht ohne weitere Instanz produktiv ausführen.

Wie ein tragfähiger Control Plane für Agenten aussieht

Ich trenne solche Systeme in 3 Ebenen.

1. Reasoning Plane

Hier arbeitet Claude oder ein anderes Modell. Diese Ebene liest Kontext, wertet Signale aus und formuliert Aktionsvorschläge. Sie darf lesenden Zugriff auf freigegebene Daten und Aktionsdefinitionen haben, aber keine langlebigen Produktionsschlüssel.

2. Policy- und Freigabe-Ebene

Ein separater Dienst nimmt die vorgeschlagene Aktion entgegen, überführt sie in ein festes Schema, bewertet das Risiko und entscheidet zwischen automatischer Freigabe, menschlicher Prüfung oder Ablehnung. In die Entscheidung fließen Umgebung, Betrag, Datensatzanzahl, Zielressource, Rückgängigmachbarkeit und Identität des Auslösers ein.

3. Ausführungsebene

Nur diese Ebene darf kurzlebige Zugangsdaten besitzen und Produktions-APIs aufrufen. Sie führt keine beliebigen Texte des Modells aus, sondern nur typisierte Aktionsverträge nach Prüfung, Idempotenzkontrolle und Protokollierung.

from dataclasses import dataclass
from typing import Literal

@dataclass
class ProposedAction:
    action_type: Literal["send_email", "run_sql", "issue_refund"]
    payload: dict
    reason: str
    actor_id: str
    environment: Literal["staging", "prod"]

def approval_required(action: ProposedAction) -> bool:
    if action.environment == "prod":
        return True
    if action.action_type in {"run_sql", "issue_refund"}:
        return True
    if action.action_type == "send_email" and action.payload.get("recipient_count", 1) > 5:
        return True
    return False

Das ist keine akademische Übung, sondern eine bekannte Trennung von Zuständigkeiten, übertragen auf agentische Systeme.

Freigabe-Gates müssen formal sein

Eine Formulierung wie „wenn es gefährlich wirkt, fragen Sie einen Menschen“ ist im Produktivbetrieb zu unpräzise. Das Modell muss eine strukturierte Absicht liefern, und das Gate muss diese gegen feste Regeln prüfen.

Welche Felder in jede Prüfung gehören

Mindestens erforderlich sind: action_type, target_resource, environment, initiator, expected_impact, reversibility, idempotency_key und ein für Menschen lesbarer Unterschied zwischen vorher und nachher. Bei SQL sollte eine Schätzung der betroffenen Zeilen vorliegen. Bei E-Mails benötigen Sie Empfänger und die endgültige Vorschau des Inhalts. Bei Konfigurationsänderungen braucht es einen Vorher-Nachher-Vergleich.

approval_rules:
  - action_type: run_sql
    environment: prod
    require_human: true
  - action_type: send_email
    environment: prod
    recipient_count_gt: 5
    require_human: true
  - action_type: issue_refund
    amount_eur_gt: 0
    require_human: true
  - action_type: update_user_role
    environment: any
    require_human: true

Solche Regeln lassen sich in Postgres oder Supabase ablegen und aus n8n-Workflows aufrufen. In regulierten Umgebungen ist das nicht nur technisch sinnvoll, sondern auch für Nachweisbarkeit wichtig. Für DSGVO, ISO 27001, NIS2 oder BSI Grundschutz zählt nicht nur, was das System getan hat, sondern wer die Freigabe nach welcher Regel erteilt hat. Mit Blick auf den EU AI Act ist genau diese Governance-Schicht in vielen Unternehmensanwendungen keine Kür, sondern saubere Vorsorge.

Welche Schutzschichten Sie sofort einziehen sollten

Geheimnisse trennen

Mit Doppler oder einem vergleichbaren Secret Manager geben Sie Produktionsschlüssel ausschließlich an die Ausführungsebene. Die Modelllaufzeit darf diese Schlüssel nicht besitzen.

Quellcode und Geheimnisfunde automatisiert prüfen

semgrep, bandit und gitleaks gehören in die CI-Pipeline. bandit findet unsichere Python-Muster. gitleaks erkennt versehentlich eingecheckte Zugangsdaten. semgrep eignet sich gut für projektspezifische Prüfregeln, etwa für unkontrollierte SQL-Ausführung oder zu offene Werkzeug-Handler.

python -m pip install bandit
bandit -r app/

docker run --rm -v "$PWD:/repo" semgrep/semgrep semgrep \
  --config=p/security-audit /repo

gitleaks detect --source . --verbose

Datenbankrollen klar trennen

In Postgres bevorzuge ich getrennte Rollen wie read_only_agent, action_executor und human_admin. Der Agent erhält nur Lesezugriff. Schreiboperationen laufen über gespeicherte Prozeduren mit engem Vertrag oder über einen Ausführungsdienst mit Richtlinienprüfung und Protokollierung.

Was im DACH-B2B als nicht rückgängig zu machen gilt

Viele Teams denken zuerst an DELETE-Befehle. Das greift zu kurz. Nicht rückgängig zu machen ist im Unternehmensalltag oft nicht nur technisch zu verstehen, sondern auch rechtlich oder prozessual. Eine E-Mail an einen Kunden mit falscher SLA-Aussage können Sie nicht einfach mit einem Datenbank-Rollback heilen. Dasselbe gilt für KYC-Statusänderungen, das Schließen eines Vorfalls ohne Betreiberbestätigung, den Export personenbezogener Daten oder die Änderung von Aufbewahrungsregeln.

Deshalb trenne ich Denkspuren des Modells strikt von Nachweisunterlagen. Die innere Begründung eines Modells ist kein belastbarer Prüfpfad. Belastbar sind eine signierte Aktionsanforderung, eine Richtlinienentscheidung, ein Freigabevermerk und ein Ausführungsprotokoll.

FAQ

Reicht Human-in-the-Loop aus?

Allein nicht. Menschliche Prüfung ist nur dann sinnvoll, wenn die prüfende Person eine strukturierte Aktion mit Ziel, Auswirkung und Unterschiedsbeschreibung sieht. Freitext des Agenten ist dafür keine gute Grundlage.

Darf ein Agent in Staging schreiben?

Ja, das kann den Entwicklungszyklus beschleunigen. Wichtig ist nur, dass die Grenze zwischen Staging-Autonomie und Produktionsbefugnis hart und nachvollziehbar bleibt.

Kann ich rückgängig zu machende Aktionen automatisch freigeben?

Teilweise ja, sofern Rückgängigmachbarkeit systemseitig definiert ist und durch Idempotenz, Protokollierung und getestete Rücksetzpfade abgesichert wird. Das Modell darf diese Einstufung nicht selbst festlegen.

Braucht ein kleines Team wirklich einen eigenen Richtlinien-Dienst?

Ja, auch wenn er anfangs sehr schlank sein kann. Eine kleine Python-Anwendung mit Postgres-Tabelle für Regeln reicht oft aus. Entscheidend ist die architektonische Trennung.

Was ist der erste sinnvolle Schritt bei einem bestehenden Agenten?

Erfassen Sie alle Aktionen, die der Agent heute auslösen kann, markieren Sie die nicht rückgängig zu machenden Vorgänge und entfernen Sie zuerst Produktionsgeheimnisse aus der Modelllaufzeit. Danach bauen Sie Ausführungsebene und Freigabe-Gate um diese Aktionen herum.

An welcher Stelle Ihrer LLM-Pipeline finden Sie heute die meisten Probleme im Produktivbetrieb: bei der statischen Analyse, in der Laufzeit-Isolierung oder in der menschlichen Freigabe vor der Ausführung? Mich interessiert, wie andere Teams das in realen Systemen lösen.

Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Founder an, die KI in regulierten Märkten bauen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.