AWS setzt KI-Agenten harte Grenzen, während sich der Sicherheitswettlauf zwischen Amazon und Google verschärft

AWS hat durchsetzbare Grenzen für KI-Agenten eingeführt, obwohl Angreifer oder manipulierte Daten deren Schlussfolgerungen beeinflussen können. Der Schritt verschärft den Wettbewerb zwischen Amazon und Google darum, welche Cloud Agenten sicher mit wertvollen Unternehmenssystemen verbinden kann.

Amazon Bedrock AgentCore Policy prüft die angeforderten Tool-Aktionen eines Agenten, bevor diese Aktionen den zugrunde liegenden Dienst erreichen. Ein manipulierter Agent kann weiterhin eine gefährliche Anfrage erzeugen, doch sie sollte scheitern, wenn sie mit einer externen Richtlinie kollidiert.

Diese Unterscheidung ist wichtig, weil Prompt-Filter nie eine vollständige Sicherheitsgrenze geboten haben. Modelle verarbeiten Anweisungen und nicht vertrauenswürdige Daten mit derselben probabilistischen Mechanik. AWS behandelt das Modell nun als nicht vertrauenswürdigen Entscheidungsträger statt als letzte Instanz.

Google Cloud und Microsoft verfolgen mit ihren eigenen Identitäts-, Gateway- und Informationsflusskontrollen dieselbe grundsätzliche Richtung. Der sich herausbildende Wettbewerb beschränkt sich nicht mehr auf Modellqualität. Cloud-Anbieter müssen zeigen, dass Agenten handeln können, ohne uneingeschränkten Zugriff auf jedes verbundene System zu erben.

AWS verlagert die Autorisierung aus dem Agenten heraus

AWS trennt, was ein Agent tun möchte, von dem, was die Infrastruktur ihm erlaubt.

Policy in Amazon Bedrock AgentCore schafft eine Schutzgrenze um die Interaktionen zwischen Agenten und Tools. Der Dienst fängt Anfragen ab, die über ein AgentCore Gateway weitergeleitet werden, und bewertet jede Anfrage, bevor er den Tool-Aufruf zulässt.

Ein AgentCore Gateway verbindet Agenten über eine verwaltete Schnittstelle mit APIs, Funktionen und anderen Tools. Die Richtlinien-Engine befindet sich neben dieser Verbindung und nicht im Prompt oder Orchestrierungscode des Agenten.

Diese Platzierung verändert das Sicherheitsmodell. Ein System-Prompt könnte einem Agenten untersagen, eingeschränkte Kundendatensätze abzurufen. Prompt Injection kann das Modell jedoch dazu bringen, diese Anweisung zu ignorieren oder anders auszulegen.

Eine externe Autorisierungs-Engine muss nicht darauf vertrauen, dass das Modell zustimmt. Sie bewertet die vorgeschlagene Aktion anhand expliziter Regeln, einer authentifizierten Identität, Tool-Parametern und des verfügbaren Anfragekontexts.

AWS verwendet Cedar, seine Open-Source-Autorisierungssprache, um diese Regeln auszudrücken. Eine Cedar-Richtlinie identifiziert den Principal, der eine Anfrage stellt, die angeforderte Aktion, die geschützte Ressource und alle erforderlichen Bedingungen.

Der Dienst folgt einer Default-Deny-Semantik. Eine Aktion erhält keinen Zugriff, sofern eine Richtlinie ihn nicht ausdrücklich erlaubt. Ein passendes Verbot setzt zudem jede weiter gefasste Berechtigung außer Kraft, die die Anfrage andernfalls erlauben könnte.

AWS erläutert diese Mechanismen in seinem AgentCore policy guide. Laut dem Leitfaden wird jede weitergeleitete Agentenanfrage bewertet, bevor Tool-Zugriff gewährt wird.

Entwickler können Cedar direkt schreiben oder Anforderungen in einfachem Englisch beschreiben. Der Dienst zur Erstellung in natürlicher Sprache übersetzt diese Anforderungen in vorgeschlagene Cedar-Richtlinien.

AWS erklärt, dass der Dienst generierte Richtlinien anhand des Tool-Schemas des Gateways validiert. Außerdem prüft er auf Regeln, die offenbar zu weitreichend, zu restriktiv oder unmöglich zu erfüllen sind.

