Emerge Times — News for the Agentic Age
AI Agents

AWS details Session endpoints for live previews of agent-built web apps

Emerge Times

Amazon Web Services published a walkthrough on 30 October 2026 for Session endpoints, a capability of Amazon Bedrock AgentCore runtime. A developer can use it to open, in their own browser, a web app that a coding agent is building. The app stays inside the agent’s session, so changes show up within seconds and no separate deployment step is needed.

What Session endpoints do

AgentCore runtime puts each agent session in its own isolated microVM. A Session endpoint gives that session an authenticated URL, which passes HTTP requests and WebSocket connections on to ports the developer has approved. According to AWS, the URL reaches only those ports. It is not tied to a particular agent release, and it ceases to work once the session is over.

AWS lists several operating details:

  • Ports are chosen through allowedPorts when the runtime is created: one to five entries within 8000–12000, with reserved platform ports excluded. The application must listen on the port itself, bound to 0.0.0.0.
  • The URL is returned in a header of the InvokeAgentRuntime response.
  • Every request is authenticated, with SigV4 signatures for IAM runtimes or bearer tokens for runtimes with a JWT authorizer. Knowing the URL does not grant access.
  • A prefix on the host name picks the port inside the session, while clients always connect on port 443.
  • HTTP/1.1, HTTP/2 (including server-sent events and gRPC) and WebSocket traffic can all pass through.

AWS describes the URL as a tool for building, testing and review. For serving an app to users, it points to a hosting service such as AWS Amplify Hosting. It also distinguishes Session endpoints from runtime endpoints such as DEFAULT, which determine which agent version callers reach.

The sample setup

The sample lives in the agentcore-samples GitHub repository. Inside the session, a coding agent listens on port 8080 and works on the website’s files through four tools: list, read, write and edit. It also launches a Vite development server on port 8090. When a file is saved, that server notifies the browser through its hot-reload WebSocket. On the developer’s computer, a component named PreviewApp serves a page with chat on the left and the live site on the right, and relays prompts via InvokeAgentRuntime.

A browser cannot attach SigV4 signatures or bearer tokens to the requests a page makes by itself. For that reason, the Session endpoint client in the bedrock-agentcore SDK opens a local endpoint on the developer’s machine. The local endpoint signs every request and every WebSocket handshake with the developer’s credentials, then passes it along. In the example, the agent relies on Claude Haiku 5.5 in Amazon Bedrock to choose what to modify.

When the developer asks for a dark coffee-house theme, the agent’s steps stream into the chat pane. The site pane changes without a refresh once the stylesheet is saved. A second port, 8081, serves a /status route listing prompts and the files changed. The same Session endpoint reaches it, with only the port differing. Port 8080 is intentionally absent from allowedPorts, since InvokeAgentRuntime reaches the agent without the Session endpoint.

The post adds that the runtime rejects requests to ports outside the allowed list, and requests lacking credentials, with 403 AccessDenied. The source text cuts off before the full table of refusal cases, so the other error conditions are not covered here.

Requirements and limits

The sample requires an AWS Region where Session endpoints are offered, Python 3.10 or later, Node.js 22 or later, and access to Claude Haiku 5.5. It ships the agent as a zip in Amazon S3 using direct code deployment for Node.js, so neither Docker nor an Amazon ECR repository is needed. Session endpoints work with microVM runtimes, not the Instances compute type. The URLs are reachable over public HTTPS, and AWS PrivateLink is not supported for inbound connections.

Why it matters for agents

This is a documented pattern for keeping a human review loop close to where an agent works. Output can be inspected in place instead of after each deploy. Two design choices stand out. Preview traffic is kept apart from the agent’s own invocation path, and authentication is enforced on every request rather than only when a connection opens.

The limits are also clear. The URLs are tied to a session and not meant for production traffic. The lack of PrivateLink may matter to teams that need private inbound paths. The source shows one sample with one model and one setup, so how well it generalizes to other agents is not established here.

Sources

This article was prepared with AI assistance and reviewed by an Emerge Times editor before publication. Licensed CC BY 4.0: credit “Emerge Times (emergetimes.com)”. Usage & License