Die Agent Control Plane: Regeln, nicht Wahrscheinlichkeiten – wie Sie KI-Agenten deterministisch steuern

🔗 Serie: Autonomous but Accountable – Teil 4: SouverĂ€nitĂ€t und LokalitĂ€t ← aktuell: Teil 5 (Serienfinale)

Die Policy Engine, die bestimmt, was ein KI-Agent tun darf, muss vollstĂ€ndig vom Sprachmodell entkoppelt sein. Willkommen in der Agent Control Plane – einer deterministischen Architektur, die Tool-Calls abfĂ€ngt, gegen harte Regeln prĂŒft und nur genehmigte Aktionen ausfĂŒhrt.

In den vorherigen Teilen dieser Serie haben wir die Grundlagen gelegt: Action Safety (Teil 1), Blast Radius & HITL (Teil 2), Traceability by Design (Teil 3) und souverĂ€ne Infrastruktur (Teil 4). Nun kommen alle Puzzleteile zusammen – in der Agent Control Plane.

Das grundlegende Prinzip: Das LLM darf niemals direkt auf Tools, APIs oder Datenbanken zugreifen. Jeder Tool-Call des Agenten wird von der Control Plane abgefangen, gegen eine deterministische Policy Engine validiert und nur dann ausgefĂŒhrt, wenn alle Regeln erfĂŒllt sind.

Die Agent Control Plane besteht aus fĂŒnf Schichten, die unabhĂ€ngig voneinander operieren:

Schicht 1: Interceptor Layer

Die erste Schicht fĂ€ngt jeden Tool-Call des LLMs ab, bevor er an die Ziel-API gesendet wird. Der Interceptor ist ein Proxy, der zwischen dem LLM und der Außenwelt sitzt. Er analysiert den Tool-Call auf Struktur, Parameter und Intent.

Schicht 2: Policy Engine

Die Policy Engine ist das HerzstĂŒck der Control Plane. Sie enthĂ€lt eine Sammlung von hartcodierten, deterministischen Regeln, die unabhĂ€ngig vom LLM definiert und durchgesetzt werden. Jede Regel prĂŒft einen Tool-Call auf spezifische Bedingungen:

{
  "policies": [
    {
      "id": "POL-001",
      "name": "E-Mail nur an genehmigte Domains",
      "description": "Verhindert das Senden von E-Mails an externe, nicht genehmigte Domains",
      "trigger": "tool_call.email_send",
      "conditions": {
        "field": "recipient_domain",
        "operator": "in",
        "value": ["meinunternehmen.de", "partner.de"]
      },
      "action": "allow"
    },
    {
      "id": "POL-002",
      "name": "Datenbank-Schreibzugriff blockieren",
      "description": "Nur Lesezugriff auf die Kundendatenbank ist erlaubt",
      "trigger": "tool_call.database_write",
      "conditions": {
        "field": "database_name",
        "operator": "in",
        "value": ["kunden_db", "produkte_db"]
      },
      "action": "block"
    },
    {
      "id": "POL-003",
      "name": "Stornierung erfordert HITL",
      "description": "Jede Stornierung einer Bestellung muss von einem Menschen freigegeben werden",
      "trigger": "tool_call.order_cancel",
      "action": "require_hitl"
    }
  ]
}

Jede Policy hat einen klaren Trigger (welcher Tool-Call wird geprĂŒft), Conditions (unter welchen Bedingungen greift die Regel) und eine Action (allow, block, require_hitl).

Schicht 3: HITL Orchestrator

Wenn die Policy Engine einen Tool-Call als „require_hitl“ markiert, wird der HITL Orchestrator aktiv. Er pausiert die Agent-AusfĂŒhrung, benachrichtigt einen menschlichen Operator und wartet auf dessen Entscheidung (wie in Teil 2 beschrieben).

Schicht 4: Audit Recorder

Jeder Schritt – vom ursprĂŒnglichen LLM-Reasoning bis zum finalen Tool-Result – wird in der Audit Control Plane aufgezeichnet (wie in Teil 3 beschrieben). Die Decision Lineage ist lĂŒckenlos und kryptografisch gesichert.

Schicht 5: Execution Layer

Erst wenn alle PrĂŒfungen bestanden sind, wird der Tool-Call an die Ziel-API gesendet. Das Ergebnis wird zurĂŒck an das LLM gegeben, das seine Antwort an den Nutzer formuliert.

