Anti-Pattern Agents Without Guardrails: Agenten ohne Leitplanken

Idee in 30 Sekunden

Agents Without Guardrails ist ein Anti-Pattern, bei dem ein Agent Aktionen ohne erzwungene Runtime-Regeln ausführt: policy-gate, Allowlist, Scope-Kontrolle, Budget-Limits und klare stop_reason.

Dadurch wird ein Modellfehler oder falsches Routing zu einem echten operativen Problem: unnötige Aufrufe, unerwünschte Aktionen, Budget-Überverbrauch oder riskanter Zugriff im falschen Kontext.

Einfache Regel: Leitplanken müssen im Code und in der Execution-Schicht leben, nicht nur im Prompt.

Beispiel für das Anti-Pattern

Das Team startet einen Support-Agenten, der Daten suchen, Status aktualisieren und Nachrichten senden kann.

Der Agent bekommt breiten Tool-Zugriff ohne zentralisierte Runtime-Regeln.

decision = agent.next_action(user_message)
result = run_tool(decision.tool, decision.args)
return result

In diesem Setup fehlt die Basiskontrolle:

# keine route-basierte Allowlist
# kein deny-by-default für riskante Aktionen
# kein tenant/env scope enforcement
# keine budget/step/time Limits

In diesem Ansatz geht der Run ohne policy-gate direkt in die Ausführung, daher werden riskante Schritte nicht am Entscheidungspunkt gestoppt.

In so einem Setup führt fehlendes Guardrailing zu:

• unvorhersehbaren Zustandsänderungen
• Risiko falscher oder unnötiger Aufrufe
• schwieriger Incident-Analyse ohne klare Verantwortungsgrenze

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn Teams zuerst darauf optimieren, "dass der Agent mehr kann", und Kontrollgrenzen auf später verschieben.

Typische Ursachen:

• zu viel Vertrauen in Prompt-Instruktionen statt erzwungener Runtime-Prüfungen
• keine separate Gateway-Schicht für Policy-Entscheidungen
• gemischte Rollen: der Agent plant und führt riskante Aktionen selbst aus, ohne Prüfungen
• niemand besitzt explizit Zugriffsregeln, Limits und Audit

Daraus entstehen Probleme:

• riskante Aktionen ohne Kontrolle - der Agent kann einen gefährlichen Schritt in einem ungeeigneten Szenario ausführen
• Ressourcen-Überverbrauch - ohne Budget- und Step-Limits steigen Kosten und Latenz pro Run
• Kontextfehler - ohne Scope-Enforcement kann die Aktion den falschen tenant/env treffen
• unklare Verantwortungsgrenzen - ein Incident ist schwer zwischen Agent und Gateway zu lokalisieren
• wiederholte Incidents - das Team korrigiert Folgen, aber nicht die Ursache

Im Unterschied zu Write Access by Default ist das Problem hier breiter: Es fehlen nicht nur write-Limits, sondern allgemeine Execution-Grenzen für den ganzen Run.

Typische Production-Signale für fehlende oder schwache Leitplanken:

• potenziell gefährliche Tool-Aufrufe gehen durch, obwohl approval_required oder policy_denied erwartet wird
• blocked attempts sind selbst auf riskanten Routen selten
• Runs erreichen oft max_steps oder Budget-Überschreitung ohne frühen Stop
• Audit-Logs zeigen nicht, welche Regel eine Aktion erlaubt oder blockiert hat
• das Team kann nicht schnell erklären, warum ein konkreter Tool-Call ausgeführt wurde

Jeder Tool-Aufruf ist eine operative Entscheidung. Wenn Ausführungsgrenzen nicht erzwungen sind, verhält sich das Agentensystem selbst in einfachen Szenarien unvorhersehbar.

Richtiger Ansatz

Startet mit einem minimalen, aber harten Satz von Runtime-Leitplanken. Jeder Schritt passiert entweder die Policy-Prüfung oder stoppt den Run mit klarem stop_reason.

Wenn ihr bei null startet, versucht nicht alles gleichzeitig auszurollen. Erster Mindestumfang: deny-by-default, route-basierte Allowlist, Scope-Enforcement (tenant/env) und explizite stop_reason für Policy-Ablehnungen.