Dieser Generierungsprozess macht vage Anforderungen nicht sicher. AWS warnt, dass Richtlinien in natürlicher Sprache weiterhin präzise und eindeutige Formulierungen benötigen. Sicherheitsteams müssen das resultierende Cedar prüfen, statt generierte Richtlinien als unhinterfragbaren Code zu behandeln.

Das Modell, das eine Richtlinie erstellt, ist auch von dem Mechanismus getrennt, der sie durchsetzt. Nach der Bereitstellung steuert die formale Richtlinie die Autorisierungsentscheidung, statt ein weiteres Modell nach seiner Einschätzung zu fragen.

Betrachten wir einen internen Support-Agenten mit Tools zum Lesen von Konten und zur Erstattung von Zahlungen. Ein Unternehmen könnte allen Supportmitarbeitern erlauben, ihnen zugewiesene Konten einzusehen, während nur Vorgesetzte größere Erstattungen genehmigen dürfen.

Enthält eine E-Mail bösartige Anweisungen, die eine Erstattung fordern, könnte der Agent versuchen, die Aktion auszuführen. Das Gateway kann sie dennoch ablehnen, wenn dem authentifizierten Mitarbeiter die erforderliche Rolle fehlt oder der Betrag die Richtlinie überschreitet.

Die abgelehnte Anfrage muss das Zahlungssystem nie erreichen. Dieses Ergebnis ist stärker, als den Agenten zu bitten, jede Variante einer bösartigen Anweisung zu erkennen.

Laut AWS-Veröffentlichungsdokumentation ist AgentCore Policy in 13 AWS-Regionen allgemein verfügbar. Zentralisierte Richtlinien können konsistent auf mehrere Agenten und Tools angewendet werden, die über zugeordnete Gateways verbunden sind.

Die CloudWatch-Integration zeichnet Autorisierungsentscheidungen für Monitoring und Audits auf. Diese Aufzeichnungen geben Sicherheitsteams einen klareren Überblick darüber, welche Aktionen Agenten angefordert haben, zugelassen oder abgelehnt wurden.

Die unmittelbare Veränderung ist daher architektonischer und nicht kosmetischer Natur. AWS setzt einen deterministischen Kontrollpunkt zwischen unsicherem Modellverhalten und folgenreichen Unternehmenssystemen.

Warum Prompt Injection den Wettbewerb zwischen Amazon und Google verändert

Der Cloud-Wettbewerb zwischen Amazon und Google hängt nun davon ab, kompromittierte Agenten einzudämmen, und nicht nur ihre Antworten zu verbessern.

KI-Agenten werden nützlich, wenn sie private Informationen abrufen, APIs aufrufen, Nachrichten versenden oder Datensätze ändern können. Dieselben Berechtigungen bestimmen auch das mögliche Schadensausmaß nach einer Manipulation.

Prompt Injection schleust feindselige Anweisungen in Inhalte ein, die ein Modell verarbeitet. Direkte Injection stammt aus einer Nutzeranfrage, während indirekte Injection in Websites, Dokumenten, E-Mails oder Tool-Antworten verborgen sein kann.

Ein Agent, der einen Lieferanten recherchiert, könnte auf einer Webseite eingebettete Anweisungen vorfinden. Diese Anweisungen könnten ihn auffordern, vertrauliche Dateien abzurufen und sie über ein anderes verbundenes Tool zu versenden.

Ein Inhaltsfilter könnte ein bekanntes Angriffsmuster erkennen. Er könnte jedoch auch eine ungewöhnliche Formulierung, einen codierten Befehl oder eine über mehrere Interaktionen verteilte Sequenz übersehen.

Das zugrunde liegende Problem geht über bösartige Prompts hinaus. Ein Modell kann eine Aktion halluzinieren, eine Geschäftsregel missverstehen oder einzeln akzeptable Tools zu einem unzulässigen Workflow kombinieren.

OWASP bezeichnet diesen Zustand als excessive agency. Das Risiko entsteht, wenn ein LLM genügend Funktionalität oder Berechtigungen erhält, um nach einer unerwarteten Ausgabe schädliche Auswirkungen zu verursachen.

