Guarded-Policy-Agent-Pattern: sichere Aktionen nach Richtlinie

Pattern-Kern

Guarded-Policy Agent ist ein Pattern, bei dem vor jeder Aktion ein policy-gate angewendet wird: allow, deny, rewrite oder escalate nach formalisierten Regeln.

Wann einsetzen: wenn Agent-Aktionen vor der Ausfuhrung formale Regelprufungen bestehen mussen.

Die Idee ist einfach: Der Agent darf alles vorschlagen, aber ausgefuhrt werden nur Schritte, die die Policy-Prufung bestehen.

Policy-Leitplanken prufen typischerweise:

• erlaubte Tools und Parameter
• Grenzen des Datenzugriffs
• budget/time Limits
• Risikoniveau der Aktion

Problem

Stell dir ein Banking-Szenario vor: Es sollen 100$ uberwiesen werden, aber im Feld werden versehentlich 10,000$ eingetragen.

Wenn ein System ohne Prufungen einfach "ausfuhren" sagt, geht diese Aktion in Prod.

Selbst wenn:

• der Kunde dieses Guthaben nicht hat
• der Betrag das Rollenlimit uberschreitet
• das Zielkonto extern ist und zusatzliche Prufungen braucht

Ohne technisches Policy-Gate kann der Agent eine gefahrliche Aktion ausfuhren, obwohl sie offensichtlich nicht durchgehen darf.

Genau das ist das Problem: Ohne Grenzen kann jede Aktion ausgefuhrt werden, auch wenn sie:

• gefahrlich ist
• zu teuer ist
• Zugriffsregeln verletzt

Losung

Guarded-Policy Agent fuhrt verpflichtende Prufungen vor jeder Aktion ein.

Analogie: wie ein Drehkreuz mit Zugangskontrolle. Auch wenn eine Person durch will, werden zuerst Rechte und Regeln gepruft. Ohne Freigabe lasst das System die Aktion nicht weiter.

Kernprinzip: Das Modell darf jeden Schritt vorschlagen, aber ausgefuhrt werden nur Schritte, die das Policy-Gate passieren.

Jede Aktion durchlauft:

1. Berechtigungsprufung
2. Budget-/Limitprufung
3. Datenzugriffsprufung
4. Risikobewertung

Danach liefert policy-engine eine Entscheidung:

• erlauben (allow) - ausfuhren
• umschreiben (rewrite) - durch sichere Variante ersetzen
• verbieten (deny) - blockieren
• eskalieren (escalate) - an Menschen ubergeben

Das schutzt vor Fallen, in denen der Agent:

• schreibt statt liest
• sensible Daten exfiltriert
• eine teure Abfrage startet
• eine destruktive Operation ausfuhrt

Funktioniert gut, wenn:

• der Agent keinen direkten Zugriff auf Tools hat
• Ausfuhrung nur uber policy-engine moglich ist
• jede Aktion zwingend allow/deny/rewrite/escalate durchlauft

Agent-Zuverlassigkeit bedeutet nicht nur "gute Absicht", sondern Aktionen, die technisch nicht ausserhalb der Regeln ausgefuhrt werden konnen.

Wie Es Funktioniert

Policy-gate fuhrt die Aktion nicht selbst aus. Es entscheidet, ob sie ausgefuhrt werden darf und in welcher Form.

Im Code Sieht Das So Aus

action = agent.next_action(context)

decision = policy_engine.evaluate(
    action=action,
    user_role=user_role,
    budget_state=budget_state,
)

if decision.type == "allow":
    result = execute(action)
elif decision.type == "rewrite":
    context.append(decision.reason)
    return agent.next_action(context)  # erneut vorschlagen durch dasselbe gate
elif decision.type == "escalate":
    result = human_approval(action)
else:
    result = stop_with_reason(decision.reason)

return result

Kernprinzip: Agent Intent und Ausfuhrung sind verschiedene Schichten. Policy steht zwischen intent und Ausfuhrung (execution).

Das Modell hat keinen direkten Weg zur Ausfuhrung, nur uber eine policy-gated Ausfuhrungsschicht (execution layer).

So Sieht Es Zur Laufzeit Aus

Goal: "Exportiere alle Kunden in CSV und sende an externe E-Mail"

Agent action:
- tool: export_customers
- params: include_pii=true
- destination: external_email

Policy check:
- rule: PII export to external channels = deny
- decision: blockieren (block)
- reason: policy.pii_exfiltration_guard

Result:
- Aktion wurde nicht ausgefuhrt
- kontrollierte Ablehnung wurde zuruckgegeben

Wann Es Passt - Und Wann Nicht

Passt

Passt Nicht

Denn die Policy-Schicht erhoht die Engineering-Komplexitat: Regeln, Regeltests und laufende Updates fur Business-Prozesse.

Unterschied Zu Supervisor Agent

Guarded-Policy ist eine technische Barriere "nach Regeln".

Supervisor Agent ist aufsichtliche Kontrolle "nach Situation".

Wann Guarded-Policy Verwenden (vs Andere Patterns)

Verwende Guarded-Policy, wenn riskante Aktionen vor der Ausfuhrung anhand klarer Policy-Regeln gestoppt werden mussen.

Kurzer Test:

• wenn du "allow/deny Check vor Aktion" brauchst -> Guarded-Policy
• wenn du "nach bereits aufgetretenem Fehler wiederherstellen" musst -> Fallback-Recovery Agent

Wie Mit Anderen Patterns Kombinieren

• Guarded-Policy + ReAct: jede Aktion im Loop geht erst durch policy-check und wird dann ausgefuhrt.
• Guarded-Policy + Supervisor: Supervisor bestimmt, wann Eskalation notig ist, und policy-engine setzt harte Regeln automatisch durch.
• Guarded-Policy + Fallback-Recovery: wenn Aktion verboten wird oder Schritt ausfallt, wechselt der Agent auf erlaubten und sicheren fallback.

Kurz

Vorteile Und Nachteile

FAQ

Q: Kann man Policy-Prufungen nur durch Prompt-Instruktionen ersetzen?
A: Nein. Prompt wirkt auf Intent-Ebene, kontrolliert aber nicht die Ausfuhrung. Policy muss in der Runtime-Schicht enforced werden.

Q: Was ist besser: allowlist oder blocklist?
A: Fur High-Risk-Systeme ist es sicherer, mit allowlist zu starten: erlaubt sind nur explizit definierte Aktionen.

Q: Was tun, wenn eine Regel zu strikt ist und nutzliche Aktion blockiert?
A: Gesteuerte Ausnahmen hinzufugen: scope, rollenbasierte Bedingungen oder Human-Approval-Pfad statt vollem deny.

Was Danach

Der Guarded-Policy-Ansatz schutzt den Agenten vor unsicheren Aktionen vor der Ausfuhrung.

Aber was tun, wenn der Agent sichere Code-Ausfuhrung in isolierter Umgebung braucht?