Praktischer Rahmen:

• deny-by-default für gefährliche oder unbekannte Aktionen
• Tool-Allowlist nach Rolle und Route
• verpflichtender Scope (tenant_id, env) aus authenticated context
• step/time/budget Limits für jeden Run
• separater Approval-Schritt für riskante write-Operationen
• Policy-Entscheidungslog für jeden Tool-Aufruf

ALLOWED_TOOLS_BY_ROUTE = {
    "faq": {"kb.search"},
    "refund": {"order.get", "refund.create"},
}
WRITE_TOOLS = {"refund.create", "ticket.close", "email.send"}


def execute_step(decision, ctx):
    allowed = ALLOWED_TOOLS_BY_ROUTE.get(ctx["route"], set())

    if decision.tool not in allowed:
        return stop("policy_denied:tool_not_allowed")

    if decision.tool in WRITE_TOOLS and not has_approval(ctx, decision):
        return stop("approval_required")

    if exceeds_budget(ctx):
        return stop("budget_exceeded")

    scoped_args = enforce_scope(
        decision.args,
        tenant_id=ctx["tenant_id"],
        env=ctx["env"],
    )
    return run_tool(decision.tool, scoped_args)

In diesem Setup arbeitet der Agent innerhalb kontrollierter Grenzen: erlaubte Aktionen laufen durch, riskante oder ungültige Schritte stoppen transparent.

Schnelltest

Wenn ihr diese Fragen mit "ja" beantwortet, habt ihr ein Risiko für das Anti-Pattern Agents Without Guardrails:

• Kann der Agent ein Tool ohne explizite Policy-Prüfung aufrufen?
• Erscheinen bei riskanten Schritten policy_denied oder approval_required fast nie?
• Kann das Team nicht schnell erklären, warum eine konkrete Aktion erlaubt wurde?

Worin es sich von anderen Anti-Patterns unterscheidet

Write Access by Default vs Agents Without Guardrails

Kurz gesagt: Write Access by Default betrifft ein unsicheres write-Zugriffsmodell, Agents Without Guardrails betrifft fehlende Ausführungsgrenzen insgesamt.

Blind Tool Trust vs Agents Without Guardrails

Kurz gesagt: Blind Tool Trust betrifft Datenzuverlässigkeit vor der Aktion, Agents Without Guardrails betrifft Grenzen der erlaubten Aktionen.

No Stop Conditions vs Agents Without Guardrails

Kurz gesagt: No Stop Conditions betrifft Loop-Beendigung, Agents Without Guardrails betrifft breitere sichere Ausführungsgrenzen.

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für anti-pattern Agents Without Guardrails.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Reicht es, Einschränkungen im system prompt zu definieren?
A: Nein. Der Prompt ist als Intention hilfreich, aber keine Erzwingung. Kritische Grenzen müssen in der Runtime-Schicht geprüft werden.

Q: Wo anfangen, wenn Leitplanken fast fehlen?
A: Startet mit deny-by-default, route-basierter Allowlist, Scope-Enforcement (tenant/env) und explizitem stop_reason bei Policy-Ablehnungen.

Q: Machen Leitplanken das System zu langsam?
A: Leitplanken erzeugen etwas Overhead. In Production ist dieser Preis aber fast immer niedriger als Fehlaktionen, Budget-Verlust und manuelle Incident-Nacharbeit.

Was als Nächstes

Ähnliche anti-patterns:

• Write Access by Default - wenn write-Zugriff ohne ausreichende Grenzen offen ist.
• Blind Tool Trust - wenn Entscheidungen auf ungeprüftem Tool-Output basieren.
• No Stop Conditions - wenn die Agenten-Schleife keine kontrollierte Beendigung hat.

Was ihr stattdessen bauen solltet:

• Allowed Actions - wie Agenten-Aktionen über explizite Regeln begrenzt werden.
• Tool Execution Layer - wo Policy, Scope und Execution-Kontrolle zentralisiert werden.
• Stop Conditions - wie ein Run transparent endet, wenn Grenzen verletzt werden.