Autorisierung begrenzt den daraus resultierenden Schadensradius. Das System geht davon aus, dass ein Agent irgendwann eine schlechte Entscheidung treffen wird, und verhindert dann, dass diese Entscheidung zu einer uneingeschränkten Aktion wird.

Dieser Ansatz ähnelt etablierten Cloud-Sicherheitspraktiken. Anwendungen sollten nur die für eine Aufgabe erforderlichen Berechtigungen erhalten, während sensible Vorgänge zusätzlichen Prüfungen unterliegen sollten.

Agenten erschweren dieses Prinzip, weil sie Tools dynamisch auswählen. Sie können außerdem viele Aufrufe miteinander verketten, Kontext zwischen Schritten mitführen und länger ohne direkte Aufsicht arbeiten.

Ein statisches Dienstkonto mit weitreichenden Berechtigungen kann daher zu einer ernsthaften Belastung werden. Der Agent erhält faktisch jede Fähigkeit, die mit diesen Zugangsdaten verbunden ist – unabhängig vom jeweiligen Nutzer oder der Aufgabe.

AWS kann AgentCore-Anfragen mit OAuth-Nutzern oder AWS Identity and Access Management-Entitäten verknüpfen. Richtlinien können dann die Identität hinter einer Anfrage berücksichtigen, statt sich nur auf die gemeinsame Dienstrolle des Agenten zu verlassen.

Google steht vor demselben Problem, da es Gemini-basierte Agenten und Model Context Protocol-Verbindungen ausbaut. MCP ist eine Standardschnittstelle, über die Modelle externe Tools entdecken und aufrufen können.

Googles MCP security guidance empfiehlt Deny-Richtlinien für den Produktionszugriff, eng abgegrenzte Berechtigungen, Eingabebereinigung und Monitoring. Sie warnt zudem, dass die Sicherheit andernfalls vollständig von der Programmierung des Agenten abhängen kann.

Diese Konvergenz ist bedeutsam. Der Wettbewerb zwischen Amazon und Google drehte sich häufig um Modellverfügbarkeit, Infrastruktur, Datenplattformen und Entwickler-Tools. Die Autorisierung von Agenten entwickelt sich zu einem weiteren wichtigen Kaufkriterium.

Unternehmenskunden setzen einen Agenten selten als isolierten Chatbot ein. Sie möchten Agenten mit Datenbanken, Code-Repositories, Support-Plattformen, Cloud-Konsolen und internen Wissensspeichern verbinden.

Jede Verbindung schafft sowohl Nutzen als auch Angriffsfläche. Ein Cloud-Anbieter, der die Verbindung erleichtert, aber die Autorisierung schwach gestaltet, verlagert das Betriebsrisiko zurück auf den Kunden.

AWS positioniert AgentCore Policy als wiederverwendbare Durchsetzungsebene über Frameworks und Modelle hinweg. Entwickler können AgentCore mit Agenten verwenden, die über mehrere gängige Orchestrierungs-Frameworks erstellt wurden.

Diese Offenheit ermöglicht AWS das Argument, dass Sicherheitsrichtlinien stabil bleiben sollten, selbst wenn ein Unternehmen sein Modell wechselt. Eine Organisation könnte ein Foundation Model ersetzen, ohne jede Berechtigungsregel neu schreiben zu müssen.

Google kann mit seinen Cloud-Identitätskontrollen, Model Armor und ressourcenbezogenen Berechtigungen ähnlich argumentieren. Sein Vorteil liegt in der Nähe zu Google Workspace, Gemini und einer umfangreichen Datenplattform.

Microsoft erhöht den Druck durch Entra Identity, Copilot und seinen Stack für die Agentenentwicklung. Der Markt entwickelt sich zu einem Dreikampf darum, wer die Grenze zwischen KI-Schlussfolgerungen und Unternehmensausführung kontrolliert.

Für Käufer lautet die relevante Frage zwischen Amazon und Google nicht, welches Modell einen bösartigen Prompt immer ablehnt. Kein Anbieter kann glaubwürdig perfekte Ablehnung bei jeder Eingabe- und Tool-Kombination versprechen.

