Yes. The account that publishes your website should have less power, not more. If its job is to release an approved version of the site, broad administrative access adds business risk without helping it do that job.
Editor’s note: This article is part of a retrospective published on October 16, 2026. Its displayed date identifies where the documented work fits in the series timeline.
Build Log Retrospective: Series hub · Previous: Why Production Publishing Should Be Boring and Repeatable · Next: Why I Removed a Feature After It Shipped
What is wrong with an all-powerful publishing account?
Convenience is the usual argument. Give one account broad access, and it can handle whatever comes up. That sounds efficient until you ask a more useful question: what could that account change that it does not actually need to change?
The answer is often a lot.
A publishing account may be used by a routine process. It may be touched during a hurried update. It may be involved when someone is trying to fix a problem quickly. If that account carries broad authority, a simple typo, a mistaken instruction, or a compromised account can reach far beyond the small task at hand.
That is what people mean by blast radius. It is the size of the area a single mistake can affect. Least privilege does not make risk disappear. It makes unnecessary access smaller, which can make a bad day more contained and easier to reason about.
For a small business, this is not security theater. It is basic operational care. You do not give every staff member a master key because someone occasionally needs to unlock one room. The same logic applies to the account that publishes a website.
What did I change in my own publishing workflow?
On October 16, while tightening my publishing workflow, I introduced a dedicated account with restricted scope. Its job was to release an approved build, not act as an all-access administrator.
I also kept the act of publishing separate from changing the working materials behind the site. That distinction matters. A publishing step should deliver the prepared version, not become an opportunity to alter everything connected to the site.
The work included testing the workflow and addressing edge cases before treating it as a repeatable process. I am not presenting that as proof that every future problem is solved. I am sharing the decision behind it: give a routine job only the authority it needs, then make the surrounding process clear enough to inspect and recover.
That is a more durable standard than trusting a powerful account to behave perfectly forever.
Why is least privilege an operating habit, not just a technical rule?
Because access decisions are business decisions. They answer who can take action, who needs to approve it, and what happens when the process does not go as planned.
I like to separate four moments: preparing the change, reviewing it, approving it, and publishing it. One person can wear more than one hat in a very small business, but the hats should still be visible. The person making a change should know when they are asking for approval. The person approving should know what they are approving. Publishing should stay a narrow, repeatable action.
That is why human approval belongs in a serious AI workflow, too. Automation can assist with routine work, but it should not quietly erase the point where a person accepts responsibility for what goes live.
Least privilege and human approval solve different problems, but they support the same habit: make consequential actions deliberate. Do not rely on a vague assumption that the right person will notice at the right time.
How can a small business review publishing access?
You do not need a complicated audit to start. Make a one-page access map for the people and accounts involved in publishing. Plain language is enough.
For each one, write down:
- Its single job. For example, prepare, review, approve, or publish.
- The minimum access it needs. Ask what it must be able to change, and what it does not need to touch.
- The approval point. State who says a change is ready to go live.
- The recovery step. Write down who can stop, reverse, or correct a change when necessary.
- The review trigger. Revisit the map when the workflow changes or a role changes.
Then remove access that is merely convenient. This is not a call to make your business harder to run. It is a call to stop treating extra authority as harmless by default.
The same question carries into other AI-assisted work. In my note on read-only access for AI work, the principle is the same: an assistant or process does not need write access simply because it can be useful without it. Start with the narrowest job that solves the actual problem.
What is the practical takeaway?
Before the next website change, identify the account or person that can publish it. Then ask: What could this account change that it does not actually need to change?
Make the one-page access map. Name each job, reduce access to the minimum needed, show where approval happens, and keep a recovery step visible. Repeat the review whenever the workflow changes. You will not remove every risk, but you will stop carrying avoidable risk just because the current setup feels familiar.
If you are not sure who can publish, change, or approve your website today, I can help you review the workflow and make the access boundaries easier to understand. Start with a conversation, not a rebuild.
What is the one account, role, or routine process in your business that has more power than its job actually requires?
Find me across the web
Stay curious, my AI friend. It's the secret sauce - think like you are seven. - Ryan