Planungs- und Ausführungsagenten für sicherere Produktionsänderungen

Ein Planungsagent sollte seine eigene Empfehlung nicht in eine Produktionsänderung umsetzen können. Gib ihm Raum, um zu prüfen, zu vergleichen und zu argumentieren. Gib einem separaten Ausführungsagenten eine kleine Zahl von Aktionsrechten und lass ihn anschließend nachweisen, dass die angeforderte Aktion zu einer genehmigten Änderung passt.

Diese Trennung klingt bürokratisch, bis man erlebt, wie ein Agent eine plausible, aber falsche Annahme über eine API-Grenze hinweg mitnimmt. Die meisten Fehler sind keine spektakulären Angriffe. Ein Agent liest ein veraltetes Runbook, verwechselt einen Staging-Hostnamen mit der Produktion oder folgt nicht vertrauenswürdigem Text in einem Issue. Hält derselbe Prozess sowohl die Zugangsdaten als auch die Berechtigung zum Handeln, wird aus dem Fehler eine Änderung, bevor ihn jemand bemerkt.

Ein Plan ist ein Beleg, keine Autorisierung

Planungs- und Ausführungsagenten brauchen unterschiedliche Befugnisse, weil ein Plan eine Aussage über die Welt hervorbringt, während die Ausführung die Welt verändert. Ein guter Plan kann trotzdem auf veralteten Daten, unvollständigem Repository-Kontext oder Anweisungen aus einer nicht vertrauenswürdigen Quelle beruhen. Wer einen Plan als Erlaubnis behandelt, legt zwei Entscheidungen zusammen, die getrennt geprüft werden sollten.

Ein Planer sollte Fakten sammeln, Unsicherheiten erklären, Alternativen vorschlagen und eine begrenzte Anfrage erstellen. Er sollte kein Produktions-Token besitzen, nur weil er in einem Bericht einen Endpunkt erwähnen muss. Wenn er Fakten aus einem geschützten System braucht, stelle eine eigens dafür entwickelte Leseoperation bereit, die nur die benötigten Fakten zurückgibt, oder lass einen Menschen die relevanten Ergebnisse bereitstellen.

Ein Executor hat eine andere Aufgabe. Er erhält eine konkrete Anfrage und entscheidet, ob sie in seinen begrenzten Zuständigkeitsbereich fällt. Er beginnt die Design-Diskussion nicht von vorn, durchsucht keine beliebigen Tickets und akzeptiert keinen Satz wie „Behebe die Bereitstellung“. Für ein Gespräch kann dieser Satz ausreichen. Als Vertrag für einen Prozess mit Zugangsdaten ist er wertlos.

Diese Unterscheidung korrigiert auch eine Gewohnheit, die Teams „Human in the Loop“ nennen, obwohl damit gemeint ist, dass jemand kurz über einen langen Chatverlauf geschaut hat. Ein Prüfer kann aus Fließtext nicht zuverlässig rekonstruieren, welche Tool-Aufrufe ein Agent ausführen könnte. Er kann eine kurze, strukturierte Anfrage prüfen, die Ziel, Vorgang, Eingaben, erwartete Wirkung und Rücknahmepfad nennt.

NIST SP 800-53, Control AC-5, fordert die Trennung von Aufgaben, um die Wahrscheinlichkeit zu verringern, dass eine Person ein System unbemerkt missbrauchen kann. Der Wortlaut bezieht sich auf Menschen, die Begründung lässt sich aber direkt auf Agenten übertragen. Kopiere keine alte Genehmigungshierarchie in einen Prompt. Trenne die Fähigkeiten in den tatsächlichen Zugangsdaten und Tool-Schnittstellen.

Der Executor muss enger begrenzt sein als der Plan

Der Executor sollte weniger Freiraum haben als der Planer, nicht bloß einen anderen Prompt. Ein separater Agent, der mit weitreichenden Cloud-Zugangsdaten beliebige Shell-Befehle ausführen kann, senkt das Risiko nicht entscheidend. Er kann eine vage Anfrage weiterhin neu interpretieren, andere Ressourcen entdecken und unabhängige Änderungen vornehmen.