Die bessere Frage ist, was passiert, nachdem die Ablehnung versagt. Eine sichere Plattform sollte die Tools, Datensätze, Parameter, Ziele und Aktionssequenzen begrenzen, die dem kompromittierten Agenten zur Verfügung stehen.

Sicherheitsstrategien von Amazon und Google treffen an der Tool-Grenze aufeinander

AWS, Google und Microsoft konvergieren bei deterministischer Durchsetzung, organisieren diese aber unterschiedlich.

AWS platziert AgentCore Policy direkt im Gateway-Pfad. Jede abgedeckte Anfrage eines Agenten an ein Tool erreicht die Richtlinien-Engine, bevor der angeforderte Aufruf fortgesetzt wird.

Cedar bietet AWS eine formale Sprache, die Teams prüfen, validieren und analysieren können. AWS hat Cedar-Konzepte auch über Agenten hinaus verwendet, was dabei hilft, die Agentenautorisierung mit etablierten Praktiken der Anwendungssicherheit zu verbinden.

Die Sicherheitsforscher des Unternehmens treffen über das Modell selbst eine unverblümte Annahme. Ihre Cedar security analysis besagt, dass Organisationen ein LLM innerhalb eines Defense-in-Depth-Designs als nicht vertrauenswürdigen Akteur behandeln sollten.

Das bedeutet nicht, dass das Modell bösartig ist. Es bedeutet, dass das Autorisierungssystem nicht von vorhersehbarem Modellverhalten abhängen kann, weil das Modell probabilistisch ist und für manipulierten Kontext anfällig bleibt.

Googles veröffentlichte Leitlinien legen derzeit den Schwerpunkt auf mehrschichtige Kontrollen rund um MCP-Server und Google Cloud-Ressourcen. Zu diesen Kontrollen gehören Deny-Richtlinien, eng begrenzte Zugangsdaten, getrennte Testumgebungen, bereinigte Eingaben und eingeschränkter Produktionszugriff.

Google empfiehlt außerdem, Lese- und Schreib-Tools davon abzuhalten, Produktionsressourcen zu erreichen, sofern der Workflow sie nicht benötigt. Wiederherstellungsfunktionen bleiben wichtig, da selbst eine autorisierte Aktion zu einem unerwünschten Ergebnis führen kann.

Der praktische Unterschied kann sich in der Entwicklererfahrung zeigen. AWS bietet eine dedizierte AgentCore-Richtlinien-Engine mit Cedar-basierter Auswertung an seinem verwalteten Gateway.

Google kann auf ausgereifte Cloud IAM- und produktspezifische Richtlinien zurückgreifen. Entwickler müssen jedoch weiterhin sicherstellen, dass jeder relevante Tool-Pfad tatsächlich die vorgesehene Kontrolle durchläuft.

Diese Einschränkung gilt auch für AWS. AgentCore Policy steuert den Datenverkehr, der über ein zugeordnetes AgentCore Gateway geleitet wird. Ein Agent mit einem anderen Ausführungspfad könnte diesen speziellen Kontrollpunkt umgehen.

Beispielsweise könnte eine Richtlinie eine S3-Operation über ein verwaltetes MCP-Tool blockieren. Die Einschränkung würde jedoch nicht automatisch ein separates Shell-Tool abdecken, das einen gleichwertigen Befehl ausführen kann.

Architekturprüfungen müssen deshalb Fähigkeiten erfassen, nicht nur benannte Tools. Sicherheitsteams müssen fragen, ob ein Agent dieselbe Ressource über ein SDK, die Befehlszeile, einen Browser, eine Funktion oder einen sekundären Agenten erreichen kann.

Microsoft entwickelt mit der Kontrolle von Informationsflüssen eine weitere Variante. Die FIDES-Middleware kennzeichnet Inhalte nach Integrität und Vertraulichkeit und überträgt diese Kennzeichnungen anschließend durch Tool-Aufrufe.

Microsofts FIDES-Sicherheitsmodell kann verhindern, dass nicht vertrauenswürdige Inhalte eine sensible Operation beeinflussen. Es kann außerdem einschränken, dass private Daten in Richtung eines öffentlichen Ziels fließen.

