AWS will Agenten mehr Autonomie geben, aber nur bei überprüfbaren Aktionen

AWS will Agenten mehr Autonomie geben und Freigaben auf das Nötige beschränken

Auf aws.amazon.com ist der Beitrag „Trust in Depth: Giving agents more autonomy without losing control“ erschienen. Der Text spricht in der Ich-Form. Wer ihn verfasst hat, geht aus dem Auszug nicht hervor, und der Auszug bricht mitten im Satz ab.

AWS beschreibt das Problem so: Agenten wählen Werkzeuge und Schrittfolgen selbst, ohne dass ein Entwickler sie vorgegeben hätte. Derselbe Auftrag kann bei zwei Läufen verschiedene Wege nehmen. Ein heute bestandener Test sagt deshalb wenig über das Verhalten von morgen. Klassische Abnahmetests stoßen hier an Grenzen, denn sie prüfen einen konkreten Ablauf, und der Agent kann beim nächsten Mal einen anderen gehen.

Die übliche Antwort, dass ein Mensch jede Aktion genehmigt, skaliert nach AWS nicht. Mit wachsender Arbeitsmenge häufen sich die Freigaben. Prüfer ermüden und übersehen gerade die relevanten Fälle. Vorsicht wird so zum Engpass, und leistungsfähige Agenten bleiben ungenutzt.

AWS setzt auf einen anderen Ansatz. Der Agent handelt eigenständig, solange sich seine Aktionen verifizieren lassen. Menschliches Urteil bleibt den Entscheidungen vorbehalten, die es brauchen. Bei höherem Risiko, etwa bei Finanztransaktionen, soll der Agent auch dann innerhalb der gesetzten Grenzen bleiben, wenn niemand zusieht. Dieses Vertrauen, so AWS, müsse erst aufgebaut werden.

Den Einstieg bildet eine Selbstdarstellung. Unternehmensverantwortliche wollten ausnahmslos, dass Agenten mehr leisten, trauten ihnen aber nicht zu, es dauerhaft richtig zu tun. Die Aussage ist anekdotisch und ohne Zahlen belegt. Prüfbar wäre sie nur durch unabhängige Umfragen unter Unternehmen.

Vieles bleibt offen. AWS nennt Content-Filterung, Tests und Monitoring jeweils als wichtig. Der Satz, der erklärt, was ihnen fehlt, ist im Auszug abgeschnitten. Welche Schichten, Mechanismen und Kontrollen „Trust in Depth“ konkret umfasst, steht nicht im Material.

Schutzschichten für Agenten sind Branchenstandard, neu ist die Rahmung

Mehrere Schichten zur Absicherung von Agenten sind keine AWS-Erfindung. Microsoft stützt die Sicherheit autonomer Agenten nach eigener Darstellung auf Defense in Depth. Mit wachsender Autonomie, so die Argumentation des Unternehmens, verschiebe sich der Schwerpunkt vom Modell allein dahin, wie Agenten zusammengesetzt, eingegrenzt und gesteuert werden.

Cisco überträgt Zero-Trust-Prinzipien auf Agenten. Im Mittelpunkt stehen drei Dimensionen: Identität, Zugriff und Verhalten. Agenten gelten dort als nichtmenschliche Identitäten, die erfasst und einem verantwortlichen Eigentümer zugeordnet werden sollen. Ihr Zugriff soll eng begrenzt, ihr Verhalten laufend überwacht werden.

Visual Studio Code kombiniert mehrere Kontrollen. Änderungen lassen sich vor der Übernahme prüfen, sensible Aktionen brauchen eine Freigabe. Autonomiestufen reichen von der Einzelfreigabe bis zum vollautonomen Betrieb. Hinzu kommen Sandboxing auf Betriebssystemebene und Trust-Boundaries. Auffällig nah liegt das an der AWS-Forderung: Autonomie wird gestaffelt, Freigaben konzentrieren sich auf sensible Fälle, Grenzen werden technisch durchgesetzt.

Ein Beitrag auf builder.aws.com geht in dieselbe Richtung. Prompt-Safety sei nur die erste Verteidigungslinie, heißt es dort. Skizziert wird eine Governance-Kontrollebene mit Kontrollen für Identität, Berechtigungen, Tool-Aufrufe und Laufzeitisolation. Außerdem beschreibt der Beitrag ein Modell, in dem Agenten Autonomie schrittweise durch Evidenz erwerben („Earned Autonomy“). Ob das die offizielle AWS-Position ist oder ein Community-Beitrag, geht aus dem Auszug nicht hervor. Als Beleg dafür, wie „Trust in Depth“ umgesetzt wird, taugt er deshalb nicht.