Beginne mit einem Aktionskatalog. Jede Aktion sollte einen einzelnen Vorgang benennen und eine kleine Zahl von Parametern akzeptieren. deploy_service_revision kann zum Beispiel einen Servicenamen, eine unveränderliche Revisionskennung und eine Zielumgebung akzeptieren. Ein Shell-Fragment oder eine beliebige URL sollte es nicht akzeptieren.

Die wirksamste Einschränkung ist oft semantischer statt technischer Natur. Ein Zugangsschlüssel kann Bereitstellungen erlauben, aber ein Executor-Wrapper kann trotzdem ein veränderliches Tag wie latest ablehnen, die Produktion ohne Änderungs-ID zurückweisen und einen Dienst außerhalb seiner Allowlist blockieren. So werden Annahmen, die sonst in einem Runbook stehen, zu Code, der eine unsichere Anfrage ablehnen kann.

Verwechsle ein eingeschränktes Tool nicht mit einem eingeschränkten Ergebnis. Ein API-Token, das billing-api aktualisieren kann, kann möglicherweise auch die Traffic-Verteilung, Umgebungsvariablen und Autoscaling-Einstellungen ändern. Trenne diese Vorgänge, wenn die API das erlaubt. Wenn sie es nicht tut, setze ein kleines Gateway davor, das nur den Vorgang akzeptiert, den du automatisieren möchtest.

Ein glaubwürdiger Executor hat normalerweise diese Grenzen:

• Er verwendet für jede Umgebung eine eigene Identität.
• Er erhält nur benannte Aktionen und keine allgemeine Shell.
• Er validiert Zielnamen und unveränderliche Eingaben, bevor er einen Anbieter aufruft.
• Seine Lebensdauer ist kurz, und er kann keine umfassenderen Zugangsdaten erstellen.
• Er schreibt eine dauerhafte Aufzeichnung von Anfrage und Ergebnis.

Viele Teams sträuben sich dagegen, weil generische Tools schneller eingerichtet sind. Für die erste Demo sind sie tatsächlich schneller. Ein weitreichendes run_command-Tool wird teuer, sobald jemand erklären muss, warum ein Agent die falsche Ressource gelöscht hat, nachdem er einen kopierten Befehl in einem Ticket gelesen hatte.

Eine Übergabe braucht eine maschinenprüfbare Änderungsanfrage

Der Planer sollte ein strukturiertes Artefakt übergeben, das der Executor validieren kann, ohne Absichten interpretieren zu müssen. Freiformpläne verleiten den Executor dazu, Lücken mit eigener Schlussfolgerung zu füllen. Damit gelangt die Planungshoheit wieder in den Aktionspfad.

Eine praktische Anfrage kann so aussehen:

{
  "request_id": "chg-2025-0417-redis-timeout",
  "environment": "production",
  "action": "deploy_service_revision",
  "target": {
    "service": "checkout-api",
    "revision": "sha256:8f31c2..."
  },
  "expected_effect": "Run the approved checkout-api revision",
  "rollback": {
    "action": "deploy_service_revision",
    "revision": "sha256:31aa09..."
  },
  "approval": {
    "approved_by": "release-manager",
    "approved_request_hash": "b2c4..."
  }
}

Der Hash ist wichtig. Ohne ihn könnte ein Prüfer die Anfrage genehmigen, die er gesehen hat, während der Executor eine veränderte Version erhält. Der Genehmigungseintrag sollte an eine kanonische Darstellung genau der Felder gebunden sein, die der Executor verwendet. Wenn dein System JSON an verschiedenen Stellen unterschiedlich serialisiert, definiere zuerst die Kanonisierung. Ein beiläufiger String-Hash ist problematisch, wenn sich die Reihenfolge von Feldern oder ausgelassene Standardwerte auf die Nutzlast auswirken können.

