The moment an AI agent can build and deploy software on its own, a new question appears: who checks the work before the world sees it? Autonomy is the point of giving an agent its own server, but autonomy without a review step is how a half-finished tool ends up on a public URL with a client watching.
The answer is not to slow the agent down. It is to make privacy the default, so every project starts in a state where only your team can reach it, and going public is a deliberate, reviewable decision.
Quick answer
Private by default means a new project has a stable URL that serves no public traffic until you explicitly set its visibility to public. The agent can build, run, and iterate freely in private, your team reviews the result, and the same URL goes live only when you choose. This gives agents room to work autonomously while keeping a human checkpoint before anything ships.
Key takeaways
- Autonomous agents need a private staging state, not an all-or-nothing public switch.
- A project should keep the same URL whether it is private or public, so what you tested is what ships.
- Review means opening the running app, not just reading generated code.
- Secrets and environment variables belong in the server, never in shared chat or public files.
- A durable workspace lets a human take over and inspect exactly what the agent did.
Why "private by default" is the safe default
There are two ways to handle visibility, and only one of them is safe.
The unsafe way is public by default: the agent ships to a live URL the moment it finishes, and you find problems after they are already visible. The safe way is private by default: the URL exists and is stable, but it serves no traffic until someone decides it should.
Private by default matters because agents are fast and confident. They will happily deploy a dashboard with a placeholder headline, a form with no validation, or a page that leaks a debug message. None of that is a disaster if the only people who can see it are on your team. It becomes a disaster when it is public before anyone looked.
The review loop
A good review loop treats the agent's output as a draft, not a release. The steps are simple:
- The agent builds the project in a private workspace and returns its URL.
- You open the URL and use the app the way a real user would.
- You describe what is wrong in plain language and the agent revises the same project.
- You repeat until the app is genuinely ready.
- You set visibility to public, and the same URL starts serving traffic.
The important detail is step two. Reading the generated code tells you what the agent intended. Opening the running app tells you what it actually did. Those are not always the same thing, which is why a live URL is the clearest artifact an agent can return.
The URL should not change when you go public
A common mistake in agent tooling is to give a project one URL while it is a draft and a different URL once it is live. That breaks the entire point of reviewing before shipping: the thing you approved is not the thing that goes out.
A stable slug fixes this. The project's URL is assigned when it is created and survives every visibility toggle. You test at that URL in private, and when you flip to public, the exact same URL serves the exact same project. There is no re-deploy step where something could quietly change, and no new link to distribute.
Secrets do not belong in chat
Agent-built apps often need real credentials: an API key for a payment provider, a token for a data source, a webhook signing secret. The wrong place for any of these is the chat transcript or a file in a public project.
The right place is the server's environment. Secrets live as environment variables inside the workspace, where the running app can read them but a public visitor cannot. This keeps the review loop honest: you can make a project public without worrying that going live also exposes a key. If you are handling anything sensitive, the security overview is worth a read before your first public project.
Keep a human takeover path
Private by default is a safety net, not a cage. The goal is to let agents work autonomously most of the time while keeping a clear path for a person to step in.
Because the agent works in a persistent workspace with durable files, logs, and environment variables, a human can open that workspace and see exactly what happened. An engineer can read the code, check the logs, fix a bug the agent missed, and hand it back. This is what separates a real agent deployment layer from a black-box that either works or does not.
What review does not have to mean
Review does not mean approving every keystroke. That would defeat the purpose of an autonomous agent. It means:
- The agent has full freedom inside a private project.
- The default state is unreachable to the public.
- Going live is a single, deliberate, reversible decision.
- A human can always inspect the workspace after the fact.
That balance — autonomy in private, a checkpoint before public — is what makes it safe to let an agent build real software instead of only drafting it.
FAQ
What does private by default actually mean for a new project?
A new project is created with a stable URL, but that URL serves no public traffic until you set the project's visibility to public. Only your team can reach it before then.
Does making a project public change its URL?
No. The slug is assigned when the project is created and stays the same across visibility toggles, so the link you tested privately is the link that goes live.
Can I make a public project private again?
Yes. Visibility is reversible. Turning a project private stops it from serving public traffic while keeping the same URL for when you are ready to go live again.
Where should API keys and secrets live?
In the server's environment variables, inside the workspace. The running app can read them; a public visitor cannot see them.
How does a human take over a project an agent built?
The workspace is persistent, so an engineer can open it and inspect the files, logs, and configuration directly, then edit and redeploy without rebuilding from a chat transcript.
Related reading
- The missing deployment layer for AI agents
- Why AI agents need persistent workspaces
- Why every AI agent should be able to return a URL
- Server4Agent security overview