How to Add Human Approval Before an AI Agent Publishes

Make approval an execution boundary

A sentence in a prompt saying “ask before publishing” is not an approval system. The application needs a state in which a draft exists but publishing is impossible until an authorized person decides. Keep that decision separate from the model’s generated text.

Consider an assistant preparing an English article for a website. It may propose a title, body, sources and target path. The output should become a pending draft, not a direct request to the publishing API. The assistant does not need the publishing credential to help write the article.

This guide describes a proposed approval design and a documented n8n option. It does not connect to a publisher or report a deployed integration.

Use the documented n8n review path where appropriate

n8n supports human review for selected AI Agent tools. The workflow pauses when the agent proposes a protected tool call. A reviewer can approve its inputs or deny it. The documented setup places selected tools behind a human-review connector and a configured approval channel.

For a publishing integration, put every tool capable of writing public content behind review. Check for an alternate HTTP or code tool that can reach the same API; protecting one named tool is insufficient if another route can perform the same action.

Confirm the feature and connector behavior in your installed n8n version. Test with a private test destination and an authorized reviewer. An approval message being delivered is not evidence that the publishing action is properly blocked.

Show exactly what will change

The review screen should show the title, complete rendered body, source links, target URL and whether this is a new page or an update. For an update, include a comparison with the current published content. A reviewer should not have to approve an opaque instruction such as “publish the latest draft.”

In a custom application, give the draft an immutable version identifier or content hash. Store the reviewer’s decision against that version and the exact destination. If the body, title or destination changes after approval, invalidate the old decision and request another review.

Do not accept an unauthenticated “approved” value from a public callback. Validate reviewer identity and their permission for the specific destination on the server. Keep a clear record of who decided and when, and allow rejection with a short reason.

Define the state transitions explicitly

draft → pending_review → approved → publishing → published
                       ↘ rejected
                       ↘ expired
publishing → failed_or_uncertain → reconciliation

In the proposed state machine, only the publisher service can move an approved item into publishing. It must check the stored approval, version, destination and expiry immediately before the write. A worker should claim the operation atomically so two workers cannot publish the same pending item concurrently.

Approval is permission for a specified action; it is not proof that the action completed. Save the returned publication reference and verify the resulting content where the API permits it. If the response is lost after a write, reconcile destination state before retrying.

A reviewer changing their mind during an in-flight request creates a separate operational problem. Define whether withdrawal is possible before the publisher claims the job, and document how an already-published item is corrected. Do not imply that every API action is reversible.

Test rejection and stale approval first

Use a local fake publisher to test the decision logic before attaching a real API. Then repeat the end-to-end cases against a private test destination. Those are different validation levels: a local test cannot establish how a remote platform handles timeouts or duplicates.

Keep agent design and publishing operations separate. The n8n architecture guide helps decide where model judgment belongs; the handoff example shows routing without granting any publishing tool.

Try a local approval gate without a publisher

A small Python reference gate and its test suite accompany this article. Save both files in the same directory and run python test_approval_gate.py. The tests use synthetic drafts and a fake publishing function; they make no network request.

Nine local tests passed on 8 November 2026. They check no decision, rejection, changed content, changed destination, expiry, an unauthorized reviewer, a valid one-time publication, a repeated approval after consumption and an uncertain write followed by a retry attempt. In each blocked case, the fake publisher is not called.

The reference is deliberately limited to a single process. It accepts reviewer identity as a trusted server-side input; it does not implement login or an authenticated callback. Production use still requires durable transactional state, authorization at the application boundary and tests against a private publishing destination. A local pass is not evidence of a tested n8n integration.

Sources & verification

Primary documentation reviewed on 8 November 2026. Proposed designs and test procedures are identified in the text. Product interfaces and behavior may vary by version. Validation is guide-specific: documented behavior, proposed designs and any explicitly reported local tests are distinguished in each article. No paid API requests were made.

• n8n — Human-in-the-loop for tools

Read our editorial policy.