AWS lets coding agents preview apps inside a session. Treat the URL as temporary infrastructure

THE SIGNAL IN ONE SENTENCE

A preview link can look suspiciously like a deployed website. It has a URL. It opens in a browser. A colleague can click around. The page may even update while a coding agent edits the files behind it. That resemblance is useful. It is also a trap. Amazon Web Services published a walkthrough on October 30 showing how a coding agent can keep a web application running inside an Amazon Bedrock AgentCore Runtime session while a reviewer watches the result. The agent changes the app, the development server stays alive in the same session and the browser receives the new state without waiting for a separate hosting deployment. AWS calls the connection a session endpoint. The plain signal is simple: the endpoint is a temporary, authenticated window into one running session. It is not a production release, a durable address or proof that anybody approved the code. Treat it as temporary infrastructure. That means the preview needs a small receipt. The receipt should say who opened the session, which code and runtime it contains, which ports are reachable, who can view it, what data sits behind it, when it expires, where its logs live and whether the work was promoted or destroyed. Without that record, a convenient review tool can drift into a shadow environment. People start sharing the URL in tickets. A product manager mistakes the preview for a stable demo. Test credentials linger. Reviewers see different code at different moments. Nobody can tell whether the page they approved is the artifact that later reached production. The technology is not the villain here. Ambiguous lifecycle is. AgentCore Runtime runs an agent session in an isolated microVM, according to AWS. A session endpoint provides an authenticated HTTPS address for application servers inside that session. The operator selects the container ports that may be reached when creating the runtime. The application still has to listen on those ports and bind appropriately. When a session begins, Runtime can return the endpoint URL in a response header. A client then selects the destination port through the endpoint hostname and sends an authenticated request. Runtime checks the caller and the requested port before forwarding the method, path, query string and body to the server in the session. The endpoint can carry ordinary web requests, server-sent events, gRPC and WebSocket connections. That is why a live development server can feel like a normal interactive app rather than a screenshot. Authentication depends on the runtime configuration. AWS documents IAM authentication with Signature Version 4, commonly called SigV4, and inbound JSON Web Token authorization. For IAM, the caller also needs permission to invoke the runtime proxy. AWS is explicit that knowing the URL does not grant access. Good. A secret-looking URL should never be the security model. Still, authenticated does not mean appropriate. A colleague may have broad cloud permissions but no business seeing the customer fixture loaded into a test page. A contractor may be allowed to review the interface but not call an internal API route. A developer may have proxy permission while the preview server itself accepts dangerous actions with no application-level authorization. The infrastructure gate and the application gate are different gates. The endpoint is also scoped to one session and lasts only as long as that session. AWS tells builders to use it to build, test and review. To serve the app to users, AWS points to a hosting service instead. That distinction should appear in the interface around every preview. Label it with the session owner, environment, creation time and expected end. Show a visible state such as draft, ready for review, accepted or rejected. Provide a separate production address only after a real deployment. Do not let the temporary URL occupy the place where a release link normally appears. The review receipt starts with identity. Record the Runtime session ID, the opaque session endpoint identifier, AWS account, Region, runtime ARN, runtime version and runtime endpoint used to create the session. Record the coding agent, agent version, model route, repository, branch, commit and uncommitted working-tree state. The endpoint identifier and the Runtime session ID are not the same value. AWS tells clients to store the returned URL with the corresponding session ID rather than trying to reconstruct one from the other. Preserve both. Next comes the route. Record every allowed port entry, the port selected for the preview, protocol and application path. AWS currently permits one to five allowed-port entries, each naming a port or range between 8000 and 12000, excluding reserved platform ports. That is a useful infrastructure constraint, not a complete inventory of application exposure. The receipt should also name the routes reviewers are expected to use. If the development server exposes a debug console, file browser, health route or admin API on the same port, port allowlisting will not hide it. Review the application route surface, not just the firewall-shaped part of the diagram. AWS notes another practical detail: the proxy preserves the method, path, query string and body, but the application receives an internal Runtime hostname in the Host header. Builders may need to configure development servers to accept that host and should prefer relative URLs for assets and redirects. This is exactly the kind of setting that becomes dangerous when copied carelessly into production. A permissive development-server host rule may be reasonable inside a tightly controlled preview. It should not quietly become the production default. Save the preview-only configuration beside the receipt and require an explicit production configuration during promotion. Authentication belongs in the record too. State whether the runtime uses IAM or a token authorizer. For IAM, record the principal, role session, policy version and InvokeAgentRuntimeProxy decision. Record the credential source as a reference, never the credential itself. For a token authorizer, record the issuer, audience, policy version and token identifier or hash without storing the bearer token. AWS's walkthrough explains that an ordinary browser cannot attach SigV4 or a bearer token to every page request on its own. The AgentCore SDK can run a local endpoint that adds credentials before forwarding browser traffic. That convenience deserves a boundary. The local helper is acting as a credentialed proxy. Record who started it, which cloud identity it uses, which remote session it targets and which local interface can reach it. Bind it narrowly. Stop it when review ends. Do not leave a developer laptop quietly translating browser clicks into signed cloud requests all afternoon because somebody forgot which terminal owns port 8088. Now inventory the data. Preview environments are magnets for shortcuts. A team wants the page to look convincing, so someone copies a realistic database snapshot. The agent needs an API, so a long-lived token enters an environment variable. The demo needs email, payments or storage, so a supposedly harmless click reaches a real service. The receipt should name every dataset, test fixture, secret reference and external service available to the session. Record whether the data is synthetic, masked or production-derived. Record egress policy and the destinations the runtime can contact. Record whether clicks can create records, send messages, spend money or trigger another agent. Do not put raw secrets or personal data into the receipt. Put stable references, classifications and hashes there, then store the sensitive material in the system designed to protect it. The next field is time. The session endpoint is tied to the session lifecycle. Record the creation time, most recent activity, configured session limits, observed closing time and teardown result. If the URL stops working when the session ends, say so. If a platform resumes the session or a new invocation reuses it, record that transition instead of pretending the first timestamp still describes a fresh environment. Time matters during review because the app can change under the reviewer. Imagine a reviewer opens the page at 10:12, checks the checkout flow and writes approved in a ticket at 10:18. The agent saved another file at 10:15. Which version did the reviewer actually see? The preview receipt should attach a revision marker to each review event. A useful marker can combine repository commit, working-tree hash, build identifier, process start time and application content hash. If the agent edits files after approval, the state should return to changed since review. Do not treat one approval click as a blessing on every future byte served by the session. Logs make this reconstructable. AWS documents CloudTrail data events for session endpoint requests. Enable and retain the relevant events for environments whose reviews matter. Link the CloudTrail event range, Runtime logs, coding-agent trace, application logs and reviewer actions in the receipt. CloudTrail is not an application diary. A proxy invocation event can show that infrastructure access occurred. It may not explain which button the person clicked, what state the app displayed or whether an internal application authorization check succeeded. Join infrastructure logs with application evidence, and be honest about gaps. The promotion record is the final piece. If reviewers accept the preview, do not promote the running session itself by social convention. Build a named artifact from a recorded commit. Run the normal tests and security checks. Deploy that artifact through the production path. Record the artifact digest, target environment, deployment identifier and production URL. Then compare the artifact with the reviewed revision. If they match, the preview served its purpose. If they differ, require another review or document the specific approved difference. If the preview is rejected, record the decision and tear the session down. Confirm that the endpoint no longer responds, the local credentialed proxy has stopped, temporary credentials have expired and temporary data has been removed according to policy. This workflow has practical uses beyond a polished demo. A developer can pair with a coding agent and see visual changes immediately. A designer can test responsive behavior before a branch becomes a pull request. A quality engineer can reproduce a bug in the same environment where the agent is fixing it. A security reviewer can inspect a minimal proof of concept without publishing it to a shared staging cluster. An incident team can preserve a short-lived reconstruction with a clear owner and deadline. The pattern can also reduce waste. Teams often create semi-permanent preview stacks for every branch, then discover a month later that half of them still run. A session-scoped preview can disappear with the work it was created to inspect. But temporary infrastructure is not automatically cheap infrastructure. The session still consumes compute, logs, network traffic and human attention. A coding agent can keep a server alive, generate repeated builds or create other cloud resources. Track the cost at the session level and close idle work deliberately. There are several limits to the current story. AWS's launch material is a vendor walkthrough, not an independent security assessment. It demonstrates one development and review pattern. It does not prove that every application placed behind a session endpoint is safe. Session endpoints use public HTTPS ingress, according to the documentation, and AWS PrivateLink ingress is not supported for them. Organizations with private-only ingress requirements need to account for that boundary rather than assuming the session inherits every private networking property of another service. The feature supports microVM runtimes and not the Instances compute type with capacity providers. Regional availability, SDK support and organizational controls still need verification in the account where a team plans to use it. Allowed ports are not application authorization. IAM or token authentication is not least privilege by itself. Isolation does not sanitize test data. CloudTrail does not capture every meaningful application event. A short-lived URL does not excuse weak dependency, secret or code review. Most importantly, a preview is not a release. The fastest way to preserve that distinction is to make the temporary state visible and machine-readable. At session start, create a receipt with owner, code, runtime, ports, identity, data and expiry. During review, append revision markers, viewers and decisions. At promotion, attach the production artifact and deployment. At teardown, prove the endpoint and helper are gone. Then test the process. Open a session with a harmless app and synthetic data. Allow one preview port. Confirm that an unauthorized identity is denied. Confirm that an authorized reviewer can reach only the intended route. Change the app during review and verify that the approval becomes stale. End the session and verify that the URL fails. Stop the local proxy. Search the logs and reconstruct the sequence without relying on the developer who ran it. If the record can answer who saw what, when they saw it, what they approved and what reached production, the preview is useful infrastructure. If the answer is merely, "There was a link in chat," the temporary environment has already outlived its paperwork.