Human in the Loop for AI Social Posts: Approval Checklist

Human in the loop for AI social posts means an agent may draft and schedule, but a named person approves each post before it is published, or approves the template behind the routine posts you have decided can go out unattended. A line in the prompt that says “ask me first” does not do that, and this page argues that the hold belongs in the scheduler, at its publish step. OWASP’s guidance for applications built on language models uses this exact case: an app that posts social media content for a user “should include a user approval routine within the extension that implements the ‘post’ operation”.

This page covers where that gate sits in tools that work today, which posts can go out without a person, who approves for a client, and an eight-point checklist for the approver. If an agent using a scheduler is new to you, start with what an agentic social media scheduler is.

What human in the loop means for AI social posts#

A human-in-the-loop approval workflow is a rule: a post an agent creates waits until a person releases it, unless it is a type you have decided can go out unattended. In the fullest form a post moves through four states: drafted, waiting for approval, scheduled, published. Not every tool has all four: Buffer has a waiting-for-approval status and Postiz does not, as the section on two schedulers shows in each tool’s own words.

The term itself does not say where the hold sits. The Model Context Protocol, which assistants use to call a scheduler’s MCP server, says of tool calls in general: “For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.” What it asks of applications is to “Present confirmation prompts to the user for operations, to ensure a human is in the loop”. (MCP specification) So the protocol’s human in the loop is a prompt in the app, and the word is SHOULD: a recommendation to the client application, not something the protocol enforces. For AI agents that post through a scheduler, whether you are asked depends on the app you use.

This post argues for more than a prompt. For social posts, three parts make the hold real:

1. The agent can create posts but cannot publish them itself.
2. A named person can approve, edit or send back.
3. The hold is enforced by the system that publishes, not only by the chat app.

Why the gate belongs at the publish step, not in the prompt#

A prompt is a request. A permission is a rule.#

An instruction in a prompt is text the model weighs along with everything else it reads. That sentence is our reasoning. Two sources place the decision outside the model:

• OWASP, under “Require user approval”, says the approval “may be implemented in a downstream system (outside the scope of the LLM application) or within the LLM extension itself.” Under “Complete mediation”, the same page says: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” (OWASP LLM06:2025)
• OpenAI, to developers of MCP servers, about the hints a tool can carry: “Annotations help ChatGPT and Codex choose appropriate confirmation and safety behavior. They do not replace authorization, validation, or confirmation in your server.” (OpenAI’s developer guide)

The protocol also tells clients not to trust a tool’s own hints: “clients MUST consider tool annotations to be untrusted unless they come from trusted servers.” (MCP specification)

The assistant’s own confirmation can be switched off#

A confirmation in the chat app is useful. It is also a setting of that app, which the person using it, or their admin, can change. If you are posting from Claude, the prompt you see before a tool runs is the first row of this table. Each quote is the vendor’s own wording. Where the last two columns link no source, they are our reading.

Buffer’s advice for its own MCP server begins “Leave the approval prompts on” and ends “that prompt is your last chance to catch a misread instruction.” (Buffer developer docs) “Last chance” is the vendor’s own phrase for a prompt that, in Claude for one, can be set to Always allow.

The ChatGPT row has a longer answer for one network: what Instagram requires before ChatGPT can post.

Other routes never show a prompt at all#

An API key or a CLI token is used by scripts and automations with nobody at a screen. Buffer: “The connection covers your whole account. An API key acts for your account and reaches every organization and channel in it.” (Buffer developer docs) In Postiz’s table “API key or OAuth app?”, the “Acts as” cell for an API key reads “You”. (Postiz docs)

Posts built from a web page or a feed also carry text the agent did not write. OWASP: “Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files.” One of its mitigations is to “Implement human-in-the-loop controls for privileged operations to prevent unauthorized actions.” (OWASP LLM01:2025)

The only place every route passes through is the scheduler’s publish step, so that is where the hold has to be.

How two schedulers hold a post today#

According to each vendor’s documentation, checked October 12, 2026. We did not run either tool. “Not documented” means the pages read do not say.

Buffer: a permission that turns every post into a draft#

In Buffer the mechanism is a role on a team member, not a switch on the agent. Buffer’s pages call it both “Needs Approval” and, on the API help page, “Requires Approval”. This post uses the first name.

There is a catch for a one-person account. The role is a Team plan feature, and Buffer adds: “On Free or Essentials, there’s only one user (the account owner).” The owner cannot be given the role, so an agent connected with the owner’s own key or sign-in is not held by it. What remains is the saveToDraft option (“Save as a draft instead of scheduling it”, Buffer developer docs), which the agent chooses, plus the chat app’s prompt.

Buffer documents a workaround for owners who need their own posts approved: “you can create another Buffer account for yourself with a separate email address and create your drafts to be approved when signed into that user profile.” (Buffer’s agency page) Read next to the table’s row on the API and the MCP server, the same arrangement would put an agent’s posts behind approval. That is our reading of two Buffer statements. Buffer does not describe it as a setup for agents, and nobody at Postnavo has run it.

Two Buffer pages disagree. The Buffer MCP product page says: “Everything goes through your Buffer queue, so nothing publishes without you seeing it first.” The developer documentation, quoted in the table, says the tool can publish immediately, and the product page’s own FAQ says posts “land in your Buffer queue as drafts or scheduled posts.” A scheduled post publishes at its time whether or not anyone looked.

Postiz: drafts and a preview link, with no blocking state#

