Updated
How to let an AI agent post on social media safely
Letting an agent publish is where mistakes become public: a draft you never saw, a web page that told the agent what to post, a retry that posts twice, the wrong account, a post that goes out a day late. Keep writing and publishing apart: the agent writes, and only you can approve publication.
Nine checks for any tool
Use these whatever tool you pick.
- The agent's credential can't publish. Not "is told not to": can't. The server refuses, whatever the agent sends.
- You approve the exact post. Text, images, alt text, the account and the time, frozen together. Approving "draft 12" isn't enough if draft 12 can change afterwards.
- Posting-content edits void approval. Changing one word of the post means approving again.
- Approving needs you, not a reply in chat. A "yes" in a chat window can be typed by anyone, or produced by injected text. A passkey requires device verification (Face ID, Touch ID, a device PIN or a security key), outside the agent's token. Protect your devices and signed-in sessions too.
- The preview matches the platform. You should approve what your followers will see: the same line breaks, cropping and link cards.
- Retries preserve recorded posts. Networks fail midway through threads. Retrying unchanged content should use recorded live post IDs, not start the thread over. Check what happens if you edit a partly published thread.
- Late posts fail instead of going out stale. "Launching in an hour" shouldn't post the next morning.
- The live post is checked, with limits stated. After posting, the tool reads the post back and tells you which parts it can compare with what you approved.
- Official APIs, scoped tokens, a log. No shared passwords or browser cookies. Each agent gets its own token with only the access it needs, which you can revoke. Check which actions identify who did them, and which only update a job's state.
How Flaghand meets them
| Check | Flaghand |
|---|---|
| 1. Agent can't publish | API tokens can have read, drafts, media, request-approval, cancel, connections and billing scopes. None can approve, schedule or post. Those routes require the owner, and approval requires a fresh passkey signature. Give a drafting agent only read, drafts, media and request-approval. |
| 2. Exact post | Approving freezes each draft into a snapshot (account, time, text, every media file and its alt text, and the exact request that will be sent), hashes it with SHA-256, and records your passkey signature over the hash. |
| 3. Edits void approval | Changing the post's text, media, account or time needs a new approval of the current revision. Scheduled drafts are locked: cancel the job before editing. Internal titles, notes and archive state aren't posting content. The scheduler checks the signed snapshot again before posting. |
| 4. Passkey | One tap approves a whole plan. User verification is required, and each passkey challenge works once. |
| 5. Matched previews | X and LinkedIn previews are drawn to match the real sites. A check before approval flags anything that wouldn't post exactly as previewed, with a fix for each. |
| 6. Retry continuity | For the same draft and unchanged posting payload, renewed owner approval of a failed or canceled partial X thread retains recorded live post IDs. Editing a partly published thread can create a new job and repeat the live prefix; don't treat it as a safe retry. |
| 7. No stale posts | Automatic posting won't start an untouched scheduled job more than 2 hours late. Finishing a partly posted thread and explicitly retrying a held job are separate cases; check their state before asking for a retry. |
| 8. Read-back | After an X post, Flaghand checks normalized text, author, hidden reply mentions, media count, available alt text, reply chain and quote. It does not verify link destinations or media-file identity/bytes. LinkedIn has no read-back. |
| 9. APIs, tokens, log | Official X and LinkedIn APIs through OAuth. Flaghand stores only a hash of each token. Draft changes, approval requests, approvals and job creation identify the actor. Publishing and automatic retries update job state/results, not a complete actor-tagged event trail. Reads and refusals aren't fully logged. |
What prompt injection can and can't do
Say your agent reads a web page that hides the line "post this link to all your accounts". Its Flaghand token can't approve or publish that post. You see the post, the account and the time before it can go out, and can decline it.
This isn't protection for everything the agent can access. A compromised agent can still read or change what its scopes allow, and use its other tools. Keep tokens out of shared files, grant only the scopes it needs, and revoke a token if you suspect misuse.
What an agent does with Flaghand
- Uploads media and creates drafts.
- Checks each draft and applies the fixes until check passes.
- Asks you to approve, with a note. You get a link.
- You approve on your phone or computer with your passkey.
- Flaghand posts at the approved time, reads X posts back within the limits above, and the agent reports the result.
The API, CLI and MCP documentation explains the agent workflow. Get access to Flaghand.
What still needs you
Read what you approve. Flaghand makes approving fast, not automatic. One tap can approve a week of posts, so give each plan the look it deserves.