AWS Adds Session Endpoints to Bedrock AgentCore Runtime for Live App Previews

What AWS announced

Amazon Web Services said Amazon Bedrock AgentCore runtime now supports a capability called Session endpoints, which lets developers open and interact with a web app that a coding agent is building, directly in their own browser, while the agent is still working on it.

According to AWS, AgentCore runtime already runs each agent session in its own isolated microVM. Session endpoints add an authenticated URL for that session that forwards each request's HTTP method, path, query string, and body, as well as WebSocket connections, to ports the developer has allowed. AWS said this lets a developer watch a page update as the agent saves each file, rather than waiting for the app to be copied out and deployed elsewhere before each review.

How Session endpoints work

AWS described six details that govern how Session endpoints function:

• Port selection: Developers set an allowedPorts parameter when calling CreateAgentRuntime, specifying one to five entries, each a single port or a range within 8000-12000, excluding reserved platform ports. AWS noted that allowing a port does not start a server; the application must listen on it, bound to 0.0.0.0.
• URL delivery: The InvokeAgentRuntime response carries the endpoint URL in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header, which SDKs that support it expose as sessionEndpointUrl.
• Authentication: For runtimes using AWS IAM, AWS said each HTTP request, HTTP/2 stream, and WebSocket handshake carries a Signature Version 4 signature, and the caller needs the bedrock-agentcore:InvokeAgentRuntimeProxy permission. For runtimes with a JWT authorizer, each request carries a bearer token instead.
• Port routing via host name: AWS said the client always connects on port 443, and a prefix on the host name selects the target port inside the session.
• Protocol support: AWS said the endpoints carry HTTP/1.1, HTTP/2 (including server-sent events and gRPC), and WebSocket traffic.
• Session scope: AWS said the URL requires credentials on every request and lasts only as long as the session, and is meant for building, testing, and reviewing agent output. To serve an app to end users, AWS said developers should deploy it to a hosting service such as AWS Amplify Hosting.

AWS also said that because a browser cannot attach a SigV4 signature or bearer token on its own, the Session endpoint client in the bedrock-agentcore SDK can open a local endpoint on the developer's machine, which adds credentials to each request and WebSocket handshake before forwarding it to the browser.

AWS distinguished the Session endpoint from the runtime endpoint that AgentCore runtime already provides. A runtime endpoint, such as DEFAULT, controls which version of an agent callers reach and lets developers keep separate versions for development and production. A Session endpoint, by contrast, reflects whichever version of the agent is running in that specific session and stops working when the session ends.

The sample walkthrough

AWS published a sample with four parts: a coding agent running on port 8080 that edits a website's files using list, read, write, and edit tools; a Vite development server on port 8090 started by the agent, which serves the website and pushes saved changes to the browser over its hot-reload WebSocket; a local PreviewApp that serves a preview page, sends prompts to InvokeAgentRuntime, and opens a local endpoint for the website; and the preview page itself, which loads the website through the local and Session endpoints while sending prompts to the agent. The complete sample, including the notebook the post follows, is in the 14-remote-access folder of the agentcore-samples GitHub repository.

Source: AWS Machine Learning Blog, "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime," published October 30, 2026.