Nach Materiallage ist „Trust in Depth“ damit eine Weiterentwicklung bekannter Prinzipien wie Defense in Depth, Zero Trust, Least Privilege und Human-in-the-Loop. Einen konkreten neuen Mechanismus lässt das Material nicht erkennen. Neu ist die Rahmung: Vertrauen soll über überprüfbare Grenzen entstehen, nicht über die Freigabe jeder einzelnen Aktion.

Unabhängige Studien sehen überprivilegierte Tools als Hauptrisiko, nicht neue Schwachstellen

Zwei arXiv-Arbeiten stützen eine nüchterne Lesart der Risiken. Beide sind Preprints und stammen nicht von AWS. Eine Analyse zu Agenten in privilegierten Cloud-Umgebungen kommt zu dem Schluss, dass viele Risiken nicht aus neuartigen Schwachstellen entstehen. Als Ursachen nennt sie überprivilegierte Tools, Diskrepanzen zwischen Fähigkeit und Absicht eines Agenten sowie Ambient Authority. Gemeint sind Rechte, die ein Agent allein durch die Umgebung erbt, in der er läuft. Die Autoren stützen sich auf eine Taxonomie, drei Beispielszenarien und ein kleines kontrolliertes Experiment.

Die zweite Arbeit wertet Penetrationstests an proprietären Agentensystemen aus. Die gefundenen Schwachstellen beschreibt sie überwiegend als wiederkehrende Klassen, wie sie aus früheren Computersystemen bekannt sind. Grundsätzlich neu seien sie demnach meist nicht.

Für die AWS-These heißt das: Entsteht das Risiko vor allem aus zu weiten Rechten und fehlender Abgrenzung, passen Begrenzungen über Berechtigungen und Isolation zu den Befunden. Eine Aufsicht, die Aktionen innerhalb fester Grenzen hält, setzt an dieser Ursache an. Über AWS-Kontrollen sagen die Studien nichts, und aus ihnen lässt sich nichts über AWS ableiten. Beide sind zudem Preprints ohne abgeschlossene Begutachtung.

Eine häufig zitierte Zahl ist mit Vorsicht zu lesen. CrowdStrike verweist auf einen SailPoint-Bericht, wonach 80 Prozent der Organisationen unbeabsichtigte Aktionen ihrer KI-Agenten gemeldet hätten. Belegt ist die Zahl nur aus zweiter Hand und im Marketingkontext. Methodik und Stichprobe lassen sich allein am Originalbericht prüfen.

Abwehrschichten gegen Prompt Injection: 8,7 Prozent Erfolgsquote gegen über 85 Prozent

Wie gut technische Schichten gegen Prompt Injection schützen, ist umstritten. Ein Preprint stellt ein mehrschichtiges Abwehrframework vor. Es kombiniert Content-Filterung mit einer auf Einbettungen beruhenden Anomalieerkennung, hierarchische System-Prompt-Leitplanken und eine mehrstufige Antwortprüfung. Nach Angaben der Autoren sinkt die Rate erfolgreicher Angriffe von 73,2 auf 8,7 Prozent. 94,3 Prozent der Basisleistung bleiben erhalten. Getestet wurde mit 847 gegnerischen Testfällen an sieben Sprachmodellen.

Dagegen steht eine Systematisierung der Literatur zu Coding-Assistenten. Sie fasst 78 Studien zusammen. Ihr Ergebnis: Sobald adaptive Angriffsstrategien zum Einsatz kommen, übersteigt die Erfolgsquote gegen moderne Abwehrmaßnahmen 85 Prozent. Von 18 untersuchten Abwehrmechanismen mildern die meisten weniger als 50 Prozent der anspruchsvollen Angriffe ab.

Der Widerspruch erklärt sich nach den Abstracts wahrscheinlich durch unterschiedliche Messungen. Das ist eine Einschätzung und keine Feststellung der Autoren. Die erste Arbeit prüft ein eigenes Framework an einem festen Benchmark für RAG-Agenten, also an statischen Testfällen. Die zweite wertet Literatur zu Angreifern aus, die ihr Vorgehen an die Verteidigung anpassen, und betrachtet Coding-Assistenten, eine andere Systemklasse. Ein Angreifer, der die Abwehr kennt und umgeht, trifft auf andere Bedingungen als ein fester Katalog bekannter Muster.

Beide Quellen sind Preprints und nicht von AWS. Aussagen über AWS-Kontrollen lassen sich daraus nicht ableiten. Für den Maßstab folgt: Technische Schichten allein sind kein Vertrauensbeleg, solange ihre Wirkung je nach Testaufbau zwischen gut 8 und über 85 Prozent Angriffserfolg schwankt. Das stützt eher die Forderung nach überprüfbaren Grenzen, innerhalb derer ein Agent handelt, als dass es sie schwächt. Wer sich nicht auf die Erkennung jedes Angriffs verlassen kann, muss den möglichen Schaden begrenzen.