Dieser Ansatz adressiert eine Schwachstelle der Autorisierung einzelner Aktionen. Eine Datenbankabfrage kann erlaubt sein, ebenso das Versenden einer E-Mail. Das gefährliche Verhalten entsteht, wenn private Abfrageergebnisse in eine externe E-Mail fließen.

AWS erweitert seine Richtlinien in Richtung sitzungsbewusster Auswertung. Zeitliche Kontrollen können die jüngsten Aktionen eines Agenten prüfen, statt jede Anfrage als isoliertes Ereignis zu beurteilen.

Diese Richtung ist wichtig, weil Angreifer ein schädliches Ziel auf mehrere legitim wirkende Schritte verteilen können. Eine Abfolge kann Risiken offenlegen, die keine einzelne Aktion erkennen lässt.

Ein Agent könnte zunächst ein vertrauliches Portfolio lesen, dann eine Zusammenfassung berechnen und schließlich eine externe Übermittlung versuchen. Jeder Tool-Aufruf kann gültig erscheinen, ohne dass der Verlauf sie miteinander verknüpft.

Für Kunden, die Sicherheitskonzepte von Amazon und Google vergleichen, ist die Abdeckung wichtiger als die Terminologie. Eine formale Richtliniensprache bietet wenig Schutz, wenn Ausführungspfade mit hohem Risiko außerhalb der Durchsetzung bleiben.

Auch die Weitergabe von Identitäten ist wichtig. Die Richtlinien-Engine benötigt verlässliche Informationen über Nutzer, Workload, Ressource, Aktion und relevanten Geschäftskontext.

Eine allgemeine „Agent“-Identität reicht nicht aus, wenn der Agent vielen Mitarbeitenden dient. Sie kann jedem Nutzer den maximalen Berechtigungssatz des Agenten gewähren und die Nachvollziehbarkeit aufheben, die normale Zugriffskontrollen ermöglichen.

Organisationen sollten die menschliche oder Workload-Identität hinter jeder delegierten Anfrage beibehalten. Sie sollten dem Agenten außerdem eine eigene, eingeschränkte Identität zuweisen, statt ihn in einer gemeinsamen Berechtigung zu verbergen.

Diese Trennung hilft bei der Beantwortung zweier unterschiedlicher Fragen. Die erste lautet, ob der Nutzer die Aktion anfordern darf. Die zweite lautet, ob dieser Agent die Aktion über dieses spezielle Tool ausführen darf.

Eine zentrale Richtlinie reduziert zudem Inkonsistenzen zwischen Teams. Ohne sie kann jeder Entwickler Autorisierung in Prompts, benutzerdefinierter Middleware oder einzelnen Tool-Handlern implementieren.

Diese verstreuten Prüfungen werden schwer auditierbar. Sie driften auch, wenn Agenten neue Tools, Modelle und Workflow-Zweige erhalten.

Ein gemeinsames Gateway kann nicht jede Berechtigung auf Ressourcenebene ersetzen. Es kann einen konsistenten Punkt bieten, an dem Organisationen Richtlinien anwenden, bevor die Absicht des Agenten nachgelagerte Dienste erreicht.

Die Richtlinie ist nur so stark wie ihre Abdeckung

AgentCore Policy reduziert Risiken, beweist jedoch nicht, dass ein auf AWS gehosteter Agent sicher ist.

Der Dienst kontrolliert Anfragen, die seine konfigurierte Gateway- und Richtlinien-Engine durchlaufen. Er kann keine Tools, Berechtigungen oder Netzwerkpfade steuern, die Entwickler außerhalb dieser Grenze belassen.

Dadurch entsteht ein Abdeckungsproblem. Ein Sicherheitsteam könnte glauben, eine gefährliche Aktion blockiert zu haben, während ein alternatives Tool einen weiteren Weg zu derselben Ressource bietet.

Weitreichende IAM-Berechtigungen können diese Lücke verschärfen. Wenn die Laufzeitrolle eines Agenten Dienste direkt aufrufen kann, müssen Gateway-Einschränkungen mit Ressourcenrichtlinien kombiniert werden, die nicht autorisierte Pfade blockieren.

