A capable agent still needs limits
“Can the agent change the website?” is not one question. Reading a page, preparing a draft, opening a branch, merging a change, and modifying the domain are different actions with different consequences.
We want those distinctions to be visible in the system, not buried in a paragraph that the model might misunderstand.
Our starting principle is that permission to prepare a change is not permission to publish it.
Separate the permissions
For the first website workflow, we propose four practical categories.
Read: inspect the allowed pages and relevant performance data. This gives the agent context without changing the site.
Prepare: create a brief, edit an allowed file in a working branch, or produce a content draft. The output is still a proposal.
Review: evaluate the change against the original goal, evidence, and checks. An approval should refer to a specific revision, not a vague idea of the work.
Publish: make that reviewed revision live through the normal deployment process. This is a separate capability and should be unavailable unless the workflow has it explicitly.
Some areas start outside the boundary
Pricing, legal pages, account access, credentials, billing, and DNS should not be editable merely because an agent can improve a blog post.
The simplest first pilot is deliberately narrow. Allow a specific content directory and a small class of changes. Prohibit unrelated component edits and new dependencies. Stop when the requested task exceeds that boundary.
These are product requirements. They still need to be implemented and tested in the agent runtime; displaying a policy on a website does not enforce it.
A second model is not the whole safety system
A reviewer agent can help challenge a draft. It should not be the only thing preventing an unauthorized action.
We want the surrounding software to enforce the allowed paths, tools, spend limits, and publication permissions. That leaves the models to reason about the work inside a boundary that does not depend entirely on their interpretation of a prompt.
Broader access should be earned
The long-term goal is less manual supervision. The starting point is not full access.
We would expand permissions only after reviewing the actual work: which changes were useful, which checks missed something, and which mistakes repeated. Some workflows may stay human-approved because the cost of a bad change is not worth removing the checkpoint.
Read the proposed permissions model and try the sample approval workflow.