Can an AI publish to your site by accident? What we refuse to build
No — and not because we are careful, which is worth nothing, but because of three decisions in the software. Creating content creates a draft on every platform we support. Publishing, unpublishing, scheduling, menus and redirects are a separate permission that starts unticked. And a connected assistant cannot ask for that permission: the request is dropped before you are ever shown an approval screen, so the only way it gets ticked is that you tick it. What follows is the whole arrangement, including the parts we decided not to build.
·
This is the question that decides whether anybody can use software like this on a real business, and it deserves a longer answer than a reassurance. A promise is only as good as the thing that would have to fail for it to break.
The box that starts unticked, and cannot be ticked for you
When you connect ChatGPT or Claude, you are shown a list of permissions with boxes. One of them is "change what visitors see", and it covers publishing, unpublishing, scheduling, editing a page that is already public, menus and redirects. It starts unticked. With it unticked, an assistant can read your site, write drafts, change drafts, put images in your library and propose a bulk change — and cannot alter one thing a visitor would notice.
The part that makes that a promise rather than a default is smaller and less obvious. A client cannot request that permission. An AI client asks for the permissions it wants when it connects, and we drop publishing from whatever it asked for, every time, on every route a client can use. The reason is precise: a permission the client requested is shown in the "it will be able to" list on the approval screen, where there is no box to untick — so leaving the box unticked would stop being enough, and we had already promised that it was.
The one place a read happens before a write
Editing content is the awkward case, because the same request can be harmless or not depending on what it lands on. Changing a draft nobody can see is writing; changing a page a visitor is reading is changing what visitors see. So an edit asks for the writing permission, and asks for the publishing one as well when the item is already public — which means reading the item first to find out, comparing its status to that platform's own word for live. If we cannot tell which state it is in, the answer is no. A refusal that might have been unnecessary is a far better outcome than an edit that might have been public.
The one irreversible act on any platform, and the guard around it
Ghost is the platform where this stops being theoretical. A Ghost publication has members, and publishing a post can email it to all of them. That is the only act in any of our adapters that cannot be undone — you cannot unsend an email — and it was worth building the guard properly rather than being careful.
- Nothing can build the request. Every Ghost request is checked for the levers that cause an email — the modern one in the address, the older ones in the body — and a request carrying any of them throws rather than failing politely. Nothing in the software is supposed to be able to build such a request, so reaching that check means our own bug, and it is treated as one: the operation stops, nothing is charged, and it is written to the log.
- A post set up to email is not published or scheduled at all. If Ghost reports a post as email-only, or with a newsletter already attached, we leave it alone. Sending it is your decision, taken in Ghost, where you can see who it goes to.
- A post that has already been sent is untouchable, and "sent" is not a destination. The only way to produce that state is to send the email, so it stays in the list of states Ghost reports and is refused as a state anything can move a post into.
Four things we have decided not to build
Each of these was a real decision with a date on it, not an unfinished feature. They are listed here because what a tool refuses to do tells you more about it than what it offers.
- No administrative actions, only administrative reads. An assistant can report what is installed, what needs updating and who has an account. It cannot install, update, activate, deactivate, change a setting or create a user. That was Rafael's decision, taken after being shown exactly what each step up could do to a live site, and it is the one capability that could have taken somebody's website down.
- No browser automation, ever. When a platform has no supported way to do something, the answer is that it cannot be done. Driving somebody's administration screens with a headless browser would fill in a great many of the grey cells in our tables and would break the first time a platform changed a button — on somebody's live website, in a way nothing could log.
- No bulk change without a person approving it. A bulk job prepares a preview, lists every page it will touch, and waits. The approval is a human one, in your own account — not a confirmation argument an assistant can fill in, which is a gate in name only.
- No design, no theme, no layout. Even where an API would allow it. The words on a page are reviewable; a changed layout is a thing you discover by looking at your own site, and nobody wants to discover that.
What happens when something does go through
Everything an assistant does is written down — what was asked for, which site it touched, what came back — and that record is read-only in your account. A bulk job can be rolled back. A publish can be put straight back to draft, which is exactly how we test that publishing works at all: publish our own draft, check it, put it back. And if you want the permission gone, remove the connection from your own account or from ChatGPT or Claude, and nothing can be asked of your site again until you add it back.
Honest limit: there is one thing in this arrangement you should know about rather than take on trust. The permission to change what visitors see was split out of the general writing permission after some connections had already been made, so a connection made before that split has to be removed and added again for publishing to work at all — and on that approval screen the box still starts unticked. Drafts keep working with no reconnection. We would rather describe that than let somebody discover it.
Questions we get asked about this
- What if I tell the assistant to publish something?
- Then it publishes it, if you granted that permission when you connected. The point is not that publishing is impossible — it is that it never happens as a side effect of something else you asked for.
- Can an assistant delete my content?
- There is no tool that deletes content. The most it can do is move something to a state visitors cannot see, on a platform that has one. Menu entries and redirects can be removed, and both of those need the permission that changes what visitors see.
- Do you ever use my website password?
- On most platforms there is no password involved at all — a token or an application password, revocable on its own. Drupal is the exception, because its basic authentication uses a real account password, which is why the setup page says to make an account for the job rather than using yours.