Generated website source is executable input. Installing dependencies, running a build, and opening the result in a browser are all actions performed on code the controller did not author.

The WebsitePitcher prototype therefore separates the orchestration process from short-lived agent and build containers. The isolation model is part of the application architecture, rather than an instruction asking generated code to behave politely.

Agent access and build access differ

The agent needs its model connection. The build needs the website source and toolchain. Giving both processes the same credentials would expand the build's access without helping it compile the site.

Both container paths use a network-disabled profile. The agent receives a deliberately constrained model-proxy connection; the build does not receive that proxy or model credentials.

The runner also checks for the intended rootless engine and applies resource and execution limits. It should fail when those requirements cannot be met instead of silently switching to a more privileged execution path.

These controls reduce exposure. They do not make an arbitrary generated program mathematically safe or remove the need to inspect the actual runtime configuration.

Treat transferred files as data

The controller exchanges bounded file manifests. Before accepting them, it validates paths, sizes, types, and duplicate entries.

The important invariant is that a manifest entry can describe a permitted file inside its assigned artifact area. It cannot request traversal outside that area, create arbitrary links, or choose a controller-owned destination.

The same validation applies to generated source and returned build artifacts. Trusting the output merely because a container returned it would move the attack boundary rather than enforce it.

Publish artifacts through a controlled commit point

The artifact store stages files in a pending directory, writes the version's source and evidence, creates its version history, and then moves the completed artifact into its final location.

The intention is to avoid a ready version that points to half-written output. Database state and filesystem publication still need failure handling; a rename does not make every persistence system one atomic transaction.

Improve and variant operations also need an explicit base version. Otherwise an asynchronous job can silently use whichever version happened to become current later.

Preview access is not publication

An internal preview is version-bound and token-protected. Public demonstration access is a separate publication decision with its own expiry.

The preview runs on a separate local address from management, reducing accidental cookie sharing. Requests check publication status, and response policy limits external resources and referrer leakage.

Expiring a preview can stop future access. It cannot retract files someone already downloaded, so private or identifiable data should not enter generated demonstrations in the first place.

This is a local prototype with further operational work ahead. Its useful design principle is already concrete: generation, execution, review, artifact storage, and publication are separate capabilities, and each should receive only the access required for its own job.