What follows is our reasoning. In Postiz the draft is a convention the agent is asked to follow, and Postiz’s advice for its own agent reads that way: “Ask it to draft rather than publish while you are getting a feel for it.” (Postiz docs) Its MCP tool accepts now (MCP tools reference). The create-post page says of a draft: “You can promote it to a real post later from the Postiz UI.” (Create Post) The status endpoint in the table shows the API can promote a draft as well.

Which posts can go out unattended, and which need a person#

This table is our recommendation. None of the network pages read for this post gives a rule that says which posts need a human. Where a network’s own page supports a row, it is cited. Where none does, the cell says so. Three questions decide each row: can it be fixed after it is live, does it speak to or about a person, and did a person already approve the substance.

On X, the account holder carries the result either way: “You are ultimately responsible for the actions taken with your account, or by applications associated with your account.” (X automation rules)

What you can still fix after a post is live#

Only networks whose help page was read are listed. The others are left out, not guessed.

We read a post sent through a scheduler as one of those “Posts from a third-party service”. X’s page does not define the term. If that reading is right, on X the check before publishing is the last one short of deleting the post.

Who approves for a client#

Two ways are documented today.

• Buffer, by account. “If posts need approval from clients, you’ll set your staff up with Requires Approval access and your clients with Full Posting access for the social channels they’ll be working on.” It is all or nothing per channel: “It is not possible to pick and choose which posts require approval.” (Buffer’s agency page) The client is invited as a user, so the client needs a Buffer login. Do not make the client an Admin as a shortcut. The same page warns: “Admins have the ability to manage any social channel connected to your Buffer organization.”
• Postiz, by link. The client opens the preview page from the table, with no Postiz account, and sees that post only. You still move the post yourself, and the link is open to anyone who has it: “A preview link is not password protected. Anyone with the URL can read the post and comment, so treat it as unlisted rather than private.” (Postiz docs)

The rest of this section is our advice, with no source behind it:

• Name one approver per client, and one stand-in.
• Agree a cut-off time before each slot.
• Agree in writing what silence means. Our default: no reply means the post does not go out.
• An approval covers the exact text, media, account and time that were shown. Any change after approval needs a new approval.
• Keep a record of who approved what, and when.

Buffer shows part of that record: “you can see who created each post in the queue.” (Buffer help) Whether either tool keeps a log of who approved a post is not documented.

Agents change one thing here: volume. An agent can draft more posts than a person has time to read, so the approver becomes the bottleneck. The decision table above is how you keep the approver’s list short. That holds for agencies running client calendars, for marketing teams with an approver in house, and for marketers who already draft with ChatGPT or Claude and approve their own posts.

Set it up in four steps#

1. Take publishing away from the agent. Use the scheduler’s hold where one exists, such as Buffer’s Needs Approval permission (Buffer help). That one needs the Team plan and an agent connected as a member with that permission, not as the owner. The route is our reading of Buffer’s pages and was not run by us: see the Buffer section. Where none exists, have the agent create drafts only, as with the draft type in Postiz (Create Post), and know that this is a convention.
2. Keep the chat app’s confirmation on for tools that write. In Claude that is the “Needs approval” setting (Claude docs). Buffer gives the same advice for its MCP server (Buffer developer docs).
3. Sort your post types with the decision table and write the result down.
4. Give the approver the checklist below.

If the agent runs in a workflow tool instead of a chat assistant, n8n documents human review for tools: “If approved, the tool executes with the AI-specified input. If denied, the action is canceled and the AI is informed of the rejection.” (n8n docs)

The approval checklist#

Eight checks. Read the post as it will appear, on the account it will go to.

1. Account, network, time. Is this the right account and network, and is the time right in the audience’s time zone?
2. Facts. Is every number, price, date, name and quote true? Check each against the source the agent used, not against the draft.
3. Links. Open every link. Does it go where the post says, and does the preview show the right page?
4. Voice and timing. Would you say this, in these words, today? Has anything in the news changed how it reads?
5. Media. Is it the right image or video, do you have the right to use it, and is the alt text there? If video or audio was made or changed with AI, is the label set where the network requires one? (Instagram Help, YouTube Help)
6. People. Does it mention, tag or reply to anyone? If so, a person wrote or rewrote that part. (Why: X’s automation rules restrict automated replies and mentions.)
7. Repeats. Is it a near-copy of something this account, or another of your accounts, already posted? (Why: X’s rule against duplicative posts, in the same automation rules.)
8. Undo. If it turns out wrong, can it be edited on this network? If not, read it once more. See what you can still fix.

Each review ends in one of three outcomes: approve, send back with a note that says what to change, or reject. Anything changed after approval is approved again.

Questions people ask#

Is telling the agent to “always ask before posting” enough?#

No. It is a request to the model, and the chat app’s own prompt can be set to skip. Put the hold in the scheduler, for the reasons under why the gate belongs at the publish step.

Can a client approve posts without logging in to the scheduler?#

In Postiz, yes, for review and comments, through a preview link that needs no account. In Buffer the client is invited as a user, and a link that works without a Buffer account is not documented: see who approves for a client.

Can I edit a post after an agent has published it?#

On X, original posts and Quotes not on the list of excluded types can be edited for 1 hour with X Premium, and we read a scheduler’s post as an excluded type. Threads and LinkedIn allow text edits only: the limits are under what you can still fix.

Who is responsible if an AI agent posts something wrong from my account?#

On X, you are: its automation rules make the account holder responsible for what the account and its connected applications do, as quoted under the decision table. Other networks’ terms were not read for this post, and this is not legal advice.

Do AI-written posts need an AI label?#

Neither page read for this post asks for a label on text. Meta requires one for photorealistic video and realistic-sounding audio but not for images, and YouTube for realistic altered or generated content: both quotes are in the decision table.