Der Executor sollte die Anfrage mit klarer Begründung ablehnen. Eine nützliche Antwortstruktur zeigt die fehlgeschlagene Prüfung, ohne ein Geheimnis offenzulegen:

{
  "status": "denied",
  "request_id": "chg-2025-0417-redis-timeout",
  "reason": "revision must be an immutable digest",
  "executed": false
}

Diese Ablehnung gehört zum Design und ist kein peinlicher Sonderfall. Teams testen, ob Agenten Aktionen ausführen können, und überspringen Tests, die beweisen würden, dass sie ihren Zuständigkeitsbereich nicht überschreiten können. Teste beide Wege.

Lass den Planer die Aktionsdefinition des Executors nicht auswählen. Der Plattformverantwortliche sollte den Katalog, seine Validierungsregeln und die Zuordnung zu Zugangsdaten festlegen. Der Planer wählt aus den unterstützten Aktionen. Er kann nicht deploy_anything erfinden, nur weil eine bestimmte Aufgabe dringend wirkt.

Getrennte Prozesse verhindern das Teilen von Befugnissen

Zwei Agentenrollen in einem Prozess lassen sich weiterhin leicht vermischen. Gemeinsame Umgebungsvariablen, Token-Caches, Arbeitsverzeichnisse und Tool-Registrierungen schaffen unbeabsichtigte Wege um die geplante Grenze herum. Führe Planer und Executor als getrennte Prozesse mit unterschiedlichen Startkonfigurationen aus.

Der Prozess des Planers sollte Recherchewerkzeuge und möglicherweise eng gefilterte Leseschnittstellen erhalten. Executor-Zugangsdaten sollten in seiner Umgebung, seinen Konfigurationsdateien oder Tool-Beschreibungen nicht sichtbar sein. Ein Modell braucht keinen Klartextzugriff auf ein Token, um es missbrauchen zu können. Wenn der Prozess ein Tool aufrufen kann, das dieses Token besitzt, ist die Tool-Grenze die relevante Berechtigungsgrenze.

Der Executor sollte die genehmigte strukturierte Anfrage und den kleinstmöglichen Tool-Bestand erhalten. Er sollte weder den ursprünglichen Tickettext noch beliebige Webinhalte, ein Repository-weites Suchwerkzeug oder den Gesprächsverlauf des Planers erhalten. Diese Materialien können Prompt-Injection, fehlerhafte Befehle oder beiläufige Anweisungen enthalten, denen der Executor keinen Grund hat zu folgen.

Daraus ergibt sich eine einfache Debugging-Regel: Wenn ein Executor mehr Kontext benötigt, um über den auszuführenden Vorgang zu entscheiden, ist das Übergabeartefakt unvollständig. Löse das nicht durch umfassenden Discovery-Zugriff. Ergänze das fehlende Feld, die Validierungsregel oder die menschliche Entscheidung in der Anfrage.

Die Prozess-Trennung hilft auch bei der Reaktion auf Vorfälle. Du kannst die Executor-Sitzung widerrufen, ohne die Rechercheaufzeichnungen des Planers zu verlieren. Du kannst prüfen, ob der Planer ein anderes Ziel vorgeschlagen hat als das genehmigte. Wenn beide Rollen eine Sitzung und eine Identität teilen, wird diese Rekonstruktion zum Ratespiel.

Sallyport passt zu dieser Grenze, wenn ein MCP-fähiger Agent HTTP- oder SSH-Aktionen benötigt, ohne die zugrunde liegenden API- oder SSH-Zugangsdaten zu erhalten. Die App bewahrt diese Geheimnisse in ihrem verschlüsselten Tresor auf und führt den Aufruf selbst aus. So kann ein Planer keine Zugangsdaten extrahieren, selbst wenn seine Anweisungen manipuliert wurden.

Die Genehmigung gehört an den Punkt, an dem sich die Folgen ändern

