# KI-Agenten mit mehreren Cloud-Konten: Jede Aktion binden

KI-Agenten können mehrere Cloud-Konten nur dann sicher nutzen, wenn jede Anfrage genau eine unveränderliche Kontogrenze nennt und der Executor jede Abweichung zurückweist. Ein Agent, der sagen kann «in der Produktion bereitstellen», aber das AWS-Konto, Azure-Abonnement oder Google-Cloud-Projekt hinter diesem Begriff nicht bestimmen kann, hat mehrdeutige Befugnisse erhalten.

Teams behandeln das oft als IAM-Aufräumarbeit. Tatsächlich geht es um das Design der Ausführung. IAM kann den Zugriff auf zwei Konten korrekt erlauben, während der Agent, sein Wrapper oder ein Shell-Profil weiterhin das falsche Konto auswählt. Dann kann ein völlig gültiges Zugangsmittel eine völlig gültige Änderung am falschen Ort ausführen.

Die Lösung ist weniger spektakulär als ein ausgeklügeltes Berechtigungsmodell. Legen Sie ausführbare Ziele im Voraus fest, binden Sie jedes an vom Anbieter vergebene Kennungen und eine eigene Ausführungsidentität, lassen Sie den Agenten ein Ziel über ein Handle anfordern und prüfen Sie den Aufrufer unmittelbar vor einem zustandsändernden Aufruf. Verständliche Umgebungsnamen bleiben nützlich, entscheiden aber nicht darüber, wo Code läuft.

## Mehrdeutige Ziele schaffen echte Befugnisse

Eine Umgebungsbezeichnung ist keine Berechtigungsgrenze. «Produktion» sagt einem Menschen, wie ein Team Ressourcen verwenden will. Eine API erfährt dadurch nicht, welches AWS-Konto, Azure-Abonnement, Google-Cloud-Projekt, welcher Tenant, welche Region oder welche angenommene Rolle eine Anfrage erhalten muss.

Der Unterschied wirkt pedantisch, bis ein Unternehmen `prod`, `production`, `prod-old` und `production-sandbox` über mehrere Organisationen verteilt hat. Bei Migrationen wurden schon Konto-Aliase kopiert, veraltete Shell-Profile zeigten auf stillgelegte Konten und eine harmlos wirkende Leseoperation landete in dem Konto, das Incident-Responder gerade erhalten wollten. Agenten verschärfen das Problem, weil sie natürlichsprachliche Bezeichnungen wörtlich nehmen und deutlich schneller handeln können als die Person, die die Mehrdeutigkeit bemerkt.

Ein Ziel muss vor der Ausführung alle folgenden Fragen beantworten:

- Welcher Anbieter besitzt die Ressource?
- Welche unveränderliche Kontogrenze erhält den Aufruf?
- Welche Umgebung weist die Organisation dieser Grenze zu?
- Welche Ausführungsidentität darf dort handeln?
- Welche geografischen oder organisatorischen Beschränkungen gelten?

Die Reihenfolge ist wichtig. Die Kontogrenze kommt vor der Umgebungsbezeichnung. Eine Anfrage mit `environment: production`, aber ohne Konto-ID oder Abonnement-ID ist unvollständig. Weisen Sie sie zurück, statt den Agenten fehlende Angaben aus einem Repository-Namen, einem Ticket-Titel oder seiner aktuellen Terminalkonfiguration ableiten zu lassen.

Eine häufige, schlechte Empfehlung lautet, dass Benennungskonventionen dieses Problem lösen. Sie helfen Menschen beim Durchsehen einer Liste, sind aber keine Kontrolle. Namen sind veränderbare Zeichenfolgen. Eine Konto-ID, Abonnement-ID, Tenant-ID, Projektnummer, Cluster-UID und Rollen-ARN stammen vom Anbieter und beanspruchen Identität wesentlich verlässlicher.

## Eine Umgebungsbezeichnung darf kein Konto auswählen

Behandeln Sie die Umgebung als kontrollierte Metadaten am Zieldatensatz und nicht als Eingabe, die zur Ausführungszeit ein Ziel auflöst. So verhindert man, dass eine Anfrage wie «diese Korrektur in der Produktion anwenden» ein Live-Inventar durchsucht und das Konto auswählt, dessen Tag zufällig passt.

