# Destruktive API-Parameter: Vor dem Löschen prüfen KI-Agenten führen destruktive API-Aufrufe zu leicht aus, wenn eine Anfrage syntaktisch korrekt aussieht. Ein gültiger JSON-Body, ein vertrauter Kontoname und eine erfolgreiche Suche beweisen noch nicht, dass der Agent gerade das richtige Objekt löschen wird. Bevor eine externe Anfrage Daten entfernt, Zugriffe widerruft, Verbindungen trennt, Vorgänge abbricht oder Daten überschreibt, solltest du Identität, Besitz, Umfang und Aktualität direkt beim Dienst prüfen. Ich habe erlebt, wie sorgfältige Entwickler eine Anfrage als «Lösche diese Testumgebung» verstanden, während die API sie als «Lösche alle Umgebungen dieser Organisation» interpretierte. Im engen Sinn enthielt der Code oft keinen Fehler. Er akzeptierte einen ungenauen Selektor, löste einen Namen aus dem falschen Konto auf oder vertraute auf Daten, die früher im Ablauf abgerufen worden waren. Ein autonomer Agent macht solche gewöhnlichen Fehler schneller und mit größerer Sicherheit. Das ist kein Fall dafür, das Modell einfach um mehr Vorsicht zu bitten. Setze ein deterministisches Gate zwischen die vom Agenten vorgeschlagene Anfrage und die Anfrage mit Zugangsdaten. Das Gate sollte Mehrdeutigkeiten standardmäßig ablehnen und einen Menschen das tatsächliche Ziel sowie die konkrete Auswirkung genehmigen lassen. ## Eine korrekt aufgebaute Anfrage kann trotzdem das falsche Objekt benennen Eine Anfrage ist erst sicher genug zum Absenden, wenn vier unabhängige Fakten feststehen: Die Ressource hat den richtigen Typ, ihre unveränderliche ID ist die beabsichtigte, sie gehört zum genehmigten übergeordneten Konto und der Vorgang betrifft genau den genehmigten Bestand. Teams vermischen diese Fakten häufig in einer einzigen Suche. Genau dort gehen Löschvorgänge schief. Stell dir einen Dienst vor, der sowohl einen Anzeigenamen als auch eine ID bereitstellt: ```json { "id": "env_7d3a", "name": "staging", "account_id": "acct_blue", "state": "active" } ``` Ein Agent, der nach `staging` sucht, hat einen Kandidaten gefunden, aber noch keine Berechtigung, ihn zu löschen. Viele Konten haben eine Umgebung namens `staging`. Selbst innerhalb eines Kontos können Namen wiederverwendet werden, nachdem ein altes Objekt verschwunden ist. Die einzig sichere Aktionsanfrage verwendet die zurückgegebene unveränderliche ID und prüft sie gegen die erwartete übergeordnete ID. Der Unterschied ist besonders wichtig, wenn eine API einen übergeordneten Pfad wie `/accounts/{account_id}/environments/{environment_id}` unterstützt. Prüfe beide Segmente. Leite den Besitz nicht daraus ab, dass die ID in einer früheren Suchantwort auftauchte oder der Agent denselben Kontonamen in seinen Plan geschrieben hat. Das übergeordnete Konto in der Aktions-URL gehört zur Autorisierungsgrenze. Der Ressourcentyp braucht eine eigene Prüfung. APIs verwenden häufig einen gemeinsamen Suchendpunkt oder geben gemischte Datensätze zurück. Ein Ergebnis namens `staging` kann eine Umgebung, ein Projekt, eine Zugriffsgruppe oder eine gespeicherte Vorlage sein. Wenn der Dienst unterschiedliche Löschendpunkte hat, wähle den Endpunkt erst, nachdem du den zurückgegebenen Typ geprüft hast. Baue keinen Endpunkt, indem du eine vom Modell erzeugte Typzeichenfolge zusammensetzt. Lege schließlich die erwartete Auswirkung fest, bevor du Kandidaten prüfst. «Die alte Bereitstellung entfernen» kann bedeuten, einen Bereitstellungsdatensatz zu löschen, einen laufenden Job zu stoppen, ein dafür ausgestelltes Token zu widerrufen oder die gesamte Umgebung zu löschen. Diese Auswirkungen dürfen nicht dieselbe allgemeine `delete`-Aktion verwenden. Mache das gewünschte Verb und den Objekttyp im Aktionsvertrag eindeutig. ## Namen helfen Menschen, IDs steuern die Anfrage Verwende eine unveränderliche ID, um eine Ressource anzusprechen. Zeige der genehmigenden Person aber genug verständlichen Kontext, damit sie eine falsche Auswahl erkennt. Eine Genehmigungskarte, auf der nur `env_7d3a` steht, lädt zum unkritischen Bestätigen ein. Eine Karte mit nur `staging` bleibt mehrdeutig. Zeige beides sowie das übergeordnete Konto und die Auswirkung des Vorgangs. Ein nützlicher Zieldatensatz sieht so aus: ```json { "operation": "delete_environment", "account": {"id": "acct_blue", "name": "Blue Team"}, "target": {"id": "env_7d3a", "name": "staging", "type": "environment"}, "expected_state": "active", "effect": "permanently removes this environment and its managed resources" } ``` Der Anzeigename des Kontos hilft dem Bediener zu erkennen, ob der Agent in den falschen Mandanten geraten ist. Der Ressourcenname erleichtert die Zuordnung. Die IDs machen die Anfrage eindeutig. Die beschriebene Auswirkung verhindert einen häufigen Genehmigungsfehler: Jemand glaubt, eine umkehrbare Stoppaktion genehmigt zu haben, während der Anbieter Daten entfernt. Löse einen Namen nie auf, indem du das erste Suchergebnis übernimmst. Suchendpunkte sortieren häufig nach Relevanz, liefern Teiltreffer oder verwenden Seiten. Wenn eine Aufgabe einen exakten Namen vorgibt, darf nach der Filterung durch übergeordnetes Konto und erwarteten Typ genau ein Kandidat übrig bleiben. Kein Kandidat muss zum Abbruch führen. Mehrere Kandidaten müssen ebenfalls zum Abbruch führen. Den Agenten auswählen zu lassen, löst das Problem nicht, weil ihm die Belege fehlen, die zwischen den Kandidaten unterscheiden. Auch die Behandlung von Groß- und Kleinschreibung braucht eine dienstspezifische Regel. Manche Anbieter unterscheiden die Schreibweise, andere normalisieren sie. Normalisiere Namen nicht selbst und gehe dann davon aus, dass der Anbieter genauso handelt. Verwende die vom Anbieter zurückgegebene Ressource als maßgebliche Quelle und übernimm die exakte Bezeichnung in den Genehmigungsdatensatz. Tags, Labels und Beschreibungen liefern Kontext, sind aber keine Identität. Sie ändern sich häufig und Nutzer können nahezu beliebige Inhalte eintragen. Ein Tag wie `temporary=true` kann eine geprüfte Liste eingrenzen. Er darf aber weder eine Kontobindung noch eine unveränderliche Ressourcen-ID ersetzen. ## Der Umfang muss konkret sein, bevor der Agent um Genehmigung bitten darf Ein destruktiver Vorgang hat auch dann einen Umfang, wenn sein Request-Body nur eine ID enthält. Dazu gehören das übergeordnete Konto, die ausgewählten Ressourcen, untergeordnete Ressourcen, die der Anbieter automatisch entfernt, und jeder Filter, der die Auswahl erweitert. Mache diesen Umfang konkret, bevor du jemanden um Genehmigung bittest. Das Löschen eines einzelnen Objekts hat einen einfachen Vertrag: eine unveränderliche ID, ein erwartetes übergeordnetes Konto und ein Ressourcentyp. Sammellöschungen brauchen einen anderen Vertrag. Zuerst muss die konkrete Menge ermittelt werden. Danach wird diese Menge oder eine begrenzte, für Menschen prüfbare Zusammenfassung genehmigt. Einen Selektor direkt an einen destruktiven Endpunkt zu senden bedeutet, dass der externe Dienst den Umfang erst nach der Genehmigung bestimmt. Angenommen, ein Agent schlägt diese Anfrage vor: ```json { "account_id": "acct_blue", "filter": {"label": "cleanup-candidate"}, "delete": true } ``` Dieser Body verbirgt die einzige Information, die der Bediener braucht: Welche Ressourcen treffen gerade zu? Löse den Filter über einen schreibgeschützten Listenaufruf auf, lehne Seiten ab, die du nicht vollständig geprüft hast, und normalisiere das Ergebnis zu IDs. Zeige dann die Anzahl und eine kurze Stichprobe mit Namen. Wenn die Menge das genehmigte Limit überschreitet, stoppe und verlange eine neue Anweisung. Ein fehlender Filter darf niemals «alle» bedeuten. Unterscheide in Request-Schemas zwischen einer erforderlichen leeren Liste und einem fehlenden Selektor. Noch besser: Verbiete es destruktiven Endpunkten, in der Aktionsschnittstelle des Agenten Filter anzunehmen. Das Gateway sollte für Sammelaktionen nur eine Liste bereits aufgelöster IDs akzeptieren. Eine praktische Form sieht so aus: ```json { "operation": "delete_resources", "account_id": "acct_blue", "resource_type": "snapshot", "resource_ids": ["snap_104", "snap_105"], "selection_observed_at": "2025-03-08T14:32:11Z" } ``` Lehne ein leeres Array `resource_ids` ab, sofern der Ablauf es nicht ausdrücklich erlaubt. Lehne doppelte IDs ab. Lehne IDs aus einem anderen Konto ab. Erzwinge eine maximale Anzahl, die zum genehmigten Vorgang passt. Ein Limit ersetzt keine Prüfung, verhindert aber, dass eine fehlerhafte Schleife aus einer Bereinigung von zwei Ressourcen einen Vorfall mit tausend Ressourcen macht. Kaskaden gehören ebenfalls zum Umfang. Wenn das Löschen eines Projekts Repositories, Bereitstellungsschlüssel, Umgebungen oder Abrechnungsdatensätze löscht, muss das vor der Genehmigung feststehen. Liefert der Anbieter Details zur Kaskade erst nach einem Preflight-Aufruf, bewahre diese Antwort auf und lasse sie dem Agenten anzeigen. «Projekt löschen» ist zu ungenau, wenn das Projekt abhängige Objekte hat. ## Lies den Dienst zweimal, wenn sich das Ziel verändern kann Eine Vorabprüfung bestätigt die Absicht, friert das Objekt aber nicht ein. Die Ressource kann sich zwischen Prüfung und Löschung ändern, das Konto wechseln oder verschwinden. Bei sensiblen Vorgängen solltest du das Ziel unmittelbar vor der Änderung erneut lesen und die vom Dienst angebotene Nebenläufigkeitskontrolle verwenden. HTTP bietet dafür einen standardisierten Mechanismus. RFC 9110 definiert bedingte Anfragen mit `If-Match`: Der Server führt die angeforderte Methode nur aus, wenn die aktuelle Darstellung mit einem vom Client übermittelten Entity-Tag übereinstimmt. Ein `GET` kann ein `ETag` zurückgeben, und ein anschließendes `DELETE` kann genau diesen Wert mitsenden. ```http GET /v1/accounts/acct_blue/environments/env_7d3a HTTP/1.1 Authorization: Bearer [injected credential] HTTP/1.1 200 OK ETag: "v42" Content-Type: application/json {"id":"env_7d3a","account_id":"acct_blue","name":"staging","state":"active"} ``` Nachdem du den Body mit dem genehmigten Ziel verglichen hast, sende: ```http DELETE /v1/accounts/acct_blue/environments/env_7d3a HTTP/1.1 If-Match: "v42" Authorization: Bearer [injected credential] ``` Gibt der Dienst `412 Precondition Failed` zurück, ist das ein erfolgreicher Schutzmechanismus. Bitte den Agenten nicht, die Löschung ohne Bedingung zu wiederholen. Lade die Ressource erneut, vergleiche sie mit den genehmigten Fakten und hole eine neue Genehmigung ein, wenn sich ein relevanter Fakt geändert hat. Ein Versionskonflikt zeigt, dass die alte Genehmigung möglicherweise nicht mehr gilt. Manche Dienste verwenden statt HTTP-ETags Revisionsnummern, Änderungszeitpunkte, Generationsfelder oder Anfrage-Token. Verwende den vom Anbieter dokumentierten Mechanismus. Bietet er keinen an, verkürze das Intervall zwischen dem letzten Lesen und dem Schreiben, führe die Aktion seriell aus und akzeptiere, dass du nicht beweisen kannst, dass das Ziel unverändert blieb. Diese Einschränkung sollte beeinflussen, ob du unbeaufsichtigte Löschungen zulässt. Verwechsle einen erfolgreichen `GET` nicht mit der Berechtigung, etwas zu verändern. Die Leseberechtigung kann mehr sehen, als die Schreibberechtigung ändern darf, und die Autorisierung kann sich unabhängig vom Objektstatus ändern. Die Antwort der Änderung entscheidet weiterhin, ob der Anbieter die Anfrage akzeptiert hat. ## Die Prüfung gehört an die Grenze zu den Zugangsdaten Eine Prüfung, die nur in einem Agenten-Prompt oder in erzeugtem Code stattfindet, ist eine Empfehlung. Die Komponente, die Zugangsdaten hält oder injiziert, muss die Kontrollen erzwingen, denn sie ist die letzte Stelle, an der ein ausgehender Aufruf verhindert werden kann. Diese Grenze sollte einen strukturierten Aktionsvorschlag erhalten, keine frei formulierte URL mit beliebigen Headern. Eine enge Aktionsdefinition kann Felder wie Konto-ID, Ressourcen-ID, Methode, erwarteten Typ und erwartete Version verlangen. Sie kann den ausgehenden Pfad aus geprüften Segmenten zusammensetzen und Query-Parameter ablehnen, die den Umfang erweitern. Akzeptiere keine vollständige URL vom Agenten, um danach Sicherheitsmerkmale daraus zu lesen. URL-Kodierung, wiederholte Query-Schlüssel, alternative Hostnamen und Pfadnormalisierung machen daraus einen Parserwettbewerb. Akzeptiere typisierte Felder, prüfe jedes gegen den Vertrag des Anbieters und baue die URL selbst. Dasselbe gilt für Request-Bodies. Erzeuge eine bekannte Body-Struktur, statt einen Blob durchzureichen, dessen Felder du nicht geprüft hast. Ein minimales Gate kann diese Reihenfolge erzwingen: 1. Bestätige, dass der angeforderte Vorgang auf einer Allowlist steht und dass seine Methode grundsätzlich destruktiv ist. 2. Löse jedes angegebene Ziel mit einem Leseaufruf unter demselben übergeordneten Konto auf. 3. Vergleiche die zurückgegebene ID, den Typ, das übergeordnete Konto und den erforderlichen Status mit dem strukturierten Vorschlag. 4. Hole die Genehmigung für die ermittelte Auswirkung ein, prüfe anschließend erneut die Aktualität und sende die Änderung. 5. Protokolliere das Ergebnis einschließlich der Anfrage-ID des Anbieters, sofern dieser eine zurückgibt. Halte die Allowlist klein. Ein allgemeiner Ausweg namens `raw_http` macht alle Kontrollen dieses Artikels wirkungslos, weil der Agent beliebige Ziele, Methoden und Bodies wieder einführen kann. Entwickler ergänzen solche Auswege, wenn ein Endpunkt fehlt, und vergessen sie dann, bis sie die Schutzvorkehrungen umgehen, auf die sie vertraut haben. Zugangsdaten sollten außerhalb des Agentenkontexts bleiben. Der Agent braucht das Ergebnis einer erlaubten Aktion, kein Bearer-Token, das er in einen curl-Befehl, ein Log oder eine Drittanbieterintegration kopieren kann. Sallyport folgt bei seinen HTTP-Aktionen diesem Prinzip: Es hält die Zugangsdaten in seinem verschlüsselten Tresor, führt die Anfrage selbst aus und gibt das Ergebnis an den Agenten zurück. ## DELETE macht eine Anfrage weder einfach noch umkehrbar HTTP-Methodennamen zeigen nicht die vollständige geschäftliche Auswirkung. RFC 9110 beschreibt `DELETE` als Aufforderung an einen Ursprungsserver, die Verbindung zwischen einer Zielressource und ihrer aktuellen Funktionalität zu entfernen. Der RFC verspricht ausdrücklich nicht, dass Daten sofort verschwinden, verbundene Daten erhalten bleiben oder eine Wiederholung in deiner konkreten API harmlos ist. Die Dokumentation des Anbieters muss die tatsächliche Auswirkung definieren. Manche APIs markieren ein Objekt zur späteren Entfernung. Manche versehen es mit einem Tombstone. Andere lösen es aus einem übergeordneten Objekt. Wieder andere löschen abhängige Objekte mit. Lies die Antwortcodes und Lebenszyklus-Hinweise des Endpunkts, bevor du einen Vorgang als risikoarm einstufst. Sende keinen Body mit `DELETE`, sofern der Anbieter das nicht ausdrücklich dokumentiert. RFC 9110 sagt, dass Inhalte in einer `DELETE`-Anfrage keine allgemein definierte Semantik haben und dazu führen können, dass Implementierungen die Anfrage ablehnen. Eine Lösch-API, die auf Filter in einem Body angewiesen ist, kann für diesen Anbieter gültig sein. Sie verdient aber zusätzliche Tests über den dokumentierten Clientpfad und darf kein Grund sein, freie Selektoren aus einem Agenten durchzureichen. Auch Wiederholungen brauchen Sorgfalt. Ein Netzwerk-Timeout erzeugt ein unbekanntes Ergebnis: Der Anbieter kann die Löschung abgeschlossen haben, nachdem dein Client aufgehört hat zu warten. Eine sofortige Wiederholung kann irreführende Logs erzeugen, bei einem schlecht entwickelten Endpunkt eine zweite Auswirkung auslösen oder eine Ersatzressource löschen, wenn die Wiederholung den Namen erneut auflöst. Behandle ein unbekanntes Ergebnis nach der Regel «erst prüfen». Frage die exakte unveränderliche ID unter dem exakten übergeordneten Konto ab. Existiert das Objekt nicht mehr und lässt das Löschmodell des Anbieters diese Interpretation zu, protokolliere den Vorgang als abgeschlossen, mit einem Hinweis auf die unsichere erste Antwort. Existiert es noch, prüfe seinen Status und, sofern verfügbar, den Anfrageverlauf des Anbieters, bevor du über eine Wiederholung entscheidest. Verwende einen Idempotenzschlüssel für Vorgänge, die das unterstützen. Erfinde aber keine Idempotenz, die der Anbieter nicht anbietet. Ein `204 No Content` sagt nur, dass der Server die HTTP-Interaktion gemäß der Definition dieses Endpunkts akzeptiert und abgeschlossen hat. Es beweist nicht, dass jede nachgelagerte Bereinigung beendet ist. Wenn die nächste Aktion des Agenten davon abhängt, dass die Löschung vollständig abgeschlossen ist, frage einen dokumentierten Vorgangsstatus oder Ressourcenstatus ab, statt den leeren Antwort-Body als Garantie zu behandeln. ## Die Genehmigung sollte Auswirkungen zeigen, nicht nur Transportdetails Menschen treffen bessere Entscheidungen, wenn eine Genehmigung die Auswirkung in verständlichen Worten beschreibt und die zur Prüfung nötigen IDs enthält. Methode, Pfad und JSON-Body sind für API-Entwickler nützlich. Sie übertragen der Person, die ein falsches Ziel erkennen soll, aber zu viel Analysearbeit. Bei einer einzelnen Ressource sollte die Genehmigung sagen, was sich ändert, das übergeordnete Konto nennen, Ressourcenname und ID anzeigen und auf unumkehrbare oder kaskadierende Auswirkungen hinweisen. Bei einer Sammelaktion sollten Anzahl, begrenzte Stichprobe, verwendete Auswahlregel und der Umstand angezeigt werden, dass die abschließende Aktion die eingefrorenen IDs statt der Regel verwendet. Bitte nicht zu Beginn eines langen Agentenlaufs um eine breite Genehmigung und verwende sie dann für jede spätere Löschung. Die Zielmenge ändert sich, während der Agent Ressourcen entdeckt. Binde die Genehmigung an eine Sitzung und an die aufgelöste Aktion. Wenn sich der Agentenprozess ändert, darf die Genehmigung nicht stillschweigend auf einen neuen Prozess mit möglicherweise anderem Code oder anderen Anweisungen übergehen. Das Gegenproblem ist Genehmigungsmüdigkeit. Wer für jeden harmlosen Lesevorgang klicken muss, klickt später auch bei einer gefährlichen Löschung, ohne zu lesen. Außerdem erhält die Löschung dasselbe visuelle Gewicht wie ein unkritischer Aufruf. Lesevorgänge können, wo angemessen, ohne Interaktion erfolgen. Verlange eine Sitzungsautorisierung für einen neu gestarteten Agenten und eine Bestätigung pro Aktion nur bei Zugangsdaten oder Vorgängen mit destruktiver Wirkung. Wer weniger Aufforderungen sieht, kann die wichtigen genauer prüfen. Der Genehmigungsdatensatz braucht ein klares Ablaufdatum. Je länger ein Agent nach der Prüfung wartet, desto weniger aussagekräftig ist der Preflight. Kann die Aktion nicht zeitnah ausgeführt werden, muss sie erneut aufgelöst und wieder genehmigt werden. Das kann sich bei einer Bereinigungsaufgabe streng anfühlen. Es ist günstiger, als erklären zu müssen, warum eine Genehmigung von vor einer Stunde auf eine Ressource angewendet wurde, die inzwischen neu erstellt worden war. ## Audit-Belege müssen die Entscheidung nachvollziehbar machen, ohne Geheimnisse offenzulegen Ein nützliches Audit-Log beantwortet mehr als «Hat eine Anfrage stattgefunden?» Es sollte rekonstruieren lassen, was der Agent vorgeschlagen hat, was der Dienst vor der Änderung meldete, was ein Mensch genehmigte, was das Gateway sendete und was der Dienst zurückgab. Erfasse normalisierte Felder, nicht nur eine rohe Anfragezeichenfolge. Protokolliere den Aktionsnamen, die Identität der Agentensitzung, die ID des übergeordneten Kontos, Ressourcen-IDs, erwartete Versionen, den Zeitpunkt der Auswahl, die genehmigte Auswirkung, den Genehmigungszeitpunkt, ausgehende Methode und Pfad, Antwortstatus sowie die Anfrage-ID des Anbieters. Speichere Hashes oder redigierte Formen von Anfragematerial, wenn es sensible Werte enthalten kann. Ein Audit-Log, das Autorisierungsheader kopiert, hat einen zweiten Zugangsdaten-Tresor geschaffen. Bewahre die Preflight-Antwort oder einen integritätsgeschützten Digest davon auf. Ohne diesen Beleg kann ein späterer Prüfer nicht erkennen, ob der Agent das falsche Objekt gelöscht hat, weil die Prüfung fehlschlug, weil sich das Objekt danach änderte oder weil der externe Dienst anders als dokumentiert reagierte. Diese Unterscheidung bestimmt, was repariert werden muss. Manipulationsnachweise sind wichtig, wenn dieselbe Maschine den Agenten und das Aktionsgateway ausführt. Ein veränderbares Textlog kann von dem Prozess bearbeitet werden, der den Vorfall verursacht hat. Sallyport erzeugt seine Sitzungs- und Aktivitätsjournale aus einem verschlüsselten Audit-Log mit Hash-Verkettung. Mit `sp audit verify` lässt sich diese Kette offline prüfen, ohne einen Tresorschlüssel zu öffnen. Das macht eine schlechte Genehmigung nicht gut, erschwert aber, nachträgliche Änderungen am Datensatz zu verbergen. Teste die Protokollierung bei fehlgeschlagenen ebenso wie bei erfolgreichen Anfragen. Ablehnungen, abgelaufene Genehmigungen, Versionskonflikte und fehlerhafte IDs zeigen, ob die Kontrollen tatsächlich Arbeit blockieren. Ein Journal voller Erfolge sagt wenig darüber aus, ob das Gate eine gefährliche Anfrage ablehnen würde. ## Baue destruktive Aktionen als enge Verträge Die sicherste API-Aktion ist angenehm eng. Sie akzeptiert genau einen bekannten Vorgang, verlangt ein bekanntes übergeordnetes Konto und eine Objekt-ID, führt eine Vorabprüfung durch und hat eine klar beschriebene Auswirkung. Allgemeine Schnittstellen wirken produktiv, bis ein Agent eine unerwartete Anfrage stellt und deine einzige Verteidigung darin besteht, zu hoffen, dass ein Bediener einen unauffälligen Parameter bemerkt. Beginne mit einer Bestandsaufnahme aller Aktionen, die löschen, widerrufen, rotieren, deaktivieren, überschreiben, veröffentlichen oder Kosten auslösen können. Halte für jede Aktion die unveränderlichen Zielfelder, übergeordneten Felder, zulässigen Status, Kaskadenverhalten, Aktualitätsmechanismus, Wiederholungsverhalten und den Genehmigungstext fest. Kannst du diese Fakten nicht benennen, solltest du die Aktion noch nicht für einen autonomen Agenten freigeben. Schicke anschließend bewusst fehlerhafte Eingaben durch das Gate: eine gültige Ressourcen-ID unter dem falschen Konto, einen passenden Anzeigenamen mit zwei Ergebnissen, ein veraltetes ETag, eine leere Sammelliste, einen fehlenden Filter, ein unter demselben Namen neu erstelltes Ziel und einen Timeout nach dem Absenden. Diese Eingaben zeigen, ob die Grenze die Bedeutung oder lediglich gültiges JSON prüft. Löse Mehrdeutigkeit nicht dadurch, dass der Agent einen längeren Plan schreibt. Mache Mehrdeutigkeit im Aktionsvertrag unmöglich. Ein Agent kann eine Absicht vorschlagen und Belege zusammentragen. Die Grenze zu den Zugangsdaten sollte entscheiden, ob die Belege genau eine erlaubte Auswirkung zu diesem Zeitpunkt und unter diesem Konto beschreiben. Diese Aufteilung ergibt ein System, das du bei Routineanfragen prüfen und auch dann vertrauen kannst, wenn etwas nicht nach Routine aussieht.