Auch das Entwerfen von Richtlinien bleibt schwierig. Das Verfassen in natürlicher Sprache senkt die syntaktische Hürde, löst jedoch weder vage Geschäftsanforderungen noch fehlende Sicherheitsannahmen.

„Analysten dürfen geeignete Berichte einsehen“ ist keine präzise Autorisierungsregel. Die Organisation muss definieren, welche Analysten, Berichte, Klassifizierungen, Regionen, Kunden und Betriebsbedingungen als geeignet gelten.

Generierter Cedar-Code erfordert Prüfung, Tests und Änderungskontrolle. Teams sollten erwartete Genehmigungen, erwartete Ablehnungen, fehlerhafte Anfragen, fehlenden Kontext und absichtlich adversariale Parameterkombinationen testen.

Eine Richtlinie, die alles verweigert, verursacht Betriebsstörungen. Eine Regel, die stillschweigend alles erlaubt, schafft das gegenteilige Problem. Beide Ergebnisse können syntaktisch gültig erscheinen.

Entwickler müssen auch den vom Agenten bereitgestellten Autorisierungskontext berücksichtigen. Sicherheitsrelevante Attribute sollten aus vertrauenswürdigen Identitätstokens, Ressourcenmetadaten oder kontrollierter Infrastruktur stammen.

Dem Modell sollte nicht erlaubt werden zu erklären, dass eine Transaktion risikoarm oder ein Dokument öffentlich ist. Diese Behauptungen müssen außerhalb des Schlussfolgerungsprozesses des Modells überprüft werden.

Audit-Protokolle bringen eine weitere Verpflichtung mit sich. Jede Entscheidung aufzuzeichnen hilft bei Untersuchungen, doch Teams müssen die Aufzeichnungen aktiv überwachen und nützlichen Kontext bewahren.

Eine abgelehnte Aktion kann auf eine erfolgreiche Sicherheitskontrolle hindeuten. Wiederholte Ablehnungen können jedoch auch einen kompromittierten Workflow, einen Richtlinienfehler oder einen Agenten offenlegen, der fortlaufend ein verbotenes Ziel erneut versucht.

Auch erlaubte Aktionen verdienen Aufmerksamkeit. Ein Angreifer kann Berechtigungen missbrauchen, die einzeln betrachtet legitim sind, insbesondere wenn Richtlinien weder Sitzungshistorie noch Datenbewegungen berücksichtigen.

Menschliche Genehmigungen bleiben für irreversible oder folgenschwere Operationen nützlich. Ein Genehmigungsbildschirm kann jedoch versagen, wenn der Agent eine irreführende Beschreibung der angeforderten Aktion liefert.

Die Oberfläche sollte vertrauenswürdige Details aus der tatsächlichen Tool-Anfrage anzeigen. Prüfer benötigen Ziel, Ressource, Parameter, Datenklassifizierung und erwartete Wirkung.

Sicherheitsteams müssen auch die Ebene zur Verwaltung von Richtlinien absichern. Ein Agent sollte nicht in der Lage sein, seine eigenen Regeln zu bearbeiten, eine schwächere Richtlinien-Engine zuzuordnen oder Berechtigungen mit weiterem Zugriff zu erhalten.

Aufgabentrennung hilft hier. Entwickler können Richtlinienänderungen vorschlagen, während Sicherheitsverantwortliche Änderungen über kontrollierte Workflows prüfen und bereitstellen.

Dieselbe Disziplin gilt für interne Wissenssysteme. Teams, die eine durchsuchbare Wissensdatenbank aufbauen, sollten Dokumentberechtigungen bewahren, bevor sie diese Inhalte einem Agenten zugänglich machen.

Die Suche sollte Datensätze entsprechend der Autorisierung des anfragenden Nutzers filtern. Das Modell sollte nur die Teilmenge der Informationen erhalten, auf die der Nutzer auch direkt zugreifen könnte.

Dieses Design verhindert einen kritischen Fehlermodus. Selbst ein erfolgreich manipulieres Modell kann keine Informationen offenlegen, die nie in seinen zugänglichen Kontext gelangt sind.

