Always-on-Agenten sind bereits da: wie Sie verhindern, dass Claude Duet zur Quelle von Datenabfluss, Fehlaktionen und Zugriffschaos wird

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany. Bei DennisCraft AI Studio setze ich produktive Agentensysteme mit Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres um, und die kritischsten Vorfälle entstehen selten durch eine einzelne Modellantwort, sondern durch einen Agenten, der im Dauerbetrieb mehr Rechte hat, als jemand sauber definiert hat.

Genau darin liegt der Unterschied bei Always-on-Agenten. Eine schwache Antwort im Chat ist lästig. Ein falscher Werkzeugaufruf um 02:13 Uhr, der Datensätze überschreibt, personenbezogene Daten in Protokolle schreibt oder einen fehlerhaften Ablauf in einer Pipeline auslöst, ist ein Betriebsproblem mit Prüf- und Meldebedarf. Wer Claude Duet als komfortable Oberfläche statt als privilegierten Akteur behandelt, baut Risiken in das System ein.

1. Die drei häufigsten Fehlerklassen im Produktivbetrieb

In Projekten für Logistik, Fintech und industrielle Automatisierung sehe ich immer wieder dieselben drei Muster: Kontextabfluss, Fehlaktionen und Zugriffschaos. Keines davon ist überraschend. Alle drei sind die Folge fehlender Grenzen im Ausführungspfad.

Kontextabfluss

Oft beginnt er mit Bequemlichkeit. Zu viele Datensätze im Prompt, zu viele interne Hinweise in Werkzeugantworten, zu viele Rohdaten in Protokollen. Der Agent erhält dadurch Kundenkennungen, interne Anmerkungen und mitunter sensible technische Informationen im selben Kontext. Das Problem ist dann nicht mehr nur die Antwortqualität, sondern die Weitergabe: in n8n-Ausführungsprotokolle, Benachrichtigungen, Dashboards oder interne Oberflächen.

Fehlaktionen

Die zweite Fehlerklasse ist die plausibel wirkende, aber sachlich falsche Aktion. Der Agent wählt den falschen Datensatz, schließt den falschen Vorgang, bildet den falschen Filter oder nimmt im Ablauf die falsche Verzweigung. In einem Chat bleibt das Text. In einem Always-on-System wird daraus ein Seiteneffekt mit realen Folgen.

Zugriffschaos

Die dritte Fehlerklasse wird am häufigsten unterschätzt. Ein temporärer Token bleibt bestehen. Ein breites Dienstkonto wird für mehrere Abläufe wiederverwendet. Eine Supabase service role versorgt plötzlich verschiedene Agenten, weil die Trennung “später” erfolgen soll. Nach wenigen Wochen kann niemand mehr eindeutig erklären, welcher Agent welche Handlung ausführen darf.

2. Das Modell darf keinen direkten Pfad zu Geheimnissen und kritischen Schreibvorgängen haben

Anthropic empfiehlt in der Dokumentation zu Tool Use ausdrücklich, Werkzeuge zu begrenzen, Eingaben zu prüfen und sensible Aktionen mit menschlicher Freigabe zu versehen. Quelle: Anthropic Docs, Tool Use, 2024, https://docs.anthropic.com/. Aus Anwendungssicht passt dazu OWASP Top 10, 2021: Unsichere Architektur und fehlerhafte Zugriffskontrolle gehören weiter zu den häufigsten Ursachen für Vorfälle. Quelle: https://owasp.org/www-project-top-ten/.

Mein Grundsatz ist klar: Das Modell darf eine Aktion anfordern, aber keine Rohgeheimnisse erhalten und nicht direkt in kritische Systeme schreiben. Zwischen Agent und Wirkung gehört eine schmale Ausführungsschicht mit klaren Verträgen.

3. Der minimale Schutzrahmen, den ich zuerst einziehe

Wenn ein Always-on-Agent bereits aktiv ist, beginne ich nicht mit Prompt-Feinschliff. Ich beginne mit getrennten Berechtigungen, statischer Analyse, Richtlinienprüfung vor Aktionen und Audit danach. Ohne diese vier Bausteine haben Sie kein steuerbares Agentensystem, sondern eine offene Automatisierungsfläche.

Statische Sicherheitsprüfung und Geheimnissuche

Wenn Agenten Python-Code oder Integrationslogik erzeugen, lasse ich vor dem Merge semgrep, bandit und gitleaks laufen. Damit finde ich früh unsichere subprocess-Muster, riskanten Datenbankzugriff und versehentlich eingespielte Geheimnisse.

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

gitleaks detect --source . --no-banner
bandit -r app -q
semgrep --config=p/security-audit --error

python -m pytest tests/test_tools.py -q
echo "checks passed"

Typisierte Operationen statt freier SQL-Ausführung

In produktiven Abläufen mit personenbezogenen Daten, Finanzbezug oder operativer Steuerung sollte SQL nicht die Standardschnittstelle des Agenten sein. Besser ist eine kleine Menge typisierter Operationen mit strikter Prüfung an der Grenze.

from pydantic import BaseModel, Field
import psycopg

class UpdateTicket(BaseModel):
    ticket_id: int = Field(gt=0)
    status: str
    actor_id: str

def update_ticket(cmd: UpdateTicket, dsn: str) -> None:
    if cmd.status not in {"open", "pending", "closed"}:
        raise ValueError("invalid status")
    with psycopg.connect(dsn) as conn:
        with conn.cursor() as cur:
            cur.execute(
                "update tickets set status=%s, updated_by=%s where id=%s",
                (cmd.status, cmd.actor_id, cmd.ticket_id),
            )
        conn.commit()

