An agent finds an outdated product claim on your website and rewrites it. The draft looks useful, but the consequential question comes next: who can make that change public? An AI agent approval workflow gives the agent room to prepare an edit while keeping publication under an accountable person’s control.
Key takeaways
- Let agents propose website edits in a draft state; give publishing authority only to the people or systems explicitly assigned to it.
- Route each proposed change with a before-and-after diff, the reason for the edit, and links to the evidence used.
- Bind approval to a specific revision. If the draft changes after approval, require another review.
- Record who approved and published the change, then verify the live page and retain a way to revert it.
- Company context can help an agent draft an accurate change. It does not grant the agent permission to publish.
An AI agent approval workflow is a process that separates an agent’s proposed action from the authority to complete it. For public website edits, the agent prepares a draft and supporting evidence; a designated reviewer approves a specific revision; a permitted publisher releases it. The workflow records each decision so the team can trace what changed and who authorized it.
Why does a website edit need an approval gate?
A public page can become a commitment the moment it changes. An agent updating a price, policy, customer name, or product capability can publish an error that readers act on before anyone on the team notices.
The ability to operate a CMS is already plausible. In Dries Buytaert’s website experiment, agents logged into his Drupal site, found posts, and worked on meta descriptions and tags. Those are narrower tasks than changing a pricing page, but they illustrate the operational boundary: once an agent can edit through a site interface, its account permissions determine what it can change.
Reports about agents editing public knowledge sites raise the same concern. This article does not rely on an unverified Wikipedia incident or assume all agent edits are harmful. The useful design question is whether a draft can reach the public without the right review.
How should an AI agent approval workflow work?
Use separate stages for proposing, approving, and publishing. Make the CMS or publishing service enforce the boundary; an instruction in the agent’s prompt is insufficient if its credentials can already press Publish.
| Stage | Agent or human action | Control to enforce |
|---|---|---|
| Propose | Agent saves a draft and explains the change | Draft-only access; no live-page write permission |
| Review | Assigned person checks the diff and evidence | Approval tied to the draft’s revision ID or content hash |
| Publish | Authorized publisher releases the approved revision | Reject changed or expired approvals |
| Verify | Team checks the live result | Record the published revision and retain rollback access |
This can be a lightweight process for a small site. The important part is that approval applies to the exact content being published, rather than a general instruction to “fix the page.”
What should the reviewer see?
Send the reviewer the page URL, a before-and-after diff, the agent’s reason for changing it, and links to the sources behind any factual claims. Identify affected fields, such as page body, title, metadata, and links. A reviewer should be able to reject a draft without reconstructing the agent’s work from chat history.
For example, an agent might propose replacing “integrates with every CRM” with a narrower statement on a product page. The reviewer needs to see which approved product documentation supports the replacement. If the documentation is missing or access-restricted, hold the change for an owner who can verify it.
What if the draft changes after approval?
Treat the approval as invalid. A revision ID or content hash lets the publishing step check that the approved draft is still the one queued for release. If another editor changes the page or the agent revises its wording, send the new version back for review. Log the approver, timestamp, revision, and publication result.
This is an implementation recommendation, not a claim that every CMS provides it out of the box. Where the CMS cannot enforce revision-bound approval, put the check in the workflow that calls its publishing API.
Which changes can be routine, and which need a person?
Set review rules by the effect of the change. An internal draft of a tag or meta description carries different risk from a live edit to legal terms. Start with human approval for all agent-produced public changes, then consider narrower exceptions only after the team can see and audit the results.
A practical routing policy might look like this:
- Content owner: Copy and metadata changes on ordinary articles.
- Product or sales owner: Claims about features, availability, integrations, and customer commitments.
- Legal or policy owner: Terms, privacy statements, regulated claims, and security disclosures.
- Site operator: Changes to navigation, redirects, templates, or anything that affects multiple pages.
A change spanning categories should go to every required owner. Define who can approve, who can publish, and who can grant those rights before deploying the agent. Microsoft’s Copilot Studio documentation describes multistage approvals for agent flows, though that documentation labels the feature as preview and cautions against production use. Oracle describes a human approval node that pauses a workflow for a person’s decision. These are examples of approval patterns, not substitutes for checking the controls in your own publishing stack.
How does company context improve the draft?
An agent editing a public page needs a reliable account of what the company has actually approved. Otherwise, it may turn a plausible Slack comment into a product promise or reuse wording from an obsolete document.
A company brain built from selected business sources can give an AI agent permissioned, source-cited context from apps such as Slack, Notion, Google Drive, and Salesforce. Gyld exposes that context through MCP servers to AI tools that can use MCP. A reviewer can then inspect the cited source behind a proposed claim, subject to the source’s permissions.
Context still has limits. A cited sales discussion is evidence that a discussion happened; it is not approval to put a promise on the homepage. The agent’s CMS account still needs draft-only access, and the publishing workflow still needs its own gate. Teams weighing knowledge approaches can also compare a managed context layer with a RAG pipeline; neither approach replaces authorization at the point of publication.
What should you set up before the first agent edit?
Run one low-risk page through the full path before expanding access. The test should prove that the agent can help prepare a change and that it cannot publish around the reviewer.
- Choose a page and specify the fields the agent may propose changing.
- Give its CMS account draft access only. Test that a direct publish attempt fails.
- Require a diff, a reason, and source links with every proposal.
- Assign a reviewer and a publisher; decide which types of change need additional owners.
- Approve one revision, then alter the draft. Confirm the old approval cannot publish the altered version.
- Publish an approved revision, inspect the live page, and test the rollback procedure.
If any step relies solely on the agent remembering an instruction, move that control into permissions or the publishing workflow. For the broader question of who may authorize agent actions across a business, see AI agent governance for business.
Related reading
- AI Agent Governance for Business: Who Controls What Agents Do? — Map the people and permissions behind agent actions beyond the website.
- AI Agent Safety Is a Context Problem — Here’s Why — Examine how missing business context affects an agent’s decisions.
Frequently asked questions
Can an AI agent edit a website without publishing changes?
Yes, if the CMS or publishing API supports a draft state and the agent’s credentials lack publish permission. Test the restriction directly; a prompt telling the agent not to publish is not an access control.
Who should approve an agent’s website edit?
The owner of the claim or page should approve it. Product claims may need a product owner; terms and privacy changes need the relevant policy owner. The publisher can be a separate role if your process requires it.
What evidence should accompany an AI-generated edit?
Include the before-and-after diff, the agent’s reason, and links to the documents or records supporting factual changes. Record the revision that was approved so a later edit cannot inherit that decision.
Does MCP provide a publishing approval workflow?
MCP lets a compatible AI tool use capabilities exposed by a server, such as company context. It does not, by itself, approve a website change. Publishing permissions and approval checks belong in the CMS or the workflow that calls it.
Can better company context replace human review?
No. Source-cited context helps an agent draft and helps a reviewer verify claims. A source can be outdated or lack authority to approve public wording, so a designated person still needs to decide what goes live.
Start building your company brain with Gyld if your AI tools need source-cited business context for drafts. Keep your AI agent approval workflow in the publishing system that controls who can make those drafts public.