Organisationen sollten nicht ihr gesamtes Vertrauen in die Erkennung von Prompt-Injection setzen. Erkennung bietet eine nützliche Schutzebene, doch unbekannte Angriffe und harmlos wirkende Anweisungen können Klassifikatoren umgehen.

AWS unterstützt Bedrock Guardrails auf der Richtlinienebene zur Bewertung von Gateway-Eingaben und -Ausgaben. Diese Funktion ergänzt die Cedar-Durchsetzung, statt sie zu ersetzen.

Der Unterschied ist einfach. Ein Guardrail schätzt ein, ob Inhalte gefährlich wirken, während die Autorisierung entscheidet, ob eine angeforderte Operation erlaubt ist.

Probabilistische Erkennung und deterministische Durchsetzung lösen unterschiedliche Probleme. Ihre Kombination verkleinert die Angriffsfläche, ohne vorzutäuschen, dass eine der Ebenen jeden Fehler abfängt.

Das Sicherheitsrennen zwischen Amazon und Google wird Anbieter belohnen, die diese Ebenen schwer umgehbar machen. Marketingaussagen über sichere Agenten sind weniger wichtig als nachweisbare Durchsetzungsabdeckung.

Kunden sollten diese Behauptungen mit Red-Team-Übungen testen, die indirekte Injection, kompromittierte Tools, alternative Ausführungspfade und mehrstufige Datenbewegungen umfassen.

Sie sollten auch das Verhalten bei Fehlern überprüfen. Ein abgelehnter Tool-Aufruf muss die geschützte Operation stoppen, ohne sensible Details über Fehler oder Ausweichpfade preiszugeben.

AWS hat ein stärkeres Standardmuster etabliert, indem Richtlinien außerhalb des Agenten-Codes platziert werden. Die verbleibende Frage ist, ob Kunden die umgebenden Identitäten und Pfade mit derselben Sorgfalt konfigurieren werden.

Worauf Unternehmenskäufer als Nächstes achten sollten

Die nächste Phase wird Richtlinienabdeckung, Sitzungsbewusstsein und Portabilität über konkurrierende Agentenplattformen hinweg auf die Probe stellen.

Das erste Signal ist, wie schnell Kunden zeitliche Richtlinien übernehmen. Regeln für einzelne Anfragen funktionieren gut bei klaren Einschränkungen, doch viele Agentenangriffe entstehen durch Abfolgen autorisierter Aktionen.

Zeitliche Auswertung kann erkennen, dass ein Agent sensible Daten gelesen hat, bevor er eine externe Übertragung versucht. Sie kann nach einer bestimmten Abfolge von Operationen auch zusätzliche Genehmigung verlangen.

Der schwierige Teil betrifft Zustand und Interpretation. Systeme müssen ausreichend Historie verfolgen, um gefährliche Verläufe zu erkennen, ohne gewöhnliche Workflows zu blockieren oder übermäßige Latenz hinzuzufügen.

Käufer sollten nach öffentlicher technischer Dokumentation suchen, die genau beschreibt, wie viel Sitzungshistorie ausgewertet wird. Sie sollten außerdem fragen, wie Zustand zwischen Nutzern, Agenten und parallelen Aufgaben isoliert wird.

Das zweite Signal ist, wie Google und Microsoft gleichwertige Kontrollen über ihre verwalteten Agentenplattformen bereitstellen. Alle drei Anbieter erkennen an, dass Prompt-Anweisungen allein verbundene Systeme nicht schützen können.

Googles Reaktion wird wichtig sein, weil Gemini-Agenten nah an Workspace-Inhalten, Cloud-Daten und Entwickler-Infrastruktur arbeiten können. Starke Ressourcenberechtigungen existieren bereits, doch eine agentenspezifische Zusammensetzung bleibt entscheidend.

Microsoft kann Entra-Identität mit Copilot, Agent Framework und Informationsfluss-Kennzeichnungen kombinieren. Sein Vorteil wird von einer konsistenten Durchsetzung über Microsoft- und Drittanbieter-Tools hinweg abhängen.

Der Vergleich zwischen Amazon und Google sollte sich auf End-to-End-Pfade konzentrieren. Käufer benötigen Nachweise dafür, dass eine Richtlinie einer Aktion von der Nutzeridentität über das Schlussfolgern des Agenten und die Gateway-Ausführung bis zum finalen Ressourcenzugriff folgt.