So lÀuft ein vollstÀndiger Agent-Durchlauf durch die Control Plane:

  1. User Input: Der Kunde gibt eine Anfrage ein
  2. LLM Reasoning: Das LLM analysiert die Anfrage und entscheidet, einen Tool-Call auszufĂŒhren
  3. Interceptor: Der Tool-Call wird vom Interceptor abgefangen – er erreicht die Ziel-API nicht
  4. Policy Engine: Der Tool-Call wird gegen alle Policies geprĂŒft. Ergebnis: „allow“, „block“ oder „require_hitl“
  5. HITL (falls nötig): Ein menschlicher Operator gibt die Aktion frei
  6. Audit: Der gesamte Vorgang wird aufgezeichnet
  7. Execution: Der Tool-Call wird ausgefĂŒhrt, das Ergebnis an das LLM zurĂŒckgegeben
  8. Response: Das LLM formuliert die Antwort an den Nutzer

Der entscheidende Punkt: Schritte 4–7 sind deterministisch und vollstĂ€ndig vom LLM entkoppelt. Selbst wenn das LLM einen bösartigen oder halluzinierten Tool-Call generiert, wird dieser von der Policy Engine gestoppt.

Viele aktuelle Agent-Frameworks integrieren die Policy-Definition in das LLM selbst – als Teil des System Prompts. Das ist ein grundlegender Architekturfehler mit gravierenden Konsequenzen:

  • Keine Durchsetzbarkeit: Ein Prompt ist eine Bitte, kein Befehl. Ein deterministischer Policy-Code ist ein Befehl.
  • Keine Audit-FĂ€higkeit: Wenn die Policy im LLM-Output versteckt ist, lĂ€sst sich nicht nachvollziehen, ob sie angewendet wurde.
  • Keine UnabhĂ€ngigkeit: Wenn das LLM die Policy definiert, kann es sie auch umgehen.

Die Agent Control Plane löst all diese Probleme, indem sie die Policy Engine physisch und logisch vom LLM trennt.

Der Aufbau einer vollstĂ€ndigen Agent Control Plane erfordert tiefgehendes VerstĂ€ndnis der Agenten-Architektur, der Sicherheitsmechanismen und der EU-Regulatorik. Die Experten von Cybereiche haben umfangreiche Erfahrung in der Entwicklung solcher Systeme fĂŒr europĂ€ische Enterprise-Kunden.

Ob der Aufbau einer deterministischen Policy Engine, die Integration einer Agent Control Plane in bestehende Systeme, die Entwicklung von HITL-Mechanismen fĂŒr KI-Chatbot-Lösungen, die Einbindung von RAG-Pipelines mit deterministischer Steuerung oder die Absicherung der gesamten Architektur durch Vulnerability Assessments – Cybereiche liefert die passende Lösung fĂŒr jedes Anforderungsprofil.

Diese 5-teilige Serie hat den Weg von den Grundlagen der Action Safety bis zur vollstÀndigen Agent Control Plane aufgezeigt. Die Kernbotschaft: Autonomie muss durch deterministische Kontrollmechanismen begrenzt werden.

Die Bausteine einer verantwortungsvollen Agent-Governance-Architektur im Überblick:

  1. Action Safety statt Output Safety – Deterministische Guardrails als Schutzschalter (Teil 1)
  2. Blast Radius & HITL – GDPR-konforme Begrenzung der Agenten-Autonomie (Teil 2)
  3. Traceability by Design – LĂŒckenlose Audit Control Plane fĂŒr EU AI Act (Teil 3)
  4. SouverĂ€ne Infrastruktur – Lokalisierte Systeme mit vollstĂ€ndiger Datenhoheit (Teil 4)
  5. Agent Control Plane – Deterministische Policy Engine entkoppelt vom LLM (Teil 5)

Autonomous but Accountable – das ist der Standard fĂŒr KI-Agenten in Europa.

Möchten auch Sie Ihre KI-Agenten mit einer deterministischen Control Plane absichern? Die Experten von Cybereiche beraten Sie gerne – von der Architektur-Analyse bis zur produktiven Implementierung. Vereinbaren Sie ein unverbindliches GesprĂ€ch und erfahren Sie, wie Sie Ihre Agenten sicher, compliant und souverĂ€n betreiben.