Richtlinienprüfung vor Seiteneffekten

Jede Aktion mit Außenwirkung sollte eine maschinell prüfbare Richtlinie passieren: Darf dieser Agent genau diese Handlung an genau diesem Objekt mit dieser Beleglage und in diesem Umfang ausführen? Wenn die Antwort nicht sauber positiv ist, wird blockiert oder an einen Menschen übergeben.

agent_policy:
  agent_name: claims_triage
  allow_actions:
    - read_customer_note
    - create_internal_task
  deny_actions:
    - export_pii
    - change_bank_details
  require_human_review:
    - close_claim
    - send_external_email
  limits:
    max_records_per_run: 25

4. Zugriffschaos ist meist die eigentliche Ursache des Vorfalls

Die unangenehmsten Fälle, die ich gesehen habe, kamen nicht aus der Prompt-Formulierung, sondern aus zu bequemen Berechtigungen. Ein angeblich vorübergehender Token blieb im Einsatz. Ein gemeinsames Dienstkonto trug mehrere Abläufe. Ein Berichtssystem erbte Schreibrechte, weil die Rollentrennung aufgeschoben wurde.

Für Supabase heißt das: anon, authenticated und service_role strikt trennen. Für Postgres heißt das: separate Rollen für Lesen, Schreiben und administrative Funktionen. Für n8n heißt das: Zugangsdaten je Ablauf und je Datenbereich isolieren. Wenn ein Agent mit personenbezogenen Daten oder finanzrelevanten Schritten arbeitet, sollte er keine gemeinsame Ausführungsidentität mit fachfremden Abläufen teilen.

Im DACH-Umfeld kommt ein weiterer Punkt hinzu: Nachvollziehbarkeit gegenüber DSGVO, ISO 27001, NIS2 und je nach Sektor auch BSI Grundschutz oder dem EU AI Act. Sie müssen belegen können, wer eine Aktion ausgelöst hat, welcher Kontext verfügbar war und warum das System diese Aktion ausführen durfte. Ohne diese Nachweise wird jede Vorfallanalyse unsauber.

5. Wann ich einen Always-on-Agenten als produktionsreif bezeichne

Ich nenne ein System erst dann produktionsreif, wenn mindestens diese Bedingungen erfüllt sind:

• jeder Agent besitzt eine eigene Identität und klar begrenzte Berechtigungen;
• Geheimnisse erscheinen weder in Prompts noch in modelllesbaren Werkzeugantworten;
• kritische Aktionen laufen über typisierte Schnittstellen statt über freie SQL- oder Shell-Ausführung;
• es gibt eine Richtlinienprüfung vor der Aktion und ein Audit-Protokoll danach;
• Protokolle bereinigen personenbezogene Daten und speichern keinen unnötigen Kontext;
• semgrep, bandit und gitleaks sind Teil der CI und nicht nur gelegentliche Prüfwerkzeuge.

Auch das OpenAI Cookbook zeigt in seinen Agenten- und Werkzeugbeispielen denselben praktischen Grundsatz: Strukturierte Werkzeugschnittstellen senken Fehlerrisiken, weil sie die Ausführungsfläche einschränken. Quelle: OpenAI Cookbook, 2024, https://cookbook.openai.com/. Im Produktivbetrieb hängt die Qualität des Gesamtsystems daher mindestens ebenso stark von den Ausführungsgrenzen ab wie vom Modell.

FAQ

Reicht lesender Zugriff auf Postgres für einen Agenten aus?

Das kann ausreichen, wenn es sich wirklich um lesenden Zugriff handelt und sensible Felder gefiltert werden. Auch lesender Zugriff kann aber zu Datenabfluss führen, wenn Inhalte in Protokolle, externe Werkzeuge oder Benutzeroberflächen weitergereicht werden.

Genügt menschliche Freigabe als Schutzmaßnahme?

Nein. Menschliche Freigabe ist bei sensiblen Aktionen sinnvoll, ersetzt aber keine begrenzten Berechtigungen, keine Richtlinienprüfung und keine saubere Nachvollziehbarkeit. Sonst bestätigt ein Mensch nur ein System ohne klare Grenzen.

Sollten Sie agentenerzeugtes SQL vollständig verbieten?

Für produktive Abläufe mit PII, Geldflüssen oder operativen Steuerfunktionen in der Regel ja. Für eng isolierte Analyseumgebungen kann es unter Protokollierung, Begrenzung und starker Trennung vertretbar sein.

Was ist zuerst wichtiger: Prompt-Härtung oder Werkzeug-Härtung?

Zuerst Werkzeug-Härtung und Zugriffskontrolle. Prompts lassen sich iterativ verbessern, aber zu breite Berechtigungen beschädigen das System auch dann, wenn der Prompt ordentlich formuliert ist.

Woran erkennen Sie Zugriffschaos frühzeitig?

Wenn Ihr Team nicht innerhalb von 15 Minuten alle Agentenidentitäten, Zugangsdaten und erlaubten Aktionen benennen kann, ist das Problem bereits da. Ein weiteres klares Signal ist ein gemeinsamer Token für mehrere fachlich getrennte Abläufe.

An welcher Stelle Ihrer LLM-Pipeline finden Sie im Produktivbetrieb derzeit die meisten Probleme: bei der statischen Sicherheitsprüfung, in der isolierten Laufzeitumgebung, in der Richtlinienprüfung vor der Ausführung oder in der menschlichen Freigabe? Mich interessiert ehrlich, wie sich das mit den Mustern deckt, die ich in DACH-Systemen sehe.
Ich biete einen kostenlosen 30-Minuten-Stack-Audit für Gründer und CTOs an, die KI für regulierte Märkte bauen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.