AgentCore Runtime Session Endpoints: Previewing a Coding Agent's Web App Live, and the Access Limits AWS Documents

AWS published "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime" on October 30. The feature is Session endpoints: each AgentCore runtime session gets an authenticated URL that forwards HTTP and WebSocket traffic to ports you list in advance. The post uses it to show a coding agent editing a Vite site while you watch the page change.

I read the post and the sample folder's README in the awslabs/agentcore-samples repo. I did not deploy anything, so the behavior below is what AWS documents, not what I observed. I did not read the linked Session endpoint documentation page.

What a Session endpoint is

Per the post, AgentCore runtime runs each agent session in its own isolated microVM. A Session endpoint is an authenticated URL for one session that forwards each request's method, path, query string and body, and WebSocket connections, to the ports you allow. Six details from the post:

• You choose the ports. Set allowedPorts in CreateAgentRuntime: 1 to 5 entries, each a single port or a range within 8000 to 12000, excluding reserved platform ports. Allowing a port does not start a server. Your app must listen on it, bound to 0.0.0.0.
• The URL arrives with the session. InvokeAgentRuntime returns it in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header.
• Every request is authenticated. With IAM, each HTTP request, HTTP/2 stream and WebSocket handshake carries a SigV4 signature, and the caller needs bedrock-agentcore:InvokeAgentRuntimeProxy on the runtime and its endpoint. With a JWT authorizer, each request carries a bearer token. "Knowing the URL doesn't grant access."
• The host name selects the port. The client connects on 443, and a prefix such as 8090-- on the host chooses the port inside the session.
• It carries HTTP/1.1, HTTP/2 (including server-sent events and gRPC) and WebSocket.
• It is scoped to one session. It lasts only as long as the session. AWS says to use it to build, test and review, and to deploy to a hosting service such as AWS Amplify Hosting to serve users.

It differs from a runtime endpoint such as DEFAULT, which controls which agent version callers reach. A Session endpoint lets you see what the agent runs inside its session, works with whichever version the session runs, and stops when the session ends.

The sample

A coding agent runs on port 8080 with four file tools (list, read, write, edit) and calls Claude Haiku 5.5 in Amazon Bedrock. It starts a Vite dev server on port 8090. On your machine, a PreviewApp serves a chat page and opens a local endpoint. A browser cannot add SigV4 signatures to the requests a page makes, so the SDK's Session endpoint client opens a local endpoint on localhost that signs each request and WebSocket handshake.

Port 8080 is not in allowedPorts, because InvokeAgentRuntime reaches the agent without the Session endpoint. The allowed ports are 8090 (the site) and 8081 (a /status route that lists each prompt and the files it changed). The post's example prompt asks for a dark color theme, and the site updates through Vite's hot-reload WebSocket without a refresh.

Requirements listed: bedrock-agentcore 1.25.2 or later, boto3 1.43.122 or later, Python 3.10+, Node.js 22+, and access to Claude Haiku 5.5. The agent deploys as a zip in S3 with direct code deployment for Node.js, so no Docker or ECR repository is needed.

I checked PyPI the same day: bedrock-agentcore latest was 1.25.2, which matches the minimum the post names.

What the runtime refuses

The post says refusals come back with an HTTP status, an empty body and an error code in a response header, so you can tell them from your app's errors:

Request	Response
A port not in allowedPorts	403 AccessDenied
No valid credentials	403 AccessDenied or 401 AuthenticationRequired
Allowed port, nothing listening	502 PortNotReachable
Session no longer exists	404 SessionNotFound

How access is protected, and where it stops

Per the post:

• The runtime strips its own authentication headers before forwarding, so the website does not receive your signature.
• Requests are logged in CloudTrail as InvokeAgentRuntimeProxy events.
• The local endpoint acts with your credentials. It listens on 127.0.0.1 only, answers only requests addressed to its own local address, and refuses WebSocket connections from pages on other origins. AWS says to run it only while you use the preview.
• "The access controls don't separate the website from the agent." Both run in the same session, so give the execution role only the permissions the agent needs.
• If the runtime replaces the session's compute, open connections close and the agent's edits might not survive without persistent storage.
• The agent's file tools resolve paths inside the site folder and refuse paths outside it. AWS suggests Bedrock Guardrails if others can send prompts, and reviewing changes before publishing.
• Session endpoints work with microVM runtimes, not the Instances compute type. URLs are reachable over public HTTPS, and PrivateLink is not supported for inbound connections.

A small discrepancy I found

The post says the complete sample is in the "14-remote-access" folder of the agentcore-samples repo. On October 31 that path returned a 404 for me. The post's own clone command, and the repo, use 01-features/02-host-your-agent/01-runtime/03-advanced/16-session-endpoints, which loaded and contains the notebook, deploy.py, preview_app.py, cleanup.py and the agent and site folders. The repo's 03-advanced directory has no 14-remote-access entry; item 14 there is 14-byo-warm-pool. So use the 16-session-endpoints path. This looks like a stale name in the prose, but I do not know the cause.

What I would check

These are my untested suggestions.

1. Deploy the sample in a throwaway account and read deploy.py first. It creates a runtime, uploads to S3 and creates an IAM role.

2. Confirm the refusals yourself. Request a port outside allowedPorts and a call with no credentials, and compare with the table.

3. Keep allowedPorts minimal. Each port you add is another surface reachable with the same credentials.

4. Scope the execution role tightly. The post says the agent and the site share a session.

5. Check CloudTrail for the InvokeAgentRuntimeProxy events after a test, so you know what a review session leaves behind.

6. Decide where persistence lives if you need edits to outlast the session.

7. Run the clean-up cells. The post says to delete the runtime, uploaded code and role to avoid ongoing charges.

What I would not conclude

• That a Session endpoint is safe to give to other people. The post says the access controls do not separate the site from the agent, and it describes the credentials as yours.
• That it is a way to host an app. AWS says it is for building, testing and review.
• That the sample behaves as shown. I did not run it.
• That the post's prose and repo agree everywhere. One folder name did not.

Frequently asked questions

What are Session endpoints?

Per AWS, an authenticated URL per AgentCore runtime session that forwards HTTP and WebSocket traffic to the ports you allow.

How many ports can I allow?

One to five entries in allowedPorts, each a single port or a range within 8000 to 12000, per the post.

How is it authenticated?

SigV4 for IAM runtimes, or a bearer token for a runtime with a JWT authorizer, on every request.

Can I use it to serve my app to users?

AWS says no: deploy to a hosting service such as AWS Amplify Hosting.

Does it work over PrivateLink?

The post says PrivateLink is not supported for inbound connections.

Which compute types does it support?

microVM runtimes, not the Instances compute type, per the post.

Where is the sample code?

In the 16-session-endpoints folder of awslabs/agentcore-samples. The post names a different folder, which returned 404 when I checked.

Sources

All read on October 31, 2026.

• Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime (AWS Machine Learning Blog, October 30, 2026)
• 16-session-endpoints sample (awslabs/agentcore-samples)
• bedrock-agentcore on PyPI

Not read: the linked Session endpoint documentation, the notebook and source files, and any CloudTrail output.