Das hat eine praktische Folge. Ihr Bereitstellungskatalog kann viele Ziele mit `environment: production` enthalten: Zahlungsverkehr, interne Werkzeuge, regionale Dienste und Konten aus früheren Übernahmen. Jedes bleibt ein eigenes Ziel. Ein Agent muss ein freigegebenes Handle wie `aws-prod-payments` auswählen, statt einen breiten Filter wie `environment=production` zu übermitteln.

Verwenden Sie die Anbieterkennungen, die die tatsächliche Grenze festlegen:

| Anbieter | Binden an | Nicht verlassen auf |
| --- | --- | --- |
| AWS | Konto-ID, Partition, Rollen-ARN, zulässige Region | Konto-Alias, Profilname, Anzeigename der Rolle |
| Azure | Tenant-ID, Abonnement-ID, bei Bedarf Ressourcengruppenbereich | Anzeigename des Abonnements, im Portal ausgewähltes Verzeichnis |
| Google Cloud | Projektnummer und Projekt-ID, bei Bedarf Organisation oder Ordner | Anzeigename des Projekts, aktive lokale Konfiguration |

Die Projekt-ID in Google Cloud ist für Anfragen meist stabil genug. Die Projektnummer liefert zusätzlich eine unveränderliche Prüfung. Azure braucht Tenant und Abonnement, weil ein Abonnement allein den Identitätskontext eines Tokens nicht beschreibt. In AWS sagt eine Kontonummer allein nicht, welche Rolle die Aktion verwenden wird. Binden Sie beides.

Verstecken Sie diese Informationen nicht im Prompt. Eine Anweisung an den Agenten wie «Produktion niemals anfassen» kann ein Zugangsmittel, das die Aktion bereits erlaubt, nicht aufhalten. Der vertrauenswürdige Executor muss den Zieldatensatz besitzen und entscheiden, ob angeforderte Identität und Ziel zusammenpassen.

## Ein Zielverzeichnis sollte Fakten und keine Vermutungen enthalten

Führen Sie ein kleines, geprüftes Verzeichnis ausführbarer Cloud-Ziele. Es ist kein zweites IAM-System und sollte nicht versuchen, jede Cloud-Berechtigung abzubilden. Cloud-IAM entscheidet weiterhin, ob eine Rolle eine API aufrufen darf. Das Verzeichnis beantwortet eine engere Frage: Wohin darf diese Anfrage gehen, wenn sie dieses Ziel-Handle verwendet?

Dieses Beispiel verwendet frei erfundene Kennungen, aber die Struktur ist bewusst gewählt:

```yaml
targets:
  aws-prod-payments:
    provider: aws
    environment: production
    account_id: "482901736154"
    partition: aws
    role_arn: "arn:aws:iam::482901736154:role/agent-payments-deploy"
    regions:
      - us-east-1
      - us-west-2

  azure-prod-fulfillment:
    provider: azure
    environment: production
    tenant_id: "2f34c630-1ce8-4ed3-a7ce-8a3286e799a1"
    subscription_id: "841742bf-9db5-4cf8-9f6b-f1778d5b7511"
    scopes:
      - "/subscriptions/841742bf-9db5-4cf8-9f6b-f1778d5b7511/resourceGroups/fulfillment-prod"

  gcp-prod-catalog:
    provider: gcp
    environment: production
    project_id: "catalog-prod-417"
    project_number: "548201736915"
    parent: "organizations/193847561029"
```

Das Verzeichnis muss wie eine Produktionskonfiguration betreut werden. Weisen Sie jedem Ziel ein verantwortliches Team, einen Prüfweg und ein Ruhestellungsdatum oder einen entsprechenden Status zu, wenn ein Konto außer Betrieb geht. Andernfalls werden alte Ziele unbemerkt zu einer Karte der Orte, die ein Agent noch erreichen kann.

Erstellen Sie Datensätze nicht aus frei formulierter Erkennung und erlauben Sie danach sofort die Ausführung. Cloud-Inventar-APIs helfen dabei, konten ohne Verantwortliche zu finden. Sie sind keine Autorisierungsentscheidung. Ein entdecktes Konto kann eine forensische Kopie, ein von einem Anbieter verwaltetes Abonnement, ein Überbleibsel einer Übernahme oder ein Test-Tenant sein, der verwirrende Produktionsbezeichnungen teilt.

