An AI agent can have more access than a task requires. An agent asked to edit a paragraph might also be able to publish the page. If it has the necessary credentials, it could make that change public before the user has reviewed it.
The agent should only have the permissions needed for the work the user has authorized. That limit should still hold if the agent misunderstands the request or decides that publishing would be helpful.
Good judgment does not replace limits on power
In her conversation with Dwarkesh Patel, historian Ada Palmer describes a distinction Machiavelli made about political power. Cesare Borgia could conquer a city, remove its ruling factions, and treat ordinary people more fairly than their previous rulers had. In Palmer's account, people could benefit from his rule while still having little protection from him.
A ruler who could order a death at will had a different kind of power from one who had to make an accusation through a public process. The process placed a limit on the ruler too. Machiavelli knew such processes could be abused; he had been tortured and exiled. But a ruler's usual fairness offered no protection if he could simply choose to abandon it.
There is a useful comparison here for AI agents. An agent may usually make sensible decisions. Its permissions determine what it can do on the occasion when it gets a decision wrong.
Match permissions to the requested work
For a paragraph edit, the agent may need to read the site files, change one of them, and run checks. It can do all of that under one request. It does not need permission to publish unless publication is also part of the task.
Those limits need to exist in the environment where the agent works. Running a command on a local machine does not make the command harmless. A test script with production credentials may still change a live service. A working copy should have access only to the files, tools, and services needed for the task.
The user can authorize editing and publishing together. Once the destination and scope are clear, the agent does not need to ask again at every step. The important point is that having credentials does not give it permission to do more than the user requested.
GitHub's protected branch controls provide one way to enforce a limit. They can require checks or another person's review before changes are merged. For that protection to work, the agent must be unable to bypass the rule or change it.
Security engineers call this principle "least privilege": give a person or program the access needed for its job. NIST SP 800-53, a U.S. government security catalog, treats access controls, audit records, and recovery as separate concerns. Each serves a different purpose. A log can help explain an unauthorized release after it happens; preventing the release requires a limit on access.
Check the work through the systems that changed
An agent's completion message should point to evidence the user can inspect. For a website edit, show the file changes and check results. If the task also included committing or publishing, include the relevant commit identifier or deployed version and the authorization covering those actions. The records should make clear which actions were proposed and which actually happened.
Keeping those records in the relevant systems also makes them available after the conversation ends. A user should be able to compare the published page with the reviewed change without relying on the agent's description of it.
Some mistakes can be reversed. Vercel documents how to restore an earlier production deployment, and version control keeps earlier file revisions. Other consequences remain: restoring a website does not recall an email, make a leaked secret private, or recover deleted data that had no backup.
For the paragraph edit, the result should be easy to check: what changed, which checks ran, and whether the change is still a draft or is now public. The agent needs enough access to finish that job, with the limits set before it starts.