Eine menschliche Genehmigung sollte eine bestimmte Entscheidung abdecken und keinen vagen Freibrief für alles darstellen, was ein Agent danach tut. Eine Sitzungsgenehmigung ist sinnvoll, um festzulegen, dass ein bekannter Agentenprozess während eines Laufs eine begrenzte Zahl risikoarmer Aktionen verwenden darf. Sie ersetzt keine Prüfung, wenn die Aktion Produktionsdaten, Identitäten, die Netzfreigabe oder Geld verändern kann.

Eine Genehmigung pro Aufruf gehört zu Zugangsdaten, deren Verwendung erhebliche Folgen hat. Der zusätzliche Klick ist gerechtfertigt, wenn der Aufruf irreversibel, ungewöhnlich oder nur mit hohem Aufwand rückgängig zu machen ist. Setze ihn bei einem Schlüssel zum Löschen in der Produktion, bei Zugangsdaten für Änderungen an der Zugriffskontrolle oder bei einer Zahlungsaktion ein. Harmlosen Statusabfragen solltest du ihn nicht vorschalten. Eine ständig erscheinende Abfrage wird zum Hintergrundrauschen, und Menschen bestätigen sie, ohne zu lesen.

Zeige in Genehmigungen, was ein Prüfer tatsächlich beurteilen kann: Aktionsname, Zielumgebung, Zielressource, unveränderliche Eingabe und geplanten Rollback. Ein Dialog mit der Aussage „Agent fordert Zugriff an“ ist Theater. Er sagt dem Prüfer nichts über die Folgen.

Der Umfang einer Genehmigung muss ablaufen. Eine an einen Prozesslauf gebundene Genehmigung sollte enden, wenn der Prozess beendet wird. Eine an eine Änderungsanfrage gebundene Genehmigung sollte an deren Inhalt gekoppelt sein und eine spätere Version nicht stillschweigend autorisieren. Langfristige Genehmigungen wirken attraktiv, weil sie Reibung beseitigen. Sie stellen aber genau die dauerhafte Berechtigung wieder her, die durch die Trennung vermieden werden sollte.

Sallyports Entscheidungskette passt gut zu diesem Modell: Die Tresorsperre verweigert jede Aktion, solange der Tresor geschlossen ist, die Sitzungsautorisierung identifiziert einen neuen Agentenprozess, und ausgewählte Schlüssel pro Aufruf können bei jeder Verwendung eine Bestätigung verlangen. Das ist bewusst enger als eine Policy-Engine. Teams müssen weiterhin entscheiden, welche Zugangsdaten eine Prüfung pro Aufruf verdienen.

Prompt-Injection erreicht Planer, bevor sie Executor erreicht

Prompt-Injection gelangt oft über die normale Arbeit des Planers hinein. Ein Repository-Kommentar fordert dazu auf, einen Befehl auszuführen. Ein Support-Ticket enthält eine gefälschte Anweisung zum Ausleiten von Konfiguration. Eine Webseite fordert den Agenten auf, frühere Anweisungen zu ignorieren. Planungsagenten sehen mehr nicht vertrauenswürdigen Text, als Executor jemals sehen sollten.

Die übliche schlechte Reaktion besteht darin, monatelang an einer perfekten Anweisung zu arbeiten, die dem Planer sagt, wie er sich nicht täuschen lässt. Das Modellverhalten kann sich verbessern, aber Textanweisungen ersetzen keine Befugnisgrenzen. Gehe davon aus, dass der Planer eine schädliche Anweisung in seinem Plan wiederholt. Lass den Executor anschließend jede Anfrage außerhalb seines Katalogs, seines Zuständigkeitsbereichs und seiner Genehmigungsbindung ablehnen.

Stell dir einen vertrauten Fehler vor. Ein Planer untersucht Latenz und liest eine alte Incident-Notiz, die empfiehlt, die Replikazahl eines Dienstes vor dem Abziehen des Traffics auf null zu setzen. Er erstellt einen Plan mit der falschen Umgebung, weil die Notiz einen kopierten Hostnamen verwendet hat. Wenn dieser Planer ein allgemeines Bereitstellungstool aufrufen kann, verwandelt er den veralteten Vorschlag womöglich in einen Ausfall.

