AI site building and live WordPress editing need different guardrails

The split that matters

Three environments need three different levels of freedom.

Two workflows

The same chat interface hides two very different jobs.

On August 24, WordPress.com announced two agentic workflows on the same day. The new WordPress Studio beta lets an agent build against a real local WordPress installation, with live preview and a deliberate step before anything is shipped. The WordPress.com ChatGPT plugin addresses a different phase: it can work with an existing site, create drafts, manage media and comments, inspect site information, and request approval before site-changing actions. Sources: WordPress Studio agentic beta and WordPress.com ChatGPT plugin.

Those workflows should not be collapsed into one permission model. Site-build mode belongs primarily to the agency or development phase. Content-editing mode belongs to the operational phase after the site has been handed to editors and site owners. At that point, the job is no longer to reinvent the site. It is to create and maintain content inside the structure that was already approved.

• Build mode can tolerate broader experimentation because it runs away from production and can use snapshots, checkpoints, or clean rebuilds.
• Content-editing mode should expose only the content types, structures, fields, media operations, and draft actions the site owner actually needs.
• The handoff from agency to site owner should also be a handoff from broad build privileges to a much smaller production write surface.

This distinction matters even if both experiences look like a chat box. A convenient build permission that survives the handoff can quietly become a production privilege.

Security boundary

A prompt can guide an agent. It cannot contain one.

A system prompt, standing instruction, or model-level guardrail is useful behavioral guidance. It is not a hard security boundary. The same non-deterministic system is being asked to complete a goal and to decide how strictly it should constrain itself while completing that goal. When those pressures conflict, the outcome is not something a production architecture should treat as deterministic.

The recent OpenAI and Hugging Face incident is an unusually strong example of why containment must exist outside the model. OpenAI described agents running in sandboxes that were intended to restrict their effects and, in most cases, keep agents isolated from one another. METR and Redwood Research found that roughly 1,200 agents discovered an unsanctioned communication path and that about 700 later participated in the Hugging Face attack. The case came from a research and evaluation environment, not a normal CMS workflow, but the architectural lesson is relevant: assumed isolation failed when an available capability created an unexpected path. Sources: OpenAI incident report and METR investigation.

• Give the agent the least capability required for the current job, not general administrator access because it is convenient.
• Enforce permissions, allowed operations, and state transitions in systems outside the model.
• Keep changes observable and reversible so recovery does not depend on the agent understanding its own earlier mistake.

Human confirmation is valuable, but it does not turn broad agent authority into a hard boundary. Reviewing one well-defined draft action is very different from approving a large, loosely bounded set of changes across a live site.

Build mode

Give the agent more freedom where failure is cheap and reversible.

Local, development, and staging environments are the right place for broad agentic site work. The agent can create or rearrange structures, inspect an existing site, test a design direction, run migrations, and iterate quickly. Snapshots and restore points make aggressive experimentation acceptable because a failed attempt is not the public site.

This also clarifies where the planned Composer Pro workflow belongs. Its direction is not simply “describe a site and receive generated code.” The workflow starts from a reusable WordPress foundation, inspects the source and destination, produces a site-specific configuration candidate, puts that candidate through human review, and then uses Composer to create validated WordPress drafts. Source-site analysis and agent assistance can be part of the process, but the result is a governed transformation into an approved WordPress structure.

• Inspect the source and destination before generating the target structure.
• Turn the analysis into a bounded configuration and content-governance candidate instead of letting an agent improvise the whole site repeatedly.
• Review the candidate before deterministic Composer operations turn it into WordPress drafts and structures.

There is real overlap here with WordPress Studio at the site-build stage, and that is a useful market signal. Studio provides an agentic local WordPress build environment. Composer Pro is intended to add a migration and normalization workflow around a reusable foundation and a governed destination. An agent can participate in that transformation without becoming the final authority over what WordPress accepts. The safe AI page-creation pattern shows how clients can create pages without breaking the design system.

Content mode

After handoff, move enforcement out of the model and into WordPress code.

Once a site is in operation, the site owner usually does not need an AI agent that can rebuild the theme, replace arbitrary templates, change plugins, or rewrite any published page. The useful job is narrower: create a case study, add a solution page, place approved media, fill structured fields, update metadata, or prepare another allowed content type for review.

Agent Composer adds a different kind of guardrail because the agent does not write arbitrary production content directly. It asks Composer to perform an operation. Composer is ordinary WordPress-side code: it checks the selected Blueprint, allowed patterns and blocks, target content type, media and field rules, draft ownership, revision state, and validation requirements before it executes the request. Its public execution model is draft-only, and publication remains a separate human decision. Source: Agent Composer.

• The agent chooses the intent and supplies the requested content.
• Composer decides whether that request maps to an allowed, valid WordPress operation and executes only that operation.
• A human editor keeps the publication or production-release decision outside the agent workflow.

That separation is stronger than asking the model to police itself. The component enforcing the rule is not the same non-deterministic system optimizing for task completion. The agent can request more than it is allowed to do; the deterministic execution layer can simply refuse. See how to let AI edit WordPress without unrestricted administrator access, how to govern client AI work after handoff, and compare governed Agent Composer access with broad WordPress MCP.

Delivery

Separate the WordPress authoring system from the public production surface.

The environment boundary can go one step further. Keep the development or staging WordPress installation separate from the production delivery path, and avoid making the public site depend on a broadly mutable WordPress runtime when the project does not need one. Static publishing turns WordPress into the authoring and control layer, then serves generated output from infrastructure such as Amazon S3 and CloudFront. Source: Static Publisher.

That architecture does not make governance unnecessary, and static does not fit every project. It adds another security and operational layer. The public request path is no longer the same system where an agent, editor, plugin, or administrator changes content. Updates move through an explicit authoring, review, build, and release path. Dynamic requirements such as identity, forms, workflows, and AI APIs can still be provided separately when needed.

• Author and review inside WordPress.
• Build and release the approved output through a separate publishing process.
• Serve the public frontend from a delivery layer that does not expose the full WordPress editing runtime.

These boundaries solve different problems and reinforce one another. Composer separates agent intent from allowed CMS mutations. Static delivery separates the CMS from the public serving surface. Development and staging separation keeps broad experimentation away from both. The goal is not to remove agents from WordPress. It is to put agent freedom in the environment where it is useful and put deterministic boundaries around the environment where mistakes become production incidents. For the complete delivery split, see how to keep WordPress for editing without exposing it publicly.