Das Verzeichnis verhindert außerdem ein unauffälliges Driftproblem. Jemand kann ein Azure-Abonnement oder eine AWS-Rolle umbenennen, ohne die unveränderliche ID zu ändern. Das Anzeigelabel kann zur besseren Lesbarkeit aktualisiert werden, während die Bindung erhalten bleibt. Ändert sich die unveränderliche ID, behandeln Sie das als neues, prüfpflichtiges Ziel, selbst wenn der Name gleich bleibt.

## Der Agent sollte ein Handle anfordern und niemals ein Ziel zusammensetzen

Ein Agent sollte Absicht und Ziel-Handle senden. Er sollte keine aus einem Befehl kopierte Rollen-ARN, keinen beliebigen Cloud-Profilnamen und keinen Shell-Befehl mit einem vom Benutzer gewählten Abonnement senden. Diese Felder geben dem Agenten Kontrolle über den empfindlichsten Teil der Anfrage.

Eine Anfrage kann so schlicht aussehen:

```json
{
  "request_id": "chg-8a31f6",
  "target": "aws-prod-payments",
  "operation": "aws.ec2.reboot_instances",
  "region": "us-east-1",
  "arguments": {
    "InstanceIds": ["i-0abc123def4567890"]
  },
  "reason": "Recover the failed checkout worker after approved release"
}
```

Der Executor löst `aws-prod-payments` in den bereits gespeicherten Datensatz auf. Er verwendet ausschließlich die dort aufgeführte Rolle, weist `eu-west-1` zurück, weil diese Region im Datensatz fehlt, und sendet die Anfrage mit der ausgewählten Kontoidentität. Der Agent erhält dabei niemals ein wiederverwendbares Cloud-Zugangsmittel.

Der dadurch verhinderte Fehler ist leicht zu erkennen. Ein Agent führt einen Befehl mit `--profile prod` aus, aber das lokale `prod`-Profil eines Entwicklers zeigt auf das Konto für gemeinsam genutzte Dienste. Der Befehl ist syntaktisch korrekt, die API akzeptiert ihn, und das Team bemerkt den Fehler erst, als der erwartete Zahlungs-Worker weiterläuft. Ein Ziel-Handle, das außerhalb des Agenten aufgelöst wird, gefolgt von einer Identitätsprüfung, stoppt den Befehl, bevor die Neustartanfrage den Executor verlässt.

Akzeptieren Sie nicht sowohl ein Handle als auch ein vom Aufrufer geliefertes Ziel «für mehr Flexibilität». Das schafft zwei Wahrheitsquellen. Enthält eine Anfrage `target: aws-prod-payments` und eine andere Rollen-ARN, muss der Executor sie zurückweisen. Er darf nicht das Feld wählen, das am spezifischsten aussieht.

## Den aktiven Aufrufer vor einem Schreibvorgang prüfen

Ein fester Zieldatensatz ist notwendig, beweist aber nicht, dass das aktive Zugangsmittel dem vorgesehenen entspricht. Tokens laufen ab, Rollenübernahmen schlagen fehl, lokale Profile gelangen in Unterprozesse und Cloud-SDKs können unerwartete Ketten von Zugangsmittel-Anbietern verwenden. Prüfen Sie die aktive Identität unmittelbar vor einem zustandsändernden Aufruf.

Für AWS dokumentiert AWS `GetCallerIdentity` als Aufruf, der Konto, ARN und Benutzer-ID der aufrufenden Identität zurückgibt. In der Dokumentation steht außerdem, dass der Aufruf diese Angaben auch dann liefert, wenn eine explizite Ablehnung ihn sonst blockieren würde. Damit eignet er sich gut als Diagnose- und Vorabmechanismus. Er gewährt keine weiteren Berechtigungen und ersetzt nicht den Vergleich mit dem erwarteten Datensatz.

Ein Vorabaufruf hat etwa diese Ausgabeform:

```bash
aws sts get-caller-identity --output json
```

```json
{
  "UserId": "AROAEXAMPLEID:agent-run-8a31f6",
  "Account": "482901736154",
  "Arn": "arn:aws:sts::482901736154:assumed-role/agent-payments-deploy/agent-run-8a31f6"
}
```

Vergleichen Sie `Account` mit `account_id` des Ziels. Analysieren Sie die ARN und vergleichen Sie die angenommene Rolle mit der konfigurierten Rolle. Verwenden Sie keine Teilzeichenkettenprüfung wie «ARN enthält payments». Weisen Sie eine andere Partition, ein anderes Konto oder eine andere Rolle vor dem Schreibaufruf zurück.