Bei einer getrennten Architektur stoppt der Fehler an mehreren Stellen. Die Übergabeanfrage muss die Produktion ausdrücklich nennen. Der Executor akzeptiert nur eine Aktion zur Bereitstellung einer Revision und keine Änderung der Replikazahl. Der menschliche Prüfer sieht das tatsächliche Ziel und die gewünschte Wirkung. Das Executor-Log hält die Ablehnung fest, wenn die Anfrage nicht passt. Keine dieser Kontrollen verlangt, dass der Planer vergifteten oder veralteten Text perfekt erkennt.

Kennzeichne die Ausgabe des Planers als nicht vertrauenswürdige Eingabe für den Ausführungspfad. Diese Bezeichnung sollte die Datenverarbeitung beeinflussen und nicht nur als Warnung in einer Oberfläche erscheinen. Interpoliere keinen Planertext in Shell-Befehle. Lass ihn HTTP-Pfade, Header oder Query-Felder nicht ohne Typprüfungen und Allowlists befüllen. Ein JSON-Schema hilft, aber die Schema-Validierung allein sagt nicht, ob production ein autorisiertes Ziel ist.

Auch Lesezugriff kann einen Weg zu Schaden eröffnen

Teams geben Planern oft weitreichenden Lesezugriff, weil „er kann ja nichts ändern“. Dieser Satz hat schon viele vermeidbare Probleme verursacht. Lesezugriff kann Kundendaten, interne Hostnamen, Bereitstellungsverläufe, Feature-Flags, Zugriffsmuster und die Namen privilegierter Systeme offenlegen. Er kann außerdem genau die Informationen liefern, die ein Angreifer braucht, um eine überzeugende Aktionsanfrage zu formulieren.

Ordne Lesezugriffe nach ihrer Sensibilität und danach, was sie ermöglichen. Ein Health-Endpunkt mit dem Status eines Dienstes unterscheidet sich von einem Endpunkt zum Exportieren einer Datenbank. Ein Dienstinventar mit öffentlichen Namen unterscheidet sich von einer API für einen Zugangsdatenmanager, die geheime Kennungen und Metadaten zurückgibt. Lege beides nicht hinter dasselbe generische read_only-Tool.

Gib dem Planer nach Möglichkeit abgeleitete Fakten. Statt Zugriff auf jedes Bereitstellungsereignis anzubieten, stelle eine Operation bereit, die für einen benannten Dienst die aktuelle Revision, den Gesundheitszustand und die ID der letzten genehmigten Änderung zurückgibt. Statt weitreichender Datenbankabfragen biete eine Metrik an, die die diagnostische Frage beantwortet. So verringerst du sowohl die unbeabsichtigte Offenlegung als auch die Menge an Material, das schädliche Anweisungen enthalten kann.

Hier übertreiben Teams oft und machen nützliche Planung unmöglich. Die Lösung besteht nicht darin, den Agenten blind zu machen. Entscheide, welche Fakten die Aufgabe braucht, und erstelle eine Leseschnittstelle für genau diese Fakten. Wenn ein Planer regelmäßig ein zusätzliches Feld benötigt, ergänze es bewusst, nachdem du den Anwendungsfall geprüft hast. Löse nicht jede Lücke durch einen Produktionszugang.

Logs müssen die Rekonstruktion eines Widerspruchs ermöglichen

Ein Audit-Trail sollte mehr beantworten als „Hat ein API-Aufruf stattgefunden?“ Nach einer umstrittenen Änderung musst du das vom Planer vorgeschlagene Artefakt, das von einem Menschen genehmigte Artefakt, die validierte Anfrage des Executors, den exakten externen Aufruf und die Antwort vergleichen können. Fehlt einer dieser Punkte, bleibt eher eine Geschichte als ein Beleg.

