KI SpotlightNewsAWS beschreibt Session Endpoints für AgentCore Runtime: Agent-Web-Apps im eigenen Browser
Jede Session erhält laut AWS eine authentifizierte URL, über die sich eine in der microVM laufende App öffnen lässt. Die Zuordnung von Sessions zu Nutzern bleibt Aufgabe der Kunden.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- AgentCore Runtime führt jede Agent-Session in einer eigenen isolierten microVM aus.
- Session Endpoints öffnen eine laufende App per authentifizierter URL aus dem eigenen Browser.
- Jede microVM hat isolierte CPU, Speicher und Dateisystem; nach Sessionende wird sie beendet.
- AgentCore Runtime ist framework-agnostisch, modellunabhängig und unterstützt MCP und A2A.
- AgentCore erzwingt keine Zuordnung von Sessions zu Nutzern; das Backend des Kunden muss sie selbst umsetzen.
Session-URL leitet Browser-Anfragen in die microVM des Agents
AWS beschreibt in einem Blogpost die Funktion „Session Endpoints“ für Amazon Bedrock AgentCore Runtime. Jede Session erhält laut Unternehmen eine authentifizierte URL. Sie reicht HTTP-Methode, Pfad, Query-String und Body einer Anfrage weiter, dazu WebSocket-Verbindungen auf den erlaubten Ports. Eine App, die in der Session des Agents läuft, lässt sich so aus dem eigenen Browser öffnen.
Hintergrund ist die Ausführungsumgebung. Runtime führt jede Session nach AWS-Angaben in einer eigenen, isolierten microVM aus, mit getrennter CPU, eigenem Speicher und eigenem Dateisystem. Nach Ende der Session wird die microVM beendet und der Speicher bereinigt. Dabei handelt es sich um die Beschreibung des Herstellers. Eine unabhängige Prüfung liegt nicht vor.
Vite-Beispiel: Dunkles Farbschema erscheint ohne Refresh
Das Beispiel des Blogposts stellt einen Coding-Agent bereit, der in seiner Session eine Vite-Website betreibt. Eine lokale Seite zeigt links den Chat und rechts die Live-Website. Bittet man den Agent um ein dunkles Farbschema, verfolgt man seine Schritte im Chat. Die Website ändert sich, ohne dass man neu lädt.
AWS nennt das die schnellste Review-Schleife: Änderungen erscheinen „within seconds“ im Browser. Ein externes Deployment würde jede Änderung verzögern. Auch das ist eine Herstellerangabe. Eine unabhängige Messung der Latenz gibt es nicht.
Zuordnung von Sessions und Rollenrechte bleiben Sache der Kunden
Die AWS-Dokumentation zu Sicherheitspraktiken weist einige Aufgaben ausdrücklich den Kunden zu. AgentCore erzwingt keine Zuordnung von Sessions zu Nutzern. Das Backend des Kunden muss diese Beziehung führen und das Lifecycle-Management umsetzen, etwa eine maximale Zahl von Sessions pro Nutzer.
Zudem kann Code in der microVM über den Metadata-Endpoint (MMDS) auf die Credentials der Execution Role zugreifen. AWS empfiehlt deshalb, die Rolle eng zu fassen. Bei persistenten Dateisystemen werden Berechtigungen zwar gespeichert, innerhalb der Session aber nicht durchgesetzt. Der Agent ist dort der einzige Nutzer.
Die Release Notes vom Oktober nennen Session-Context-Keys, die den Zugriff pro Session oder Runtime einschränken. Sie gelten nur für Plattformversion V2. Laut AWS umfasst das Sicherheitsmodell von AgentCore unter anderem Firecracker-microVMs, eine IAM-Rolle und Inbound-OAuth mit JWT-Authorizer. Wie diese Mechanismen die Vorschau-URL im Einzelnen absichern, geht aus dem vorliegenden Material nicht hervor.
E2B und sandboxd bieten bereits Port-Zugriff und Preview-URLs
Ähnliche Ansätze gibt es auch außerhalb von AWS. E2B betreibt pro Session eine microVM und macht Ports über sandbox.getHost(port) erreichbar. Das MIT-lizenzierte sandboxd vergibt pro App eine Live-Preview-URL. Agent-Sandbox ist eine selbst gehostete, zu E2B kompatible Lösung auf Kubernetes. Welcher Ansatz überlegen ist, lässt das Material nicht beurteilen.