Wenden Sie dasselbe Muster an anderer Stelle an. Fragen Sie bei Azure aktiven Tenant und aktives Abonnement ab und vergleichen Sie beide mit dem ausgewählten Ziel. Fragen Sie bei Google Cloud aktives Projekt und authentifizierten Principal ab und prüfen Sie das Projekt vor einem verändernden API-Aufruf gegen den Zieldatensatz. Diese Prüfungen müssen im selben Prozesskontext laufen, der die Aktion sendet. Ein Terminal zu prüfen und in einem anderen auszuführen, vermittelt nur ein Gefühl von Sicherheit.

Vorabprüfungen haben eine Grenze: Eine Rolle kann korrekt sein und trotzdem zu weit reichende Berechtigungen haben. Die Cloud-Rolle selbst braucht weiterhin minimale Berechtigungen für ihr Ziel. Die Bindung verhindert, dass eine Anfrage in ein unbeabsichtigtes Konto gelangt. IAM begrenzt, was die korrekte Kontoidentität dort tun kann. Beide Kontrollen sind nötig.

## Breite kontoübergreifende Rollen verbergen den Fehler, bis er schadet

Eine Administratorrolle, die in jedes Konto wechseln kann, ist beliebt, weil sie den Einrichtungsaufwand reduziert. Sie macht die Zielauswahl aber zu einer irreversiblen Entscheidung mit hohem Risiko. Wählt der Agent oder Executor das falsche Konto, hat dieselbe weitreichende Identität oft genügend Zugriff, um den Fehler abzuschließen.

Trennen Sie Ausführungsrollen nach Konto und Zweck. Eine Produktionsrolle für Bereitstellungen im Zahlungsverkehr sollte keinen Vertrauenspfad zu Analyse-, Identitäts- oder Notfallwiederherstellungskonten besitzen. Wenn ein Agent kontenübergreifend Lesezugriff braucht, verwenden Sie getrennte Leseschreibrollen und machen Sie die Zielbindung bei jedem Aufruf sichtbar. Lesezugriff kann Kundendaten, die Infrastruktur-Topologie und an ungeeigneten Orten gespeicherte Zugangsdaten offenlegen. «Nur lesen» macht Auswahlfehler nicht harmlos.

Nutzen Sie native Vertrauensbedingungen der Cloud, um die Übernahme einer Rolle zu begrenzen. Vertrauensrichtlinien für AWS-Rollen können den vertrauenswürdigen Principal einschränken und, wenn es zum Aufrufer passt, eine externe ID verlangen. Azure-Workload-Identitäten lassen sich durch Ansprüche föderierter Anmeldedaten und Ressourcenzuweisungen begrenzen. Bei Google Cloud kann die Identitätsübernahme eines Dienstkontos einschränken, wer ein Zugriffstoken ausstellen darf. Die genaue Technik unterscheidet sich, das Design bleibt gleich: Eine Ausführungsidentität sollte genau einem geprüften Ziel und Zweck zugeordnet sein.

Verwechseln Sie eine zentrale Broker-Identität nicht mit umfassender Berechtigung. Ein Broker kann Anfragen für viele Ziele koordinieren, während jede Anfrage eine zielbezogene Identität erhält. Das erfordert mehr Einrichtung als eine universelle Administratorrolle, macht aber den Schaden sichtbar, wenn Prozess, Prompt oder Integration einen Fehler machen.

## Eine Bestätigung muss das für Menschen prüfbare Ziel zeigen

Niemand kann eine sichere Aktion bestätigen, wenn die Kontogrenze in der Bestätigung fehlt. «Checkout-Worker in der Produktion neu starten» verlangt vom Prüfer, einer unsichtbaren Auflösungslogik zu vertrauen. Die Bestätigung braucht Ziel-Handle, Umgebungsbezeichnung, unveränderliche Konto-ID, aktive Rolle oder Dienstidentität, Aktion und Ressourcenbereich, auf den die API zugreifen wird.

Für den Neustart einer AWS-Instanz könnte eine sinnvolle Bestätigung so aussehen:

```text
Target: aws-prod-payments
Environment: production
Account: 482901736154
Identity: agent-payments-deploy
Action: ec2:RebootInstances
Region: us-east-1
Resource: i-0abc123def4567890
Reason: Recover failed checkout worker after approved release
```

