Who Is Allowed to Change Your Website Now?

A question that used to answer itself

For most small businesses, “who can change the website” had an obvious answer: whoever had the login. Usually one or two people, both of whom you knew, both of whom would think twice.

That’s changed, quietly, in about a year.

Webflow shipped MCP 2.0 in July 2026, which lets AI agents work on live sites with proper permission enforcement and branch-based iteration. Their own figure is that over 30% of enterprise customers were already running agents against production sites, roughly four times the number in January. Anyone on a coded stack has been able to point an agent at their repository for longer than that.

So the honest current answer to “who can change your website” is often: whoever has the login, plus whatever they’ve connected to it, plus anything that has.

That doesn’t need to be alarming. It does need a decision, and most businesses this size have never made one.

Why it matters more than it sounds

Three reasons, none of them theoretical.

Speed removes the pause. The value of an agent is that it does in two minutes what took an afternoon. The afternoon was also when you noticed the mistake. Take out the afternoon and you take out the noticing.

Confident output is hard to triage. Generated work has a flat surface. There’s no rushed-looking corner to draw your eye, because it all looks equally finished. You can’t skim it for the weak bit the way you can with human work.

Attribution gets muddy fast. When something’s wrong on Thursday and three people and two agents touched the site on Wednesday, “what changed?” is a question you want a system to answer rather than a group chat.

Two patterns worth copying

Both solve the same problem. Pick the one your team can actually operate.

The branch pattern

Changes happen in an isolated copy. Someone looks at it. Then it goes live.

This is how software teams have worked for twenty years — a pull request — and it’s now available inside visual platforms too. Webflow’s MCP 2.0 lets agents build on branches so changes sit in a secure, isolated environment before reaching the live site, enforces your existing roles and permissions including custom ones, and logs every action with clear attribution of what was done by AI.

Good when: more than a couple of people touch the site, or agents are involved at all.
Cost: a step between doing and shipping. Some people find that intolerable. They’re usually the people whose mistakes you’re protecting against.

The staging pattern

A complete copy of the site that isn’t public. Changes go there, get checked, then get published.

Simpler, older, and perfectly adequate for a small team. The weakness is that it’s one shared space — two people working at once will collide.

Good when: one or two editors, changes in batches.

What actually goes wrong

The failure I see most isn’t a rogue agent. It’s overlap.

A marketing hire edits a page in the morning. An agent is asked to update the same page in the afternoon, using the version it read yesterday. The morning’s work quietly disappears. Nobody notices for a fortnight because the page still looks fine — and it does look fine, just without the thing that was added.

Branches catch this. Shared staging doesn’t. That’s the strongest practical argument for the branch pattern, and it has nothing to do with AI going wrong and everything to do with two things editing the same document.

A change-control policy for a small business

One page. Adapt it, put it somewhere people will see it, and revisit it once a year.

Who can publish

Named people only: Joe Bloggs. Not roles, not “the marketing team” — names. Everyone else drafts.

What can be published without review

Copy corrections, image swaps, new blog posts, new CMS entries.

What always needs a second pair of eyes

Anything touching navigation, pricing, forms, checkout, legal pages, or site-wide components. Anything an agent produced that goes beyond copy. Anything on the homepage.

Where changes are made

On a branch or on staging. Never directly on the live site, including by whoever wrote this policy.

Agents

Agents work under the permissions of the person who connected them, and that person owns what the agent does. Agents may draft anything. Agents publish nothing without a human looking at it. Every agent action is logged.

Before anything goes live

Someone opens it on a phone. Someone submits the form. That’s it — two checks, thirty seconds, and they catch most of what actually goes wrong.

If something breaks

Joe Bloggs is called. The change log is checked first, not last. Nobody is blamed for a rollback.

The three things that matter most

If a one-page policy is more than you’ll sustain, do these:

1. Nothing publishes straight to live. Branch or staging, always, no exceptions for senior people.
2. A human looks at anything structural or commercial before it’s public. Agents draft; people decide.
3. You can see who or what changed something. Most platforms log this. Know where the log is before you need it.

Everything else is refinement.

Where this is heading

Webflow’s stated direction has agents as ordinary members of the team — with roles, permissions and accountability built in from the start rather than added after something breaks. Whether or not that ships as described, the direction is right and it’s not unique to them.

The businesses that will handle it comfortably are the ones that decided who’s allowed to change things while the answer was still simple. It’s a lot easier to write this policy now, with two editors and one occasional agent, than in eighteen months with five of each.

Platform capabilities verified 13 August 2026.

→ Back to Rented Ground
→ Next: Your Second Audience