# Amazon Bedrock AgentCore adds Session endpoints to preview live web apps built by coding agents

published: 2026-10-30T22:05:26.937Z
topic: infrastructure
source: https://aws.amazon.com/blogs/machine-learning/preview-web-apps-live-as-your-coding-agent-builds-them-with-amazon-bedrock-agentcore-runtime/
url: https://aiagentnews.io/stories/amazon-bedrock-agentcore-adds-session-endpoints-to-preview-live-web-apps-built

AWS describes Session endpoints for Amazon Bedrock AgentCore runtime, which give each agent session an authenticated URL for opening apps running inside it. The post walks through a sample where a coding agent edits a Vite website and the changes appear in the browser without a refresh.

Session endpoints forward HTTP and WebSocket requests from a session to the ports the developer allows when calling CreateAgentRuntime, with between 1 and 5 entries in the allowedPorts list, each a port or range within 8000 to 12000. The URL is returned in a response header from InvokeAgentRuntime, and each request must be signed with SigV4 for IAM-based runtimes or carry a bearer token for runtimes with a JWT authorizer. The host name prefix selects the target port while clients connect on port 443.

The sample runs a coding agent on port 8080, a Vite development server on port 8090 and a status route on port 8081. A local endpoint opened by the bedrock-agentcore SDK adds credentials to browser requests, since browsers cannot sign requests themselves. The agent uses Claude Haiku 5.5 in Amazon Bedrock to decide which files to change.

The runtime removes its own authentication headers before forwarding requests, and it records them in AWS CloudTrail as InvokeAgentRuntimeProxy events. Requests to ports outside allowedPorts are refused with a 403 AccessDenied response. The post notes that Session endpoint URLs are reachable over public HTTPS and that AWS PrivateLink is not supported for inbound connections.

## Why it matters if you build agents

Agent developers can review generated web apps in a live browser session without first deploying them elsewhere, which shortens the edit-and-check loop.

Session URLs stop working when the session ends and are scoped to the session, so the post recommends them for building and reviewing output rather than serving users, which still calls for a hosting service.

Because the website and the agent share a session, the post advises giving the execution role only the permissions the agent needs and reviewing its changes before publishing.