Führe eine stabile Anfrage-ID durch den gesamten Ablauf. Der Planer vergibt oder erhält sie. Die Genehmigung wird an sie und ihren Inhalts-Hash gebunden. Der Executor schreibt sie zusammen mit seiner Prozessidentität und dem Ergebnis der Aktion. Das externe Gateway protokolliert sie zusammen mit dem ausgehenden Ziel und dem Antwortstatus. Protokolliere keine Bearer-Tokens, Passwörter, privaten Schlüssel oder vollständigen sensiblen Nutzdaten, nur damit die Zuordnung einfacher wird.

Manipulationsnachweise sind wichtig, weil normale Anwendungslogs oft in Speichern liegen, die Administratoren bearbeiten können. Eine hashverknüpfte Ereignisfolge macht spätere Änderungen erkennbar, wenn du den erwarteten Zustand der Kette aufbewahrst. Sie beweist nicht automatisch, dass jedes Ereignis wahr ist. Sie erschwert aber das unbemerkte Umschreiben der aufgezeichneten Geschichte. Genau das brauchst du, wenn Personen unter Prüfung zugleich Zugriff auf den Log-Speicher haben.

Sallyport erstellt seine Sessions- und Activity-Journale aus einem verschlüsselten, hashverketteten Audit-Log. sp audit verify prüft die Kette offline über den Chiffretext, ohne einen Tresorschlüssel zu benötigen. Das ist für eine Untersuchung hilfreich, weil die Prüfung nicht erfordert, dem Prüfer Aktionszugangsdaten zu geben.

Führe vor einem Vorfall eine Rekonstruktionsübung durch. Wähle eine genehmigte Änderung und bitte einen Kollegen, anhand der Aufzeichnungen fünf Fragen zu beantworten: Welcher Agent hat sie vorgeschlagen, wer hat die genaue Anfrage genehmigt, welcher Executor hat sie ausgeführt, welcher externe Vorgang hat stattgefunden und welches Ergebnis kam zurück? Wenn eine Antwort vom Gedächtnis oder einem Chatverlauf abhängt, verbessere die Aufzeichnungen.

Die erste automatisierte Aktion sollte langweilig und reversibel sein

Beginne die Trennung mit einer Aktion, die einen klaren Verantwortlichen, eine eng begrenzte Zielmenge und einen bereits geübten Rücknahmepfad hat. Eine Bereitstellung in einer Nichtproduktionsumgebung mit einer unveränderlichen Revision ist ein besserer erster Fall als das Ändern von Zugriffsregeln oder das Löschen veralteter Konten. Langweilige Arbeit gibt dir die Möglichkeit, Lücken im Design zu finden, ohne die Produktion auf eine Demo zu setzen.

Führe dieselbe Aufgabe wiederholt durch den Workflow, bis sich das Anfrageformat nicht mehr aus belanglosen Gründen ändert. Achte auf die vorhersehbaren Fehler: Planer lassen ein Ziel aus, Prüfer genehmigen eine allgemeine Beschreibung, Executor benötigen nicht deklarieren Kontext und Logs können Genehmigung und Aufruf nicht miteinander verbinden. Jeder Fehler zeigt, an welcher Stelle weiterhin Befugnisse zwischen den Rollen durchsickern.

Miss den Erfolg nicht daran, wie wenige Genehmigungsklicks übrig bleiben. Entscheidend ist, ob der Executor ein falsches Ziel, eine nicht genehmigte Revision und eine nicht unterstützte Aktion ablehnt und die beabsichtigte Aktion ausführt. Ein System, das jede Aktion einfach macht, ermöglicht wahrscheinlich zu viele Aktionen.

Wenn der Workflow zuverlässig funktioniert, erweitere jeweils eine Aktionsfamilie. Halte den Planer neugierig und den Executor langweilig. Produktionsautomatisierung verdient Vertrauen, wenn ihre Ablehnungen genauso bewusst erfolgen wie ihre Erfolge.