AgentCore und Zugangsdaten: Was kann die Shell erreichen?

TL;DR: AWS dokumentiert 2 standardmäßige Harness-Werkzeuge, Shell und Dateioperationen, sofern der Betreiber sie nicht einschränkt; die MicroVM-Isolierung trennt Sitzungen.^[2][4] Die Analyse von LLMRumors: Zum Schutz der Zugangsdaten eines Agenten gehört auch die Entscheidung, welche Komponenten innerhalb dieser Sitzung sie verwenden oder lesen dürfen.

Der Bericht von Unit 42 vom 18. September 2026, der am 1. Oktober erneut auf X kursierte, beschreibt eine Prompt Injection, nach der eine Shell aktive Zugangsdaten auslas und auf einen simulierten nachgelagerten Dienst zugriff. Laut Forschern schloss AWS ihren Bericht am 10. Juni als informativ.^[1] Dieser Artikel vom 5. Oktober analysiert die Folgen für den Einsatz.^[9]

Die entscheidende Frage ist, wohin Befugnisse wandern, sobald ein Agent arbeitet. Ein Support-Ablauf kann aus Nutzersicht eng begrenzt wirken und trotzdem auf einer Dienstidentität mit deutlich umfassenderem Zugriff beruhen. Die Architektur muss diesen Unterschied erhalten, wenn nicht vertrauenswürdige Inhalte in den Ablauf gelangen.

Unsere frühere Analyse zu Agenten-Sandboxes (Englisch) untersuchte Isolierungsentscheidungen verschiedener Plattformen. Hier geht es um Befugnisse für Zugangsdaten innerhalb einer Sitzung, eine andere Frage als die Grenze um diese Sitzung.

Titelbild: Neu generierte redaktionelle Illustration. Tuscheillustration eines Terminalraums neben einem verschlossenen Zugangsdaten-Tresor und einer separaten Tür. Sie ist keine Produktaufnahme und kein Messbeleg.

Sitzungsisolierung: Die Grenze vor dem Vertrauen benennen

AWS beschreibt dedizierte MicroVMs mit getrennten CPU-, Speicher- und Dateisystemressourcen für Nutzersitzungen.^[4] Das sind wertvolle Kontrollen gegen den Zugriff einer Sitzung auf eine andere. Sie legen allein jedoch nicht fest, welche Komponenten innerhalb derselben Sitzung einander untersuchen dürfen.

Gefragt werden muss, was innerhalb der Sandbox gemeinsam läuft, welcher Code Befugnisse erhält und welche vertrauenswürdige Komponente die nachgelagerte Authentifizierung übernimmt. Eine Grenze um eine Anwendung kann trotzdem Komponenten mit unterschiedlichen Vertrauensanforderungen einschließen.

Die Harness-Übersicht von AWS verbindet verwaltete Infrastruktur mit einer eigenen Shell und einem Dateisystem für den Agenten.^[3] Genau darin liegt der Reiz des Produkts: Teams müssen weniger Aufwand in die umgebende Infrastruktur investieren. Zugleich wird ein Diagramm der internen Befugnisse zum notwendigen Bestandteil der Einsatzprüfung, neben dem Diagramm zur Trennung der Cloud-Nutzer.

Vault-Verschlüsselung: Speicherschutz hat einen definierten Umfang

AWS dokumentiert die automatische Verschlüsselung gespeicherter Daten im Token-Vault mit AWS-eigenen KMS-Schlüsseln; kundenverwaltete Schlüssel stehen als Alternative zur Verfügung.^[10] Unsere Schlussfolgerung: Die Entscheidung über die Verwaltung des Schlüssels unterscheidet sich von der Entscheidung, welche laufende Komponente nutzbare Zugangsdaten erreichen kann. Prüfen Sie beides. Eine strengere Speicherrichtlinie belegt keine Trennung zwischen Shell und Authentifizierungsprozess.

Standardwerkzeuge: Jede Fähigkeit braucht einen Verantwortlichen

Laut Werkzeugdokumentation erlaubt das Weglassen von allowedTools sämtliche Werkzeuge. Sie unterscheidet außerdem zwischen vom Modell ausgewählten Werkzeugen und einer separaten API zur direkten Befehlsausführung mit eigener IAM-Berechtigung.^[2] Eine Beschränkung der ersten Kategorie belegt nicht, dass die zweite gesperrt ist.

