A safe publishing system for AI agents
Agents are good at preparing variants and operating repeatable workflows. Public delivery is irreversible enough that authority, review, and recovery must be designed as product states—not hidden inside a prompt.
A safe AI-agent publishing system lets an agent discover approved destinations, prepare destination-specific content, and create a reviewable publish plan. A human or separately authorized trusted workflow accepts the exact public output. Every delivery receives its own receipt, and ambiguous outcomes stop for reconciliation instead of being replayed blindly.
The safe default is prepared, reviewable, and one step short of public.
The common design mistake is treating “can call the API” as one permission. Reading recent campaigns, drafting a caption, connecting an account, and publishing to a public audience are materially different authorities. They should not share one credential or one confirmation.
An agent adds the most value before the irreversible step:
- turn a URL, article, transcript, or brief into structured source content;
- discover usable destinations and media;
- prepare variants that respect destination fields and limits;
- surface missing permissions, media, policy, or schedule details;
- freeze the exact proposal into a plan an approver can inspect;
- read delivery state and explain failures after publication.
The public action can remain fast without being invisible. A review screen can show the source, every destination version, account binding, media, schedule, and any warnings in one place. Approval then creates evidence, not just a conversational “yes.”
A reference state machine keeps intent and authority separate.
- Source accepted: validate a public HTTPS URL or bounded inline content; reject private-network fetches and oversized responses.
- Destinations resolved: list exact channel IDs, release status, format compatibility, account state, and safe defaults.
- Variants prepared: preserve the source and create an explicit destination payload for each target.
- Plan frozen: bind content, account, media version, settings, schedule, and idempotency key into an immutable plan.
- Human reviewed: an authorized workspace member sees the exact output and records a decision.
- Plan consumed: one atomic operation creates the campaign and independent destination deliveries.
- Delivery observed: attempts progress through queued, processing, published, retryable failure, terminal failure, or reconciliation required.
- Recovery chosen: retry only known-safe failures; otherwise edit, reconnect, cancel, or reconcile manually.
The plan should expire. Approval of “publish this text to this account today” must not become a reusable permission to publish different text next month. Consumption should accept a plan ID, not a replacement payload.
Eight guardrails make the workflow dependable.
Bind tokens to one audience and resource
For hosted MCP, validate that the access token was issued for the exact protected resource. Do not accept a token merely because its signature is valid. The MCP authorization specification and OAuth resource indicators exist to prevent a token for one service from being replayed against another.
Keep provider credentials out of model context
The agent needs safe destination IDs and capabilities, not the underlying OAuth refresh token, bot token, webhook secret, app password, or storage URL. Provider authorization belongs in the browser or another dedicated human-controlled flow.
Require stable idempotency keys
Bind each create or publish request to a caller-supplied key and a fingerprint of the full request. Exact retries should return the same resource. A changed request with the same key should fail rather than mutate the meaning of the original action.
Separate reads from writes
Reporting agents often need campaign and receipt access without any publishing authority. Connection mutations, media uploads, drafts, publish plans, and direct delivery deserve separate scopes.
Validate the exact destination copy
Workspace terminology, blocked terms, required disclosures, and platform limits must run against the final variant, not only the shared source. Keep private drafts saveable when possible; block the public action with a specific recovery message.
Bound selectors and fan-out
“All connected channels” should resolve to an explicit, reviewable list before approval. Set request, destination, media, and schedule limits so a malformed agent action cannot create an unbounded batch.
Recheck authority at execution
A plan can become stale after approval if a role changes, a channel is disconnected, a media object is replaced, or an entitlement expires. Revalidate every binding when the plan is consumed.
Treat unknown outcomes as a state
A timeout during a public write is not proof of failure. Store an explicit reconciliation state and attempt the safest provider-specific read or receipt check. Automatic replay is appropriate only when the operation is known to be idempotent.
Incident patterns reveal whether the safety model is real.
| Incident | Unsafe behavior | Safer response |
|---|---|---|
| Agent receives a 401 | Ask for or search logs for a stronger token | Return the missing scope and a human authorization path. |
| Provider times out on POST | Immediately repeat the request | Mark the outcome unknown, inspect provider evidence, then decide. |
| One of ten destinations rejects media | Mark the whole campaign failed or republish all ten | Keep nine receipts and repair only the incompatible destination. |
| Approval sits open for two days | Publish the old plan unchanged | Expire or revalidate account, media, schedule, policy, and entitlement bindings. |
| Prompt asks to “post everywhere” | Expand the selector and publish immediately | Resolve a bounded destination list and show it in the plan. |
A prompt can express intent. It should not be the only durable evidence of authorization, the exact public payload, or the delivery result.
The PostOnce.co agent model
PostOnce.co offers local stdio MCP and a hosted HTTP MCP endpoint alongside its REST API and repository CLI. They share the same workspace-bound content, channel, media, publish-plan, and delivery contracts.
Public agent delivery is browser-reviewed by default. The hosted flow uses workspace-bound OAuth, while higher-trust direct publishing remains a separate scope intended for explicit operator configuration. A caller can prepare an exact plan, send the human to its review URL, consume only the approved plan, and then inspect every destination result.
This model is a fit when an agent should perform substantial preparation and operational work without silently gaining account-connection or public-publish authority. It is not a claim that every catalog connector is generally available: verify the current connector status and the concrete API and MCP contract before designing the workflow.
Can an agent publish while I keep final review?
In PostOnce’s reviewed-publish flow, the agent prepares a plan containing the exact copy, media, accounts, settings, and schedule. An authorized person reviews that plan in the browser. The caller consumes the approved plan by ID; changing its contents requires another plan. See the integration example.
This enforced plan review is separate from the multi-step team approvals shown as a product preview. Hosted MCP does not receive the direct-publish scope. Paid Pro or Agency access and a compatible MCP client are required; support for a particular client should be verified rather than inferred from its name.
What should an agent do when a delivery times out?
Read the existing campaign result. If the outcome is uncertain, pause public writes and ask the operator to inspect the destination. Do not create a new idempotency key merely to force another attempt. Follow the recovery checklist so a missing response does not become a duplicate post.
Primary sources
- Model Context Protocol authorization specification — protected-resource discovery, issuer validation, least-privilege scope challenges, and HTTP transport requirements.
- RFC 9700: Best Current Practice for OAuth 2.0 Security — current guidance for redirect flows, PKCE, token protection, and authorization metadata.
- Mastodon API: statuses — an example of provider-supported idempotency and rich destination-specific fields.
- PostOnce.co API & MCP documentation — the product-specific scope, publish-plan, media, and delivery contract described in this guide.
- PostOnce.co security and data handling — implemented product controls and explicitly unclaimed certifications.