要点
- Amazon Bedrock AgentCore Runtime adds Session endpoints: each microVM session gets an authenticated HTTPS URL that forwards method/path/query/body and WebSockets to allowed ports (roughly 8000–12000, up to five entries).
- Browsers cannot SigV4-sign page requests; the bedrock-agentcore SDK local endpoint injects credentials on the machine so one page can chat left and hot-reload a Vite site right.
- Refusal semantics are explicit: disallowed port/missing credentials → 403; nothing listening → 502; dead session → 404—the preview is a build-and-review channel, not end-user hosting.
On 30 October 2026, the AWS Machine Learning Blog announced that Amazon Bedrock AgentCore Runtime Session endpoints let you preview web apps live while a coding agent builds them. It is easy to file this as another hot-reload demo. A stricter reading: the review loop’s latency tax is not how fast the model writes code, but whether the app must be copied out of the session and deployed elsewhere before anyone can click it. Session endpoints make “see the page the agent just changed” a first-class runtime capability.
[1]The mechanism is explicit. On CreateAgentRuntime you set allowedPorts (one to five entries, single ports or ranges roughly in 8000–12000, excluding reserved platform ports); allowing a port does not start a server—the app must listen on 0.0.0.0. The InvokeAgentRuntime response carries X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url (SDK: sessionEndpointUrl); a hostname prefix selects the in-session target port while clients still connect on 443. IAM runtimes require SigV4 on every HTTP/HTTP2/WebSocket handshake plus bedrock-agentcore:InvokeAgentRuntimeProxy; JWT inbound uses a bearer token instead. The sample places the coding agent on 8080 (via Invoke, not in allowedPorts), Vite on 8090, a status route on 8081, and a local PreviewApp that serves a localhost preview page and opens a local endpoint for 8090.
Three design choices are checkable. Auth boundary: knowing the URL is not access; the runtime strips its own auth headers before forwarding so the site never sees the caller’s signature; requests land in CloudTrail as InvokeAgentRuntimeProxy. Protocol coverage: HTTP/1.1, HTTP/2 (including SSE and gRPC), and WebSocket all pass—necessary for Vite HMR, not decorative. Refusal table: port outside allowedPorts or missing credentials → 403 AccessDenied (or 401); allowed port with nothing listening → 502 PortNotReachable; gone session → 404 SessionNotFound. The post also draws a hard line: Session endpoints are for build/test/review; user-facing apps should go to hosting such as Amplify. Constraints match: site and agent share the session’s compute, so keep the execution role minimal; if compute is replaced, connections drop unless persistent storage is configured.
Steelman one: this is still cloud-runtime lock-in—teams already previewing via local or self-managed docker compose gain less, and must accept public HTTPS Session URLs without PrivateLink inbound. Steelman two: the local endpoint binds 127.0.0.1 with the caller’s credentials, fixing browser signing while tying “who can open the preview” to a developer laptop and a short-lived session; remote collaboration and retention need extra work. Steelman three: the sample has Claude Haiku 5.5 restyle a theme—proving a file-tool + HMR loop, not the security boundary of a complex full-stack app; Guardrails and path confinement to the site folder help, but enterprise tool-permission matrices remain open.
For coding-agent product teams, the KPI expands from “one-shot patch pass rate” to “seconds from prompt to visible UI change.” For platform security, Session endpoints turn “can the agent reach in-session services” into an explicit port policy and proxy permission, not an implicit sidecar forward. If review still depends on pushing artifacts to a shared preview environment, the AgentCore story will look ahead of practice; if PMs already sit beside the agent clicking buttons, missing in-session preview becomes felt friction.
[1]Watch three things over the next six months: whether Session endpoints move from notebook samples into default IDE/plugin paths for coding agents; whether allowedPorts and InvokeAgentRuntimeProxy land as auditable enterprise policy packs; and how cleanly teams separate in-session preview from user-facing hosting so temporary Session URLs are not mistaken for production ingress. If coding-agent product speed increasingly depends on true in-session preview rather than another deploy pipeline, Session-endpoint-class capabilities stop being demo tricks and become runtime defaults.