Unsere Empfehlung betrifft den Betrieb: Die Verantwortung für die wirksamen Berechtigungen gehört an die Anwendungsgrenze. Dokumentieren Sie die Fähigkeiten, die ein Ablauf benötigt, testen Sie die Nichtverfügbarkeit anderer Fähigkeiten und wiederholen Sie die Prüfung bei neuen Integrationen. Eine deklarierte Werkzeugliste sollte ein prüfbarer Vertrag sein, keine bloße Erinnerung in einer Konfigurationsdatei.

Daraus entsteht ein echter Zielkonflikt. Allgemeine Codeausführung ist gerade deshalb nützlich, weil nicht jede Operation vorhergesehen werden muss. Eng begrenzte Werkzeuge machen erlaubtes Verhalten leichter aufzählbar. Entscheiden Sie sich für jeden Arbeitsablauf bewusst für diese Flexibilität und planen Sie den Entwicklungsaufwand für ihre Begrenzung ein. Diese Kosten gehören in die Wirtschaftlichkeitsrechnung der Automatisierung.

Identität: Aufruf und nachgelagerter Zugriff getrennt entscheiden

AgentCore Identity verwaltet Authentifizierung und Zugangsdaten für Agenten, die auf AWS und Drittanbieterdienste zugreifen.^[5] Aus Sicht des Anwendungsdesigns kann ein Identitätsdienst jedoch nicht entscheiden, welchen Kundendatensatz eine konkrete Support-Anfrage sehen sollte. Dafür braucht es die umgebende Autorisierungsrichtlinie.

Der Harness-Sicherheitsleitfaden von AWS beschreibt nutzerbezogene Zugangsdaten für nachgelagerte Dienste über eingehendes OAuth. Laut Dokumentation wird die Nutzeridentität bei SigV4-Aufrufen derzeit nicht entsprechend weitergegeben.^[6] Teams sollten deshalb den tatsächlichen Identitätsfluss prüfen, statt anzunehmen, dass jede Integration die Berechtigungen des Aufrufenden übernimmt.

AWS dokumentiert deterministische Richtlinienprüfungen für den Datenverkehr durch AgentCore Gateway, einschließlich Regeln anhand der Nutzeridentität und Werkzeugparameter.^[11] Damit erhalten Teams einen Durchsetzungspunkt jenseits der Erklärung des Modells. Sein Umfang zählt: Eine Gateway-Richtlinie sollte nicht als Kontrolle jedes Shell-Befehls gelten. Erfassen Sie, welche Zugriffswege durch diesen Punkt führen und welche nicht.

Geteilte Verantwortung: Dokumentation in Abnahmekriterien übersetzen

Das allgemeine Verantwortungsmodell von AWS besagt, dass Kundenpflichten vom Dienst und seiner Integration abhängen.^[7] Die Datenschutzdokumentation für Identity ordnet die Sicherheitskonfiguration dem Kunden zu und empfiehlt Aktivitätsprotokolle sowie den Schutz von Zugangsdaten.^[8] Diese Aussagen erklären die Zuständigkeit; sie bestätigen das berichtete Experiment der Forscher nicht unabhängig.

Laut VPC-Leitfaden bestimmen Sicherheitsgruppen, mit welchen Ressourcen die Laufzeit kommunizieren kann; empfohlen werden möglichst geringe Berechtigungen und VPC Flow Logs.^[12] Unsere Synthese: Netzwerkreichweite, Werkzeugberechtigung und Datenautorisierung sind getrennte Abnahmekriterien. Prüfen Sie diese mit harmlosen synthetischen Daten, einschließlich eines gesperrten Ziels und einer unerlaubten Geschäftstransaktion. Zugriff auf einen genehmigten Dienst bedeutet nicht, dass jede Operation dort erlaubt sein sollte.

Verwaltete Infrastruktur erleichtert den Einsatz von Agenten. Sie beseitigt nicht die Pflicht des Betreibers, delegierte Befugnisse zu verstehen. Der Unternehmensvorteil wird bei den Teams liegen, die erklären, testen und begrenzen können, was ihre Agenten tatsächlich tun dürfen.

Quellen

Zuletzt aktualisiert: 5. Oktober 2026