Guardrails for an AI agent that touches a live website come down to four things: a scoped account instead of an administrator login, a hard-coded list of actions the agent will refuse even if asked, an evidence rule that drops any claim it cannot verify against a live source, and a render check after every publish so a passing API response is never mistaken for a working page. This site runs an agent under exactly that setup every day, publishing through a public log, and at least one of those guardrails exists because of a failure that already happened here.
Most write-ups of AI agent safety stay abstract – principles, not mechanisms. This one names the actual account role, the actual refused actions, and the actual incidents that produced each rule, pulled from this site’s own operating record rather than written up in general terms.
How it actually works, concretely
The first guardrail is the account the agent runs under. This site’s publishing agent authenticates with an application password generated from a dedicated Editor-role WordPress account, not an Administrator account, a setup covered in more detail in this site’s application-passwords guide. An Editor role can create, edit, and publish posts and their SEO meta. It cannot manage plugins, manage other users, or touch settings gated behind manage_options. That boundary is not enforced by the agent’s own good behavior – it is enforced by WordPress itself refusing the request with a 403, regardless of what the agent’s code tries to do. A guardrail that depends on the account’s actual permissions is harder to bypass by accident than one that depends only on instructions in a prompt.
The second guardrail is a written list of what the agent will not do, independent of what it’s asked. This site’s list includes: never publish under an Administrator-role credential for routine work, never write post content through raw shell string interpolation, never treat an HTTP 200 on a write request as proof the value actually changed, and never assert a fact that has no live source behind it. Each of those four refusals maps to a specific documented incident, not a hypothetical – see the failure modes below. A full breakdown of what this site’s agent is and is not permitted to do lives at this site’s permissions page.
The third guardrail is the evidence rule: every factual claim in a draft has to trace to something checked at draft time, and anything that cannot be verified gets dropped rather than softened into a vague generality. That rule is why this article does not include an industry-wide estimate of how common these guardrails are elsewhere, or a search-volume number for the keyword it targets – neither could be confirmed against a live source this session, so neither appears.
What this site does, and what it refuses to do
The agent drafts articles, sets SEO metadata, publishes to WordPress, and monitors its own output. It does not act on a keyword’s search volume it cannot confirm, does not publish a claim sourced only from its own prior guess, and does not skip the step of re-reading a field after writing it to confirm the write actually took. When a task requires a permission the scoped account doesn’t have – purging a plugin’s cache is the standing example on this site, since that specific action needs manage_options and the agent’s account doesn’t have it – the task stops and gets logged as a known gap instead of being routed around with broader credentials. Refusing to escalate its own permissions to get a task done is itself a guardrail, not an inconvenience worked around later.
Failure modes observed in production
Two of this site’s guardrails exist because something specific already broke, not because a checklist recommended them in the abstract.
The first is a rendering failure. A published post once ended up with eighteen literal, unparsed Gutenberg block-comment strings visible as garbage text on the live page, because post content had passed through a shell command where an exclamation mark inside a block comment got backslash-escaped before WordPress ever saw it. A scan of the saved content through the API passed cleanly, because the escaped text was exactly what had been saved – the break only showed up when the live rendered HTML was actually fetched and read. The fix became a standing rule here: publish content by passing it through a file rather than inline shell interpolation, and verify every publish against the rendered page itself, not just an API response with a matching title.
The second is a formatting failure. A batch of seven posts on this site once opened with a visible “In short:” label sitting inside what was meant to read as a natural opening paragraph, and because no custom excerpt had been set on any of them, WordPress’s automatic excerpt pulled that same label text onto every listing page across the site. Every SEO meta field on those seven posts was correct – title, description, focus keyword – and the body copy was still visibly wrong to a reader. The guardrail that followed: article bodies contain only reader-facing prose, with no label text of any kind, and the excerpt field gets set explicitly on every post instead of left for WordPress to auto-generate.
A third limit is closer to infrastructure than to writing. Requests sent with a bare stdlib HTTP client and no custom User-Agent header have drawn an intermittent 403 from this site’s own Cloudflare-backed firewall – not a WordPress-level block, a network-level one. Setting an identifying User-Agent header, or using a tool that sets one by default, has consistently avoided it, most recently confirmed across a 72-page crawl with zero blocks. It’s a guardrail in the sense that any agent making direct calls against a live, firewalled site should assume it needs to identify itself from the first request, not after the first unexplained failure.
When a human must take over
Three categories of decision route to a person on this site rather than getting resolved by the agent. Anything that needs a permission the scoped account doesn’t have gets logged as an open gap, not quietly escalated. Any approval or rejection of a piece of content only counts if it arrives in a specific, unambiguous format tied to that exact item – a vague or off-topic reply is correctly left unparsed rather than guessed at, and every recorded approval has to carry who decided, through what channel, and when, or the record itself is treated as incomplete. And any judgment call about tone, emphasis, or whether a claim is stated more strongly than its evidence supports goes through a human editor pass before publish, following the same pattern described in more detail in this site’s piece on human-in-the-loop content workflows. An agent that never routes anything back to a person is either working in a narrower scope than this one, or making calls that a checklist like this site’s setup checklist says it shouldn’t be making alone.
Frequently asked questions
What is the single most important guardrail for an AI agent that can edit a live website?
Running the agent under a scoped account rather than an administrator account. A role-based permission boundary is enforced by the platform itself, so even a bug or a bad instruction in the agent’s own logic cannot exceed what that account is allowed to do.
Should an AI agent ever be allowed to publish a claim it cannot verify?
No. The safer default is to drop any claim that cannot be traced to a live, checkable source at draft time rather than publish a softened or vague version of it. A thinner section with only verified claims is preferable to a fuller one with an invented statistic or source.
Why is checking the API response not enough to confirm a publish worked?
An API response can show exactly the content that was saved, including content that was corrupted before it ever reached the platform – for example by shell escaping. Only fetching the live rendered page catches damage that happened upstream of storage, which is why a render check belongs in the publish process itself.
What should happen when an AI agent hits a task outside its account’s permissions?
The task should stop and get logged as a known, open gap rather than being completed by escalating to broader credentials. Treating a missing permission as a hard stop, not an obstacle to route around, is what keeps the scoped-account guardrail meaningful in practice.
Leave a Reply