Diese Detailtiefe ist keine Formsache. Prüfer kennen häufig die Kontonummer oder das Ziel-Handle ihres eigenen Dienstes, während die Beschreibung eines Agenten plausibel und dennoch falsch sein kann. Das Ziel muss vor der Aktionsbeschreibung groß genug erscheinen, um schnell geprüft zu werden. Eine überraschende Kontonummer fällt Menschen eher auf als eine subtile Abweichung in einem Befehlspayload.

Fordern Sie keine pauschale Bestätigung für «alle Arbeiten in dieser Sitzung» an, wenn die Sitzung mehrere Produktionskonten umfasst. Eine Sitzung kann eine berechtigte Grenze haben, etwa wiederholte Änderungen an einem Bereitstellungsziel, darf sich aber nicht unbemerkt ausweiten. Fordern Sie eine neue Bestätigung an, wenn sich das Ziel-Handle ändert, eine Operation von Lesen zu Schreiben wechselt oder eine Anfrage einen sensibleren Bereich betrifft als ursprünglich bestätigt.

Die sitzungsbezogene Autorisierung von Sallyport identifiziert den verbindenden Prozess. Die Anmeldeinformation pro Aufruf kann außerdem für jede Verwendung eine Bestätigung verlangen. Das ist nur dann hilfreich, wenn die Aktionsanfrage ein für den Prüfer erkennbares Ziel enthält und der Executor dieses bereits an ein einziges Ziel gebunden hat.

## Logs müssen Absicht, Identität und Nachweise des Anbieters verbinden

Cloud-Audit-Logs zeigen, welche Identität eine API aufgerufen hat, erklären aber selten die Anweisung des Agenten, die Zielauswahl oder die Entscheidung des Prüfers. Aufzeichnungen auf Agentenseite erklären die Absicht, beweisen aber nicht, dass die Cloud den erwarteten Aufruf erhalten hat. Bewahren Sie beide Datensätze auf und verbinden Sie sie mit Anfrage-ID und unveränderlichen Zielkennungen.

Erfassen Sie für jede Aktion vor und nach der Ausführung folgende Felder:

- den Agentenprozess oder die Sitzung, von dem beziehungsweise der die Anfrage ausging
- das ausgewählte Ziel-Handle und die aufgelösten unveränderlichen Kennungen
- die bei der Vorabprüfung beobachtete Ausführungsidentität
- Operation, Ressourcenbereich, Ergebnis und Anfrage-ID
- die Referenz auf das Audit-Ereignis des Anbieters, sofern dieser eine liefert

AWS CloudTrail, Azure Activity Log und Google Cloud Audit Logs erfassen jeweils Aktivitäten auf Anbieterseite, abhängig von den verwendeten Diensten und der Logging-Konfiguration. Bewahren Sie diese Datensätze in einer eigenen Sicherheitsgrenze auf. Behandeln Sie ein Agenten-Aktivitätslog nicht als Ersatz für den Nachweis des Anbieters, weil ein kompromittierter lokaler Prozess über eine Anfrage lügen könnte, die er nie abgeschlossen hat.

Sallyport erfasst Agentenläufe und einzelne Aufrufe in getrennten Journalen, die aus einem verschlüsselten, hashverketteten Audit-Log abgeleitet werden. Mit `sp audit verify` lässt sich diese Kette offline über dem Chiffretext prüfen. Das hilft festzustellen, ob lokale Aktionsaufzeichnungen nach einem Vorfall verändert wurden.

Der praktische Test ist eine Untersuchungssimulation. Wählen Sie eine genehmigte Änderung aus und bitten Sie einen Ingenieur, ohne zu raten vier Fragen zu beantworten: Welcher Agentenprozess hat sie angefordert, welches Ziel wurde ausgewählt, welche Cloud-Identität hat sie ausgeführt und welches Ereignis auf Anbieterseite bestätigt sie? Wenn eine Antwort erfordert, Zeitstempel manuell über drei Konsolen abzugleichen, sind Ihre Aufzeichnungen zu schwach.

## Ein Vorfall im falschen Konto beginnt meist vor dem API-Aufruf

Der sichtbare Fehler ist häufig eine Änderung in der Produktion, die im falschen Konto landet. Der frühere Fehler ist meist ein unkontrollierter Auflösungspfad. Behandeln Sie den Vorfall als Bindungsfehler und nicht bloß als Fall, in dem jemand «das falsche Profil verwendet» hat.

