Four controls for AI-assisted website editing.

The model proposes; the system enforces.

A model can interpret a request and suggest a structured change. Treat that proposal as untrusted input. The application must decide whether the authenticated user may make it, whether the values are valid, and whether the required approvals exist.

Connecting a model to tools, including through a protocol such as MCP, does not by itself establish permissions. Limit what the tool can do and enforce authorization at the service that performs the action.

For a first implementation, choose a small set of allowed operations. “Change this event's start time” is easier to validate than unrestricted access to edit an entire website.

Four controls to demonstrate before launch.

1. Permissions enforced outside the model. Derive the user's role from trusted authentication. Enforce field and resource permissions on the server or trusted publishing service. A role dropdown or prompt instruction is not an authorization boundary.
2. A defined set of changes. Validate the operation, target, data type, length, and allowed values. Restrict design tokens and templates where the workflow requires consistency.
3. Checks plus human review. Run link, accessibility, content, and rendering checks appropriate to the change. A banned-word list can catch listed words; it cannot establish that a claim is true or that a page meets every legal obligation.
4. An explicit publishing decision. Show the exact diff and rendered preview. Record who approved which version, protect against intervening changes, and provide a tested rollback.

Ask to see an unauthorized rate change rejected, an invalid value rejected, an outdated proposal stopped, and an approved change reversed. Keep the result as acceptance evidence.

Separate drafting from publishing. If a model or connector is unavailable, the editor should know what is happening and have a documented fallback.

Fewer public components can help, but responsibilities remain.

A static public site can have a smaller runtime surface than an architecture that executes a CMS request for every visitor. That is an architectural choice, not a promise that the site cannot be compromised.

Review the build pipeline, repository access, deployment credentials, dependencies, third-party scripts, forms, and the editing service. Define who patches each component and how an editor's access is revoked.

Do not put secrets in browser code. Validate consequential actions on a trusted service. Keep an audit trail proportionate to the data involved, with access and retention controls.

Try the workflow demo → It illustrates interaction and review, not production-grade access control.