# Amazon Bedrock AgentCore enables live web previews from an agent session

- Source: MechNext — https://mechnext.eu/en/article/58-amazon-bedrock-agentcore-enables-live-web-previews-from-an-agent-session
- Published: 2026-11-01
- Updated: 2026-11-01
- Category: Industry News
- Language: en (Markdown in other languages: ?lang=de, ?lang=sk, ?lang=pl, ?lang=zh, ?lang=ru)

> An Amazon Bedrock AgentCore Session endpoint provides authenticated access to allowed ports inside an isolated agent session. Amazon’s sample connects a coding agent, Vite, and a local endpoint so browser previews update through hot reload without a manual refresh.

Amazon’s sample shows how a developer can watch a web application while a coding agent changes its files. The foundation is the Amazon Bedrock AgentCore runtime, where every agent session runs in its own isolated microVM. A Session endpoint provides authenticated access to the ports that have been allowed for that individual session.

This arrangement separates two communication paths. InvokeAgentRuntime is used to reach the agent itself. Other services running beside the agent in the same session, such as a development web server or a status route, can be reached through the Session endpoint when their ports are explicitly included in the runtime configuration.

### Configuring ports and obtaining the endpoint

When an agent runtime is created, `allowedPorts` accepts between one and five individual ports or port ranges. Each selection must fall within 8000–12000 and must exclude ports reserved by the platform. An application offered on one of those ports must listen on `0.0.0.0`.

InvokeAgentRuntime returns the Session endpoint URL in the `X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url` header. SDKs that support the feature expose the same value as `sessionEndpointUrl`. The address is scoped to a single session rather than being a permanent runtime address. Credentials are required on every request, and the endpoint stops working when its associated session ends.

### Authentication and traffic types

For a runtime authorized with IAM, HTTP requests, HTTP/2 streams, and WebSocket handshakes sent through the Session endpoint require SigV4 signatures. The caller also needs the `bedrock-agentcore:InvokeAgentRuntimeProxy` permission. A runtime configured with an inbound JWT authorizer uses bearer tokens instead.

The endpoint carries both HTTP/1.1 and HTTP/2 traffic. This includes server-sent events and gRPC, alongside WebSocket connections. In the sample, that combination allows ordinary web content and the development server’s live-update connection to pass through the same session-scoped access mechanism.

The `bedrock-agentcore` SDK provides a Session endpoint client that can expose a local endpoint. It adds credentials to browser requests and WebSocket handshakes before forwarding them to the remote Session endpoint. The browser therefore connects locally, while the client handles the authenticated forwarding required to enter the session.

### How the sample is connected

The coding agent in the sample runs on port `8080`. A Vite development server runs on `8090`, and the agent exposes a status route on `8081`. Only ports `8090` and `8081` are allowed through the Session endpoint. Port `8080` is deliberately omitted because InvokeAgentRuntime reaches the coding agent without going through that endpoint.

When the agent saves a modified file, Vite sends the change through its hot-reload WebSocket. The connection travels through the Session endpoint and the local endpoint to the browser. As a result, the displayed website updates without a manual page refresh. The flow joins the agent’s file edits, the continuously running Vite server, and authenticated WebSocket transport within the life of one session.

### Requirements and access boundaries

Amazon lists Python 3.10 or later, `bedrock-agentcore` 1.25.2 or later, and `boto3` 1.43.122 or later for the sample. It also requires Node.js 22 or later with npm, Git, a Jupyter environment, and access to Claude Haiku 5.5 in Amazon Bedrock.

The allowed-port list actively controls access. A request aimed at a port outside `allowedPorts` is refused with HTTP `403 AccessDenied`. A request without credentials receives the same refusal. When the refusal comes from the runtime, the response body is empty and an error code is supplied in a response header.

Three conditions therefore shape access to an auxiliary service: the application must listen on the required interface, its port must be included in the allowed configuration, and each request or connection must carry the credentials appropriate to the runtime’s authorization mode. Because the URL belongs to one session and expires with it, clients also have to use the endpoint returned for the current invocation context.

The complete route is narrowly defined. InvokeAgentRuntime contacts the agent and returns the session URL. The Session endpoint exposes only the configured auxiliary ports. The local SDK client adds authentication for browser traffic. Vite then uses its WebSocket to report saved changes, allowing the current web preview to update without reloading the page.

For the sample, the distinction between port `8080` and ports `8090` and `8081` is especially important. The first belongs to the direct agent invocation path, while the latter two demonstrate session-scoped proxy access. Keeping those roles separate explains both the runtime configuration and why a live site can be displayed while the agent remains reachable through its normal invocation interface.