The Security of Autonomous Publishing: Guardrails for Agentic Site Modification
Pillar: Layout Guardrails
Letting an AI agent publish directly to a live site sounds, reasonably, like it should worry you. It's a fair instinct. The honest answer isn't "don't worry about it" — it's a specific description of what's actually enforced, and where the real limits still are.
Content can't execute anything, ever
This is the part that's true unconditionally, not a policy someone has to remember to follow. Every piece of content is restricted to a small, explicit set of safe HTML — checked once the moment it's written, and checked again every time it's rendered, so a bypass of the normal write path still can't sneak something unsafe through. Scripts, inline event handlers, embedded iframes from arbitrary sources — all rejected outright, regardless of how they're asked for or what wrote them. An agent authoring content structurally cannot make it execute code, because the only things it's allowed to write can't.
This is also, quietly, why "the site's own JavaScript" and "content written by an agent" are two completely separate claims. The site itself can and does ship client-side code — search, for instance — written and reviewed by a human, the normal way. What an agent writes as content never can, on either path.
Who can actually publish — the honest, current answer
Two things are real and enforced today. First, only someone with real write access to the private content repository can reach the write path at all — nothing public-facing has standing access. Second, access to specific tools is derived live from that same repository's actual collaborator permissions, checked fresh on every connection, not from a separate account system that could drift out of sync or get forgotten about.
What's not true yet, stated plainly rather than rounded up: a fully hardened setup where even the repository owner's own personal credentials are structurally barred from bypassing the agent and pushing directly. That's a real, planned hardening tier — not a missing feature so much as an optional upgrade for anyone who wants it, since the platform-level mechanism it depends on isn't available on every hosting tier by default. The honest current guarantee is private repository access plus live, permission-derived tool access — which is genuinely strong, and worth stating precisely instead of leaning on a stronger claim that isn't true yet.
Every mistake is recoverable
The other half of "safe" isn't just prevention — it's what happens after something goes wrong anyway. Because the underlying storage is git, nothing is ever actually destroyed. A bad delete is undoable, reading the content back out of git's own history rather than restoring from a backup and hoping one exists. A bad publish is undoable too, through a real, reviewable change rather than a silent overwrite that erases the evidence of what happened.
Put together: content that can't execute anything, access that's real and checked live rather than assumed, and mistakes that are always reversible. That's not a claim that nothing can go wrong. It's a specific description of what actually stops it, and what still depends on who you've given repository access to — which is the real, honest scope of the guarantee.