Build
Unprivileged workspace
The agent creates the site, runs local checks, and produces an immutable artifact. It may access source content and development tools, but it cannot modify production services, DNS, or release settings.
Publish a website with a browser agent without exposing deployment keys.
Build freely, approve an immutable preview, grant one publishing capability, verify the live route, and close access with a receipt.
Follow the workflowBuild without production accessPreview immutable outputApprove one releaseGrant short-lived authorityVerify public behaviorRevoke and receiptBuild without production access
The safe publishing pattern
Separate creative autonomy from production authority.
Why the boundary matters
A browser agent can research, write, code, test, and prepare a website without possessing a production deployment credential. Those activities need workspace access, not authority over a live domain. The publishing credential becomes necessary only after the artifact is complete and a person or policy approves the exact release.
Many unsafe workflows collapse those phases. A deployment token sits in a general environment variable from the moment the agent starts. It may become visible to every subprocess, appear in diagnostic output, leak into a copied shell command, or remain usable after the task ends. The agent is trusted with production authority even while it is still exploring.
Core ruleThe model may request use of a publishing capability, but it should never read, repeat, or store the credential that implements that capability.
The safer design introduces a broker between the agent and the deployment system. The broker receives a structured request, verifies the approved artifact and target, issues a short-lived grant inside the execution boundary, observes the release, and invalidates access after verification.
Before you start
Prepare three separate trust zones.
Approval channel
A person reviews the preview, target, change summary, and risk. Approval is bound to the artifact digest rather than a mutable folder.
Publish runtime
A clean worker receives only the approved artifact and temporary deployment capability. It does not inherit the full build conversation.
Verification runner
Independent checks confirm the expected public route, title, assets, links, and rollback readiness before the grant closes.
Implementation workflow
Six stages from draft to verified release.
STAGE A
Build and test in an unprivileged workspace
Let the agent generate the static page or application, install only required dependencies, and run local validation. The workspace can write artifacts but has no deployment token, provider session, or DNS capability.
artifact/
index.html
assets/
checks.json
manifest.jsonSTAGE B
Freeze the artifact and describe the release
Create a content digest and a manifest that names the destination service, public route, expected title, files, and rollback artifact. The approval must apply to this immutable package, not whatever happens to be in the workspace later.
artifact_sha256: 6f82...a190
target: production-static-site
route: /approved-guide/
expected_title: Approved Guide
rollback: release-184STAGE C
Approve the preview and narrow request
Show the user the preview URL, change summary, target environment, requested capability, and grant lifetime. If the artifact or target changes, invalidate approval and ask again.
STAGE D
Issue the publishing capability inside a clean runtime
Prefer workload identity, provider-issued deploy hooks, or tokens restricted to one service. Inject the capability directly into the publishing tool. Do not return its value to the language model or place it in general logs.
grant.scope = "deploy:production-static-site"
grant.artifact = "sha256:6f82...a190"
grant.ttl = "8m"
grant.destinations = ["api.host.example"]STAGE E
Deploy once and verify independently
The publisher uploads the approved artifact. A separate verifier requests the exact route, confirms status and title, checks critical links and assets, and compares the deployed artifact when the platform supports it.
STAGE F
Revoke, destroy runtime state, and return a receipt
End the grant even when deployment fails. Destroy the clean worker, retain redacted evidence, and send the user the live URL, verification result, release identifier, access-closure status, and any failed checks.
Approval message
Ask for a decision the user can understand.
A strong request identifies the immutable artifact, destination, consequence, access lifetime, and rollback. "Allow deployment access" is too broad because it leaves the user guessing what will happen.
Grant policy
Decide what proceeds and what must stop.
| Observed condition | Decision | Reason |
|---|---|---|
| Artifact digest and destination match approval | Proceed | The execution remains inside the approved release envelope. |
| Agent asks to deploy a changed artifact | Stop | Approval was bound to different bytes; regenerate preview and request. |
| Publisher contacts the configured hosting API | Proceed | The network destination is required for the scoped capability. |
| Publisher attempts DNS or account administration | Stop | The grant covers release upload, not infrastructure configuration. |
| Verification fails but rollback is available | Rollback | Restore the prior release before revoking the temporary capability. |
| Grant reaches its time limit | Revoke | Expiration wins even when the agent is still reasoning about next steps. |
Independent verification
Do not equate a successful deploy command with a healthy site.
Exact route returns success
Request the new public path directly and require the expected status code.
Title and canonical match
Confirm the page identity and production URL, not merely a generic homepage.
Critical assets load
Check scripts, styles, images, and fonts without relying on browser cache.
Primary actions resolve
Test outbound links and the main user path with clear failure reporting.
Mobile layout remains usable
Inspect a narrow viewport for overflow, occlusion, and unreadable controls.
Rollback remains reachable
Verify the prior artifact or provider rollback mechanism before closing access.
The final receipt
- Artifact
- sha256:6f82...a190
- Release
- production-static-site / deploy-185
- Live URL
- https://example.com/approved-guide/
- Checks
- 6 passed, 0 failed
- Rollback
- release-184 available
- Access
- Grant revoked; runtime destroyed
Production access should arrive after the artifact is approved and disappear before the agent starts planning another task.
Failure handling
Design the unhappy paths before the first autonomous release.
Deploy command fails
Capture redacted stderr, preserve the approved artifact, revoke the grant, and report the failure. Do not extend access automatically while the agent improvises.
Always revoke before retry planning.Deploy succeeds, verification fails
Attempt the preapproved rollback if available, verify the restored release, then close access. Report both the failed release and rollback result.
Public behavior is the source of truth.Custom domain is broken
Separate service health from DNS health. Verify the provider hostname, report the exact DNS or TLS failure, and avoid claiming the custom URL is live.
Never hide a domain-routing failure.Use this with Super
Coordinate approval without babysitting the browser.
A conversational release loop
A text-message AI assistant can deliver the preview, request the bounded grant, and return the verified release receipt in the channel the user already watches. The agent waits at the consequential step rather than requiring the user to observe every build action.
The computer-use cache can retain safe browser state between runs while deployment authority remains temporary. That separation improves speed without converting cached sessions into permanent production access.
This workflow directly supports an AI agent that builds websites: creation and local QA happen autonomously, the human approves the immutable preview, and the agent receives only the publishing capability needed for the approved release. Super coordinates the lifecycle from request through verified outcome.
FAQ
Implementation questions
Can the deployment token stay in an environment variable?
A short-lived token may be injected as a process environment value inside a clean, isolated publisher when the deployment tool requires it. It should not be placed in the general build environment, shell history, diagnostic dumps, or any context visible to the model.
What if the hosting provider only supports long-lived keys?
Store the key in a dedicated vault, restrict retrieval to the publisher identity, limit network destinations, expose it only during execution, and rotate it regularly. This is less ideal than provider-issued temporary credentials but still prevents broad agent access.
Why bind approval to an artifact digest?
Without a digest, an agent could change files after preview approval and publish different content under the original consent. The digest connects the reviewed artifact to the bytes released.
Should the agent be allowed to change DNS during publishing?
Usually no. DNS changes have a broader blast radius and different rollback behavior than uploading a site. Treat DNS as a separate capability with its own preview, approval, and verification plan.
Can low-risk releases be preapproved?
Yes. A policy may allow releases to a preview environment or routine content updates when tests, artifact rules, destinations, and rollback conditions are satisfied. Production changes with new capabilities or infrastructure effects should trigger a stronger gate.
Primary security references
- NIST, Implementing a Zero Trust Architecture. Just-enough and just-in-time access, continuous evaluation, and least privilege.
- NIST SP 800-207, Zero Trust Architecture. Dynamic policy decisions for resource access.
- OWASP Secrets Management Cheat Sheet. Guidance on secret isolation, rotation, expiration, revocation, and dynamic credentials.
- Google Cloud Workload Identity Federation. Short-lived identity exchange as an alternative to persistent service-account keys.