AWS und SANS ordnen Agentenrisiken – Identitäten werden zum blinden Fleck
Amazon Web Services (AWS) veröffentlichte am 2. September 2026 einen Beitrag über ein gemeinsam mit dem SANS Institute entwickeltes Kapitel im eBook zur Cloud Security Exchange 2026. Der Beitrag im AWS Security Blog ordnet die Absicherung agentischer Workloads in vier Bereiche: Identität und Governance, kontinuierliche Verhaltenserkennung, abgestufte Reaktion sowie die zusätzlichen Risiken von Multi-Agenten-Systemen.
Der am 2. September vorgestellte Rahmen beantwortet die zentrale Kontrollfrage damit nicht zuerst auf der Ebene des Sprachmodells. Entscheidend ist, welcher Agent mit welcher eigenen Identität unter wessen Verantwortung auf welche Werkzeuge und Daten zugreifen darf – und ob seine Handlungen erkannt, begrenzt und nachträglich rekonstruiert werden können. Filter gegen Prompt Injection oder unerwünschte Ausgaben bleiben relevant, ersetzen diese Zugriffskontrollen aber nicht.
Die Identität wird zur ersten Kontrollfläche
Der blinde Fleck entsteht, wenn ein autonomer Agent zwar gültige Zugangsdaten besitzt, im Identitätsbestand aber nicht als eigenständiger Akteur geführt wird. Agenten können APIs aufrufen, mehrstufige Abläufe ausführen und Entscheidungen über Cloud-Ressourcen treffen. Erscheinen ihre Aktionen dabei unter dem Konto eines Menschen oder einem gemeinsam verwendeten Dienstkonto, lässt sich die tatsächliche Handlungskette nur unvollständig zuordnen.
Eine am 12. Juni 2026 veröffentlichte Zero-Trust-Checkliste des SANS Institute beginnt deshalb mit dem Aufbau eines Agenteninventars und der Durchsetzung minimaler Rechte. Darauf folgen Zero-Trust-Architektur, eine Baseline des normalen Verhaltens und eine vorbereitete Vorfallreaktion. SANS beschreibt KI-Agenten ausdrücklich als nichtmenschliche Identitäten, die viele Organisationen bislang weder vollständig zählen noch konsistent steuern oder auf Kompromittierungen überwachen können.
AWS ergänzt diese Perspektive um konkrete Architekturprinzipien: Jeder Agent soll eine eigene Identität und temporäre, eng begrenzte Zugangsdaten erhalten. Anfragen müssen einzeln authentifiziert und autorisiert werden; Aktionen sollen über eine nachvollziehbare Autorisierungskette mit dem ausführenden Agenten verbunden bleiben. Damit rückt nicht nur die Qualität einer Modellausgabe in den Blick, sondern auch die Reichweite einer technisch zulässigen Handlung.
Eine Prioritätenmatrix für Pilot und Produktion
Aus beiden Veröffentlichungen lässt sich eine gestufte Prioritätenmatrix ableiten. Die Trennung zwischen Pilot- und Produktivbetrieb ist eine redaktionelle Umsetzung der dokumentierten Prinzipien, keine zusätzliche Vorgabe von AWS oder SANS:
- Identität: Im Pilotbetrieb müssen alle Agenten inventarisiert, einem verantwortlichen Bereich zugeordnet und technisch unterscheidbar sein. Für den dauerhaften Betrieb kommen ein geregelter Lebenszyklus der Identitäten, temporäre Zugangsdaten und die nachvollziehbare Zuordnung delegierter Aktionen hinzu.
- Berechtigung: Ein Pilot sollte nur auf freigegebene Werkzeuge und begrenzte Testdaten zugreifen können. Bei produktiver Autonomie muss eine vom Modell getrennte Kontrollinstanz sensible Aufrufe autorisieren; folgenreiche Aktionen benötigen klar definierte Grenzen oder eine menschliche Freigabe.
- Verhalten: Schon der Pilot muss zusammenhängende Protokolle über Werkzeugaufrufe und Datenzugriffe erzeugen. Im Produktivbetrieb werden daraus belastbare Baselines, anhand derer neue Ziele, ungewöhnliche Aufrufreihenfolgen oder auffällige Datenzugriffe erkannt werden können.
- Vorfallreaktion: Für einen Pilot sind ein benannter Abschaltweg und auswertbare Protokolle das Minimum. Produktive Systeme benötigen abgestufte Maßnahmen, die vom Blockieren eines einzelnen Aufrufs über eingeschränkte Rechte bis zur Isolation des Agenten und zur menschlichen Eskalation reichen.
Diese Reihenfolge macht zugleich den Unterschied zwischen Anbieterempfehlung und übertragbarem Sicherheitsprinzip sichtbar. AWS verweist für Erkennung, Schwachstellenmanagement und zentrale Sicherheitsabläufe auf Amazon GuardDuty, Amazon Inspector und AWS Security Hub. Eigene Identitäten, externe Autorisierung, durchgängige Telemetrie und vorbereitete Eindämmung sind dagegen nicht an eine bestimmte Cloud-Plattform gebunden.
Verhaltensüberwachung braucht einen bekannten Normalzustand
Statische Verbotsregeln decken bekannte unerlaubte Aktionen ab, erkennen aber nicht jede Abweichung eines anpassungsfähigen Agenten. Die Dokumentation der SANS Cloud Security Exchange ordnet deshalb Identitätskontrollen, Observability, Laufzeitschutz, kontinuierliche Überwachung sowie automatisierte Eindämmung und Behebung als zusammengehörige Architekturthemen ein. Die dort dokumentierte AWS-Session unterscheidet zudem zwischen sofortiger Eindämmung, menschlicher Eskalation und Abläufen, die ein System selbst abschließen darf.
Eine Verhaltensbaseline bewertet nicht, ob eine Antwort sprachlich gewöhnlich klingt. Relevant sind die operativen Muster: welche APIs der Agent verwendet, welche Ressourcen er erreicht, in welcher Reihenfolge er Werkzeuge aufruft und wohin er Daten übermittelt. Ein erstmals kontaktiertes Ziel oder ein für den dokumentierten Zweck ungewöhnlich breiter Zugriff kann damit ein Warnsignal auslösen, obwohl die einzelne Anfrage formal authentifiziert wurde.
Die Reaktion muss zum Risiko und zur Eindeutigkeit des Signals passen. Ein klar unzulässiger Werkzeugaufruf kann automatisch blockiert werden. Bei einer ungewöhnlichen, aber möglicherweise legitimen Abfolge ist eine Einschränkung der Rechte mit anschließender menschlicher Prüfung oft angemessener als das sofortige Abschalten des gesamten Systems.
Mit der Autonomie wachsen die Kontrollen kumulativ
AWS beschreibt die Reifegrade nicht als Austausch vorhandener Schutzmaßnahmen. Die Empfehlungen gelten von der Evaluierung über Pilotprojekte bis zum Betrieb in großem Maßstab; mit wachsender Autonomie kommen Kontrollen hinzu. Sobald Agenten Aufgaben weitergeben, Zugriffe aushandeln oder über Organisationsgrenzen hinweg zusammenarbeiten, müssen auch Delegationsketten und weitergereichte Berechtigungen sichtbar bleiben.
Die veröffentlichten Materialien liefern Architektur- und Umsetzungsmuster, aber keinen universellen Zertifizierungsmaßstab für heterogene Agentenplattformen. Ebenfalls offen bleibt, welche plattformübergreifenden Nachweise sich für Identitäten, Autorisierungsketten und Verhaltensbaselines durchsetzen werden. Belastbar ist bereits die Reihenfolge: Ohne Inventar, unterscheidbare Identitäten, begrenzte Rechte und rekonstruierbare Aktionen fehlt die Grundlage, auf der Verhaltensüberwachung und Vorfallreaktion zuverlässig aufbauen können.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.