Betrachten wir einen plausiblen Ablauf. Ein Repository enthält ein Skript, das `ENV=prod` akzeptiert. Sein Wrapper übersetzt das in ein AWS-Profil namens `prod`. Während einer Migration änderte ein Entwickler dieses Profil so, dass es auf ein Konto für gemeinsam genutzte Dienste zeigte, weil kein direkter Zugriff auf das alte Zahlungskonto mehr erforderlich war. Später erhält ein Agent die Anfrage, einen Zahlungs-Worker neu zu starten. Er findet das Skript, setzt `ENV=prod` und führt es aus. Die Profilauflösung des Skripts wählt die gemeinsam genutzten Dienste. Die Rolle verfügt über weitreichende EC2-Berechtigungen, weil das Team sie aus Bequemlichkeit für den Betrieb verwendete. Der Neustart gelingt im falschen Konto.

Die Cloud-API war an keiner Stelle verwirrt. Das Skript stellte eine gültige Anfrage mit einer gültigen Identität. Eine Maßnahme nach dem Vorfall, die Agenten lediglich auffordert, «das Konto noch einmal zu prüfen», wird wieder scheitern, weil der gleiche Auflösungspfad bestehen bleibt.

Beheben Sie diese Fehlerklasse in einer konkreten Reihenfolge:

1. Deaktivieren Sie den betroffenen Sitzungs- oder Rollenpfad und sichern Sie Agenten- sowie Cloud-Audit-Logs.
2. Bestimmen Sie den exakten Selektor, der das falsche Ziel gewählt hat, etwa Profilname, Standardabonnement, Umgebungs-Tag oder eine vom Aufrufer gelieferte Rollen-ARN.
3. Ersetzen Sie diesen Selektor durch ein freigegebenes Ziel-Handle, das der Executor auflöst.
4. Ergänzen Sie einen Vergleich der aktiven Identität, der jede Abweichung vor Schreibvorgängen zurückweist.
5. Teilen Sie die weitreichende Rolle auf, falls sie Aktionen in nicht zusammengehörigen Konten erlaubte.

Testen Sie anschließend absichtlich den Ablehnungspfad. Verknüpfen Sie ein Staging-Ziel mit einem Zugangsmittel für ein anderes Testkonto und prüfen Sie, ob der Executor vor dem verändernden API-Aufruf stoppt. Teams testen oft nur erfolgreiche Abläufe und weisen nie nach, dass ihre Kontobindung bei Fehlern sicher abbricht.

## Der Rollout gelingt am besten mit den riskantesten Schreibvorgängen

Warten Sie nicht auf ein vollständiges Cloud-Inventar, bevor Sie gefährliche Aktionen explizit binden. Beginnen Sie mit Vorgängen, die den Produktionszustand ändern oder offenlegen können: Bereitstellungen, Identitätsänderungen, Netzwerkänderungen, Datenexporte, Geheimnisrotation und destruktive Infrastruktur-Befehle. Schreibgeschützte Erkennung kann beim Aufbau des Verzeichnisses helfen, sollte aber neu gefundene Konten nicht stillschweigend für die Ausführung freigeben.

Listen Sie zuerst die Konten auf, die solche Aktionen empfangen können, und weisen Sie jedem eine klare Umgebung und einen Verantwortlichen zu. Erstellen Sie danach für jedes Konto-Zweck-Paar einen Zieldatensatz. Lassen Sie dann einen Executor-Pfad Handles auflösen, zielbezogene Zugangsdaten beziehen, die aktive Identität prüfen und die Aktion protokollieren. Entfernen Sie zuletzt den direkten Agentenzugriff auf Umgebungsprofile, Standardabonnements und Zugangsdaten-Dateien.

Rechnen Sie mit Widerstand von Ingenieuren, die gewohnt sind, Konten im Terminal mit einer Variablen zu wechseln. Diese Gewohnheit ist schnell, weil sie den Kontext in das Gedächtnis einer Person verlagert. Ein autonomer Agent verfügt nicht über dieses Gedächtnis, und die Menschen, die seine Aktionen prüfen, ebenfalls nicht. Legen Sie den Kontext in die Anfrage, das Zielverzeichnis und die Ausführungsnachweise.

Wenn Sie Kontonummer, Ausführungsidentität und Ressourcenbereich einer Aktion vor ihrer Ausführung nicht nennen können, verfügt der Agent noch nicht über genügend Informationen für einen sicheren Vorgang. Lassen Sie ihn die fehlenden Fakten beschaffen oder überlassen Sie die Aktion einem Menschen.