Policy Boundaries in Architecture: Was Agenten tun dürfen

Idee in 30 Sekunden

Die Policy-Boundaries-Schicht ist die Systemgrenze, die festlegt, was ein Agent tun darf und was nicht.

Der Agent kann Aktionen vorschlagen, aber die finale Entscheidung liegt immer beim System: allow, deny oder require_approval.

Wann noetig: wenn der Agent Zugriff auf Tools, Daten oder Operationen hat, die Zustand aendern, Budget verbrauchen oder Risiko erzeugen koennen.

Das LLM darf side effects (Zustandsaenderungen) nicht selbst steuern. Die Policy-Boundaries-Schicht erzwingt das auf Architektur-Ebene.

Problem

Ohne klare Policy Boundaries beginnt ein Agent "zu frei" zu handeln.

Das erzeugt typische Risiken:

• der Agent fuehrt eine Aktion ohne noetige Rechte aus;
• liest oder uebertraegt sensible Daten;
• der Agent ueberschreitet Budget, Quoten oder erlaubte Schrittzahl;
• startet irreversible Operationen ohne Freigabe;
• unterschiedliche Services wenden unterschiedliche Regeln an, und Verhalten wird unvorhersehbar.

Als Ergebnis steigen Incident-Risiken, Audits werden schwieriger und Fehler werden teurer.

Loesung

Fuege Policy Boundaries als separate Governance-Schicht im System hinzu: sie prueft jede riskante Aktion vor der Ausfuehrung.

Diese Schicht arbeitet nach "deny by default": erlaubt ist nur, was explizit in der Allowlist steht und zum Kontext passt.

Analogie: wie ein Zugangssystem in einem Buerozentrum.

Eine Person moechte vielleicht in den Serverraum, aber die Tuer geht nur mit richtigem Zugriffslevel auf.

Die Policy-Boundaries-Schicht prueft genauso den Zugriff auf Aktionen und Ressourcen vor der Ausfuehrung.

Wie Policy Boundaries funktionieren

Policy Boundaries ist eine Governance-Schicht zwischen Agent Runtime und Ausfuehrungs-/Daten-Layern, die entscheidet: Aktion zulassen, blockieren oder zur Freigabe senden.

Dieser Zyklus gilt fuer jede riskante Aktion und liefert vorhersagbares Verhalten, selbst bei Modellfehlern.

Im Code sieht das so aus

class PolicyBoundaryLayer:
    def __init__(self, policy_engine, approval_queue):
        self.policy_engine = policy_engine
        self.approval_queue = approval_queue

    def authorize(self, action, context):
        request = {
            "actor_role": context["role"],
            "tenant_id": context["tenant_id"],
            "action": action["name"],
            "resource": action.get("resource"),
            "risk_level": action.get("risk_level", "medium"),
        }

        decision = self.policy_engine.evaluate(request)
        mode = decision.get("mode")

        if mode == "allow":
            return {"ok": True, "mode": "allow", "scopes": decision.get("scopes", [])}

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(request=request, reason=decision["reason_code"])
            return {"ok": False, "mode": "pending_approval", "ticket_id": ticket_id}

        # Fail-closed for deny and for unexpected/unavailable policy modes.
        return {
            "ok": False,
            "mode": "deny",
            "reason_code": decision.get("reason_code", "policy_unavailable_or_invalid"),
        }

Wie es zur Laufzeit aussieht

Anfrage: "Loesche Rechnung INV-991 und sende Kundendaten an ein externes CRM"

Step 1
Agent Runtime: bildet action -> delete_invoice + export_customer_data
Runtime: sendet Aktionen an Policy Boundaries

Step 2
Policy Boundaries: Check -> Rolle support_agent, Risiko high
Policy Engine: delete_invoice -> require_approval
Policy Engine: export_customer_data -> deny (reason_code: cross_system_export_blocked)

Step 3
Runtime: erstellt approval ticket fuer Loeschung
Runtime: blockiert Export und gibt eine sichere Antwort mit Grund zurueck

Die Policy-Boundaries-Schicht "raet" nicht nur, sie stoppt gefaehrliche Aktionen wirklich.

Wann es passt - und wann nicht

Die Policy-Boundaries-Schicht wird dort gebraucht, wo reale Risiken bei Zugriff, Zustandsaenderung oder Kosten bestehen. Fuer einen lokalen Read-only-Prototyp kann das unnoetige Komplexitaet sein.

Passt

Passt nicht

In solchen Faellen reicht manchmal ein einfacher Check im Code:

if role != "admin":
    raise PermissionError("denied")

Typische Probleme und Ausfaelle

Die meisten dieser Probleme werden durch einen einzigen Policy-Kontrollpunkt, einen Fail-closed-Ansatz und qualitatives Audit geloest.

Wie es mit anderen Patterns zusammenspielt

Die Policy-Boundaries-Schicht ersetzt nicht Agent Runtime oder Tool Execution Layer. Sie ist eine systemweite Zugriffskontroll-Schicht ueber ihnen.

• Agent Runtime - Runtime steuert Schritte, waehrend die Policy-Boundaries-Schicht prueft, welche Aktionen in diesen Schritten erlaubt sind.
• Tool Execution Layer - execution layer fuehrt Aktion aus, waehrend die Policy-Boundaries-Schicht entscheidet, ob sie gestartet werden darf.
• Human-in-the-Loop Architecture - riskante Aktionen koennen in require_approval ueberfuehrt werden.
• Multi-Tenant - die Policy-Boundaries-Schicht erzwingt Zugriffsisolation zwischen Tenants.

Anders gesagt:

• Agent Runtime definiert wann der Agent einen Schritt macht
• Die Policy-Boundaries-Schicht definiert welche Aktionen in diesem Schritt ueberhaupt erlaubt sind

Unterschied zu Guarded-Policy Agent

Guarded-Policy Agent macht das Agentenverhalten vorsichtiger.

Die Policy-Boundaries-Schicht haelt die Aktionsausfuehrung kontrolliert, selbst wenn sich der Agent irrt.

Kurz

FAQ

Q: Wenn es Guarded-Policy Agent gibt, braucht man Policy Boundaries trotzdem?
A: Ja. Guarded-Policy Agent verbessert Verhalten, aber die Policy-Boundaries-Schicht erzwingt Regeln auf Systemebene.

Q: Wo sollten policy rules am besten gespeichert werden?
A: Meist in einer separaten policy engine oder einer policy-as-code-Layer mit Versionen und Tests.

Q: Was tun, wenn policy engine nicht verfuegbar ist?
A: Fuer riskante write-Operationen gilt fail-closed: Ausfuehrung verbieten, solange Pruefung nicht verfuegbar ist.

Q: Koennen Policy Boundaries von der Umgebung (dev, staging, prod) abhaengen?
A: Ja. Dieselben Aktionen haben oft unterschiedliche policy rules je nach Umgebung, Risikolevel und Datentyp.

Was als Naechstes

Policy Boundaries setzen die Spielregeln. Als Naechstes ist es sinnvoll zu sehen, wo diese Regeln im System durchgesetzt werden:

• Tool Execution Layer - wie policy bei echten Tool-Aufrufen angewendet wird.
• Human-in-the-Loop Architecture - wie Freigabe fuer kritische Aktionen gestaltet wird.
• Agent Runtime - wie runtime die Schleife anhand von Regeln stoppt oder fortsetzt.
• Production Stack - wie policy Teil der operativen Disziplin wird.