Wenn ein Coding-Agent in einer AWS-Umgebung arbeitet, tut er das in der Regel mit den Rechten eines Menschen. Er übernimmt eine IAM-Rolle, und in CloudTrail steht danach der Name dieser Rolle – nicht, dass hier ein Modell in einer Schleife gehandelt hat. Genau diese Unterscheidung ist in dieser Woche von der Randnotiz zum Kernproblem geworden, nachdem zwei kritische PHP-Lücken eine globale Patch-Welle ausgelöst haben und Cloudflares CEO Matthew Prince gegenüber Reuters sagte, es kämen „ein paar Jahre, in denen sich jede einzelne Woche anfühlen wird, als fiele der Himmel herunter“.

AWS hat darauf keine Rede gehalten, sondern still seine Werkzeugsammlung umgebaut. Die älteren Repositories aus dem AWS-Labs-Programm tragen inzwischen Deprecation-Hinweise; awslabs/startups etwa schreibt, seine Plugins seien nach aws/agent-toolkit-for-aws umgezogen. Das Agent Toolkit ist seither das unterstützte Produkt: Apache-2.0, seit April öffentlich, inzwischen rund 3.200 Sterne und gut 400 Forks, zuletzt am 23. Oktober aktualisiert.

Was drin ist:

- Vier Plugins für Claude Code, Codex und Cursor (Kiro bekommt den MCP-Server direkt): aws-core für Serviceauswahl, CDK/CloudFormation, Serverless, Container, Storage, Observability, Abrechnung und Deployment; aws-agents für Bedrock und AgentCore; aws-data-analytics für S3 Tables, Glue und Athena; aws-agents-for-devsecops für Incident-Untersuchung, Code-Review, UAT-Freigaben, Vulnerability-Scans und Penetrationstests über AWS DevOps Agent und AWS Security Agent. - Agent Skills, die nur bei Bedarf geladen werden, plus Rules-Dateien, die dem Agenten sagen, wann er die Dokumentation durchsuchen soll, statt zu raten. - Den AWS MCP Server: ein verwalteter, authentifizierter Endpunkt für über 300 Services, mit sandboxierter Python-Ausführung, Dokumentationssuche ohne Anmeldung, CloudWatch-Metriken und CloudTrail-Protokollierung pro Anfrage.

Der eigentlich interessante Teil sind zwei IAM-Kontextschlüssel: aws:ViaAWSMCPService und aws:CalledViaAWSMCP. AWS setzt sie auf Aufrufe, die über seine verwalteten MCP-Server laufen. Damit lässt sich eine Policy schreiben, die einem Agenten nur Leseaktionen erlaubt, selbst wenn die zugrunde liegende Rolle schreiben dürfte – oder die bestimmte Aktionen ausschließlich dann zulässt, wenn sie von einem Menschen kommen. Das ist keine Sandbox und keine Zustandsmaschine. Es ist eine Identitätsebene: Der Aufruf trägt jetzt mit, wer ihn ausgelöst hat.

Warum das mehr ist als Produktpflege: Die vergangenen zwei Wochen haben gezeigt, wie schnell ein Agent, der Rechte hat, zum Angriffsvektor wird – nicht weil er böswillig ist, sondern weil er Anweisungen folgt, die in einem Ticket, einer README oder einer Webseite stehen. Wenn ein Agent nur lesen darf, ist eine Prompt-Injection unangenehm. Wenn er deployen darf, ist sie ein Vorfall. Die Trennung von Agent- und Menschen-Aktion ist die Voraussetzung dafür, überhaupt eine Grenze ziehen zu können.

Was das Toolkit nicht löst:

- Innerhalb der gewährten Rechte bleibt ein kompromittierter Agent gefährlich. Der Schlüssel sagt, wer gehandelt hat; er sagt nicht, ob das Handeln klug war. - Ein devsecops-Plugin, das Penetrationstests anstoßen kann, ist selbst ein mächtiges Werkzeug. Wer es installiert, sollte wissen, mit welcher Rolle es läuft. - Die IAM-Schlüssel greifen bei Aufrufen über die verwalteten MCP-Server. Wer Agents direkt gegen die CLI oder eigene Integrationen laufen lässt, bekommt diese Unterscheidung nicht geschenkt. - Und die Protokollierung ersetzt keine Richtlinie: CloudTrail zeigt hinterher, was passiert ist. Die Entscheidung, was ein Agent dürfen soll, trifft weiterhin ein Mensch.

Die praktische Konsequenz für Teams ist unromantisch: Agenten bekommen eigene Rollen statt geliehener, Policies bekommen Bedingungen statt Vertrauen, und die Frage „welche Rechte braucht dieses Ding wirklich“ wird vor dem ersten Deploy beantwortet statt nach dem ersten Vorfall. AWS liefert dafür jetzt die Bausteine – und die Ausrede, es gebe keine Möglichkeit, Agenten von Menschen zu unterscheiden, ist seit dieser Woche schwächer.

Quellen