Das dritte Signal sind unabhängige Sicherheitstests. Anbieter-Dokumentation beschreibt das beabsichtigte Verhalten, während Red Teams fehlende Pfade, verwechselte Identitäten, unsichere Standardwerte und unerwartete Tool-Kombinationen aufdecken.

Tests sollten eine bösartige Webseite, ein manipuliertes Support-Ticket, eine kompromittierte MCP-Antwort und ein feindseliges Dokument in einem genehmigten Repository umfassen. Jede Quelle kann indirekte Anweisungen in den Kontext eines Agenten tragen.

Forscher sollten außerdem prüfen, ob Agenten verbotene Anfragen in technisch andere Aktionen umwandeln können. Ein blockierter Export könnte zu einem Browser-Upload, Shell-Befehl, kodierten Nachricht oder einer Anfrage an einen anderen Agenten werden.

Die Ergebnisse werden bestimmen, ob externe Richtlinien eine sinnvolle Eindämmung oder nur eine weitere Konfigurationsebene schaffen. Die stärksten Belege werden aus Angriffen stammen, die das Verhalten des Modells verändern, aber dennoch die Autorisierungsgrenzen nicht überschreiten.

Unternehmen müssen nicht auf diese Ergebnisse warten, bevor sie ihre Architektur verbessern. Sie können beginnen, indem sie jeden Agenten, jedes Tool, jede Berechtigung, jede Datenquelle und jedes externe Ziel inventarisieren.

Jedes Tool sollte den engstmöglichen Aktionsumfang erhalten. Schreibgeschützter Zugriff sollte von Änderungen, Löschungen, externer Freigabe oder finanzieller Ausführung getrennt bleiben.

Teams sollten dauerhafte Berechtigungen entfernen, wenn kurzlebige Delegation ausreicht. Sie sollten die Nutzeridentität über Tool-Aufrufe hinweg bewahren und sowohl versuchte als auch abgeschlossene Operationen protokollieren.

Folgenreiche Aktionen sollten vertrauenswürdigen Genehmigungskontext erfordern. Sicherheitsteams sollten regelmäßig alternative Wege zu geschützten Ressourcen testen, statt nur die vorgesehene Gateway-Route zu validieren.

Bei der Entscheidung zwischen Amazon und Google Cloud reichen Modell-Benchmarks nicht mehr aus. Käufer sollten Default-Deny-Verhalten, Identitätsweitergabe, Richtlinienanalyse, Audit-Detailtiefe, Sitzungssteuerungen und Durchsetzungsabdeckung vergleichen.

Sie sollten auch fragen, wie Richtlinien Modell- und Framework-Änderungen überstehen. Eine Autorisierung, die eng an eine bestimmte Agentenimplementierung gebunden ist, wird während Migrationen teuer in der Wartung und leichter zu umgehen.

AWS hat eine klare architektonische Wette abgeschlossen. Das Unternehmen geht davon aus, dass sich die Schlussfolgerungen von Agenten weiterhin beeinflussen lassen, und begrenzt dann die Folgen durch deterministische Kontrollen außerhalb des Agenten.

Diese Annahme ist glaubwürdiger als das Versprechen perfekter Modellbefolgung. Sie akzeptiert, dass Fehler und Angriffe auftreten werden, bewahrt jedoch eine separate Autorität über Tools und Daten.

Der Ansatz hängt weiterhin von einer disziplinierten Konfiguration ab. Eine eng gefasste Gateway-Richtlinie kann weder eine überprivilegierte Laufzeitumgebung noch eine nicht verwaltete Shell oder Daten kompensieren, die vor der Autorisierungsfilterung abgerufen wurden.

Unternehmensteams sollten jetzt einen konkreten Workflow Ende zu Ende testen. Manipulieren Sie den Agenten, beobachten Sie seine angeforderten Aktionen und bestätigen Sie, dass geschützte Vorgänge an einer externen Grenze scheitern.

Dieser Test liefert einen praktischen Maßstab für Amazon Google und jede andere Agentenplattform: Das Modell kann getäuscht werden, aber die Infrastruktur muss weiterhin Nein sagen.