AWS hat Amazon Bedrock AgentCore Memory um eine differenzierte Zugriffskontrolle erweitert und bietet Entwicklern damit eine verwaltete Möglichkeit, den Agentenspeicher nach Benutzer oder Mandant über AgentCore Gateway zu isolieren. Die Veröffentlichung vom 28. August verschiebt einen sensiblen Teil des Agentendesigns in die Infrastrukturrichtlinie: Wer kann den Speicher lesen, schreiben, abrufen oder ändern, den ein KI-Agent sitzungsübergreifend verwendet?

Die Funktion verwendet laut AWS OAuth-JWT-Authentifizierung und Cedar-Richtlinien. Ein verwalteter Speicher-Connector stellt 12 Speichervorgänge als Cedar-Aktionen bereit, sodass Teams Zugriffsregeln für Speichervorgänge ausdrücken können, anstatt sich nur auf Anwendungscode zu verlassen, um Datensätze vor oder nach jedem Aufruf zu filtern.

Das hört sich vielleicht wie eine kleine Autorisierungsaktualisierung an. Das ist es nicht. Persistenter Speicher ist einer der Hauptunterschiede zwischen einer einfachen Chat-Oberfläche und einem Agentenprodukt mit langer Laufzeit. Sobald sich Agenten an Benutzereinstellungen, Kontokontext, Projektverlauf, frühere Entscheidungen, Supportfälle oder den Status von Geschäftsprozessen erinnern, wird der Speicher zu einer Sicherheitsgrenze. AWS geht jetzt damit um.

Was sich geändert hat

Amazon Bedrock AgentCore Memory ist Teil des Agent-Infrastruktur-Stacks von AWS. Es soll Agenten dabei helfen, Kontext über Interaktionen hinweg zu speichern und abzurufen, anstatt jedes Anwendungsteam zu zwingen, seine eigene Speicherschicht von Grund auf neu aufzubauen.

Mit der neuen Zugriffskontrollfunktion können Entwickler die Isolation pro Benutzer und pro Mandant durch AgentCore Gateway erzwingen. Laut AWS funktioniert die Funktion mit der OAuth-JWT-Authentifizierung und Cedar, der Richtliniensprache, die auch in anderen AWS-Autorisierungssystemen verwendet wird. Die AgentCore-Dokumentation beschreibt die Richtlinie in AgentCore als einen Cedar-basierten Mechanismus zur Steuerung des Zugriffs auf Gateway-Tools.

Die praktische Änderung besteht darin, dass die Speicherautorisierung jetzt näher an der Gateway- und Tool-Ebene angesiedelt werden kann. Anstatt benutzerdefinierte Prüfungen für jeden Speicheraufruf innerhalb der Anwendung zu schreiben, können Teams Richtlinien definieren, die regeln, welcher Aufrufer welche Speicheraktion in welchem ​​Namespace oder Mandantenkontext ausführen kann.

Für mandantenfähige Software ist das eine bedeutende Architekturänderung. Ein KI-Assistent für eine Anwaltskanzlei, eine Agentur, ein Supportteam oder eine Unternehmensabteilung kann viele Benutzer über denselben Agentencode bedienen. Der gefährliche Fehlermodus besteht nicht nur darin, dass das Modell eine schlechte Antwort gibt. Es liegt daran, dass der Speicher eines Mandanten in die Sitzung eines anderen Mandanten abgerufen wird oder dass ein Agent einen sensiblen Zustand in den falschen Bereich schreibt. Eine differenzierte Richtliniendurchsetzung zielt darauf ab, diese Fehlerklasse zu reduzieren.

Warum die Speicherisolation jetzt wichtig ist

Der Agentenspeicher stellt ein neues Persistenzproblem für KI-Plattformen dar. Prompt-Protokolle, abgerufene Dokumente, Tool-Ausgaben, Benutzereinstellungen und Workflow-Status können alle Teil zukünftiger Überlegungen werden. Das macht den Speicher nützlich, macht es aber auch schwieriger, über Datengrenzen nachzudenken.

Traditionelle API-Autorisierung konzentriert sich normalerweise auf eine Anfrage: Kann dieser Aufrufer jetzt auf diese Ressource zugreifen? Das Agentengedächtnis dehnt die Frage über die Zeit aus. Ein während einer Sitzung gespeicherter Datensatz kann Wochen später durch einen anderen Tool-Aufruf, ein anderes Modell oder eine andere Version des Agenten abgerufen werden. Wenn die Plattform keinen Identitäts- und Autorisierungskontext in diese Speicheroperationen überträgt, kann die Speicherschicht zu einer stillen Quelle für benutzerübergreifende Leckagen werden.

AWSs Verwendung von Cedar ist auch deshalb von Bedeutung, weil es auf Richtlinien als Infrastruktur für Agentensysteme hinweist. Agentenentwickler benötigen zunehmend Kontrollen, die Tools, Speicher, Ausführungsumgebungen, API-Schlüssel und Prüfprotokolle abdecken. Die Platzierung dieser Kontrollen in einer Gateway-Ebene gibt Plattformteams die Möglichkeit, Richtlinien konsistent durchzusetzen, selbst wenn Anwendungsteams mit verschiedenen Modellen oder Agent-Frameworks experimentieren.

Dies ist direkt relevant für das KI-API-Gateway-Design. Ein Gateway, das nur Eingabeaufforderungen an Modelle weiterleitet, reicht für ernsthafte Agentenbereitstellungen nicht mehr aus. Die Steuerungsebene muss Identitäten, Mandanten, Tools, Speicherbereiche, Ratenbeschränkungen und Prüfpfade verstehen. Model Gate und ähnliche Plattformen gehen in die gleiche Richtung: Ein einheitlicher Zugriff ist nur dann sinnvoll, wenn er mit durchsetzbaren Grenzen verbunden ist.

Wer ist betroffen?

Die unmittelbare Zielgruppe sind AWS-Kunden, die Agenten auf Bedrock AgentCore erstellen, insbesondere Teams, die an SaaS-Produkten, internen Unternehmensassistenten, Automatisierung des Kundensupports, Rechercheagenten und Workflows für Partner arbeiten. Jedes Produkt, das mehrere Organisationen oder Teams über eine gemeinsame Infrastruktur bedient, muss dieselbe Frage beantworten: Woher weiß der Agent, welchen Speicher er verwenden darf?

Entwickler können davon profitieren, weil sie sich auf verwaltete Richtlinienprüfungen verlassen können, anstatt die Autorisierungslogik über den Anwendungscode zu verteilen. Dadurch entfällt zwar nicht die Notwendigkeit eines sorgfältigen Designs, aber es kann die Anzahl der Stellen verringern, an denen durch einen Fehler falsche Daten offengelegt werden können.

Auch Sicherheits- und Plattformteams sind betroffen.Der Agentenspeicher muss nun wie eine Datenbank, ein Dokumentenindex oder ein Geheimspeicher überprüft werden. Das Zugriffsmodell sollte explizit sein. Der Prüfpfad sollte zeigen, welche Identität auf welchen Speichervorgang zugegriffen hat. Die Mandantenisolierung sollte direkt getestet und nicht aus dem Anwendungsrouting abgeleitet werden.

Für Unternehmen, die Agentensysteme kaufen oder aufbauen, erhöht die Version die Grundlage für Anbieterfragen. Es reicht nicht mehr aus zu fragen, ob ein Assistent ein Gedächtnis hat. Käufer sollten sich fragen, wie der Speicher aufgeteilt wird, ob die Autorisierung außerhalb des Modells erzwungen wird, wie Richtlinien aktualisiert werden und wie der Speicherzugriff in Protokollen angezeigt wird.

Praktische Konsequenzen für Entwickler

Die offensichtlichste Konsequenz ist architektonischer Natur. Teams, die langlebige Agenten entwickeln, sollten das Routing der Modellfunktionen von den Ausführungs- und Speicherberechtigungen trennen. Einem leistungsstarken Modell kann es gestattet sein, über eine Aufgabe nachzudenken, aber das bedeutet nicht, dass jeder Tool-Aufruf oder jede Speichersuche breiten Zugriff erben sollte.

Zweitens sollten Gateways und Agent-Plattformen Speicheroperationen als erstklassige Ereignisse behandeln. Lese-, Schreib-, Such-, Lösch- und Aktualisierungsvorgänge weisen unterschiedliche Risikoprofile auf. Nutzungsanalysen sollten sich nicht auf die Anzahl der Token beschränken. Für Agenten-Workloads müssen Analysen zunehmend die Toolnutzung, den Speicherzugriff, den Mandantenumfang, die Benutzeridentität und die Richtlinienergebnisse anzeigen.

Drittens sollten mandantenfähige Produkte vermeiden, sich auf sofortige Anweisungen zur Durchsetzung der Datentrennung zu verlassen. Ein Modell kann angewiesen werden, den Kontext eines anderen Kunden nicht abzurufen, es muss jedoch eine dauerhafte Isolierung unterhalb des Modells erzwungen werden. Das bedeutet begrenzte Anmeldeinformationen, Gateway-Richtlinien, Namespace-Design und Tests, die nachweisen, dass der mandantenübergreifende Zugriff fehlschlägt.

Abschließend sollten Partner- und Reseller-Plattformen darauf achten. Wenn eine KI-API für Agenturen oder eine Partner-API-Automatisierungsebene es nachgelagerten Kunden ermöglicht, Agenten zu erstellen, wird die Speicherverwaltung Teil des Produktvertrags. Die Plattform muss den Partnern genügend Flexibilität bieten, um nützliche Automatisierungen zu erstellen, ohne dass sie unsichtbare Datenaustauschpfade zwischen Clients erstellen müssen.

Was ungewiss bleibt

AWS hat das Steuerungsmodell und seine Verwendung von OAuth-JWTs, Cedar-Richtlinien, AgentCore Gateway und verwalteten Speicheroperationen beschrieben. Was aus der öffentlichen Ankündigung weniger klar hervorgeht, ist, wie Teams diese Richtlinien in komplexen Produktionsbereitstellungen entwerfen werden, wie einfach das Debuggen von Richtlinien sein wird und wie viele Betriebsdetails Kunden standardmäßig in Protokollen erhalten.

Die breitere Richtung ist jedoch klar. Der Agentenspeicher wird zur Infrastruktur. Dabei müssen Autorisierung, Beobachtbarkeit und Abrechnung bis in die Gateway-Schicht folgen. Die Unternehmen, die zuverlässige Agentenplattformen entwickeln, werden diejenigen sein, die Modellzugriff, Toolberechtigungen und Speicherstatus an einem Ort sichtbar und steuerbar machen können.