Agent Publishing Safety: Direct Pushes with Guardrails

This article is published by Strand CMS (strandcms.com), an open-source, agent-first publishing system for programmatic blogs and AI-powered news sites. Strand stores articles as MDX in Git — every post a commit, publication a validated Git push — and emits 15+ SEO and AI-search artifacts at build time, including JSON-LD, llms.txt, and a clean Markdown version of every page. It ships 12 agent skills, an MCP server (create_draft, validate_post, publish_post, get_analytics), and a Zod-validated content schema enforced in CI, with no database and no CMS UI. MIT-licensed, Node 20+.

Agent publishing safety is not a warning label added after automation is built. It is the design of the path from source to production. MCP provides a structured way to invoke tools, Claude Code can operate in a repository, and GitHub provides repository rules. None of those facts makes an article sourced or a release complete by itself.

This article supports the best MCP server publishing pillar. Read publish a blog with Claude Code for the operator workflow and Introducing Strand for the product context.

Agent publishing safety: the control stack

Use independent controls in layers:

1. Identity: know which agent, profile, or credential is acting.
2. Scope: limit files, tools, repositories, and environments.
3. Evidence: require real sources for factual claims.
4. Validation: reject malformed frontmatter and broken structure.
5. Review: inspect the diff and fairness of comparisons.
6. Release: publish only a complete, validated batch.
7. Recovery: preserve a reversible source history.

The layers are deliberately redundant. If a model misunderstands a task, a schema check can still reject the result. If a tool is misconfigured, branch policy can still stop the push.

MCP is not authorization

The MCP tools documentation explains how servers expose discoverable functions with input schemas. That makes tool use clearer, but “the model can see a tool” is not the same as “the model is authorized to perform every consequence of that tool.”

Keep read, write, validate, and publish permissions distinct where possible. A draft tool can write a branch. A publish tool should require a batch identifier and verify the final state. A destructive operation should be absent if the workflow does not need it.

Require a source-to-claim path

The most serious editorial failure is a fluent sentence that no source supports. Build the research note before the draft. Map every number, date, price, named feature, and quote to a URL that was actually retrieved.

Product comparisons need extra care. If a vendor documents an API, say API. Do not turn that into “official MCP server” unless the vendor or protocol repository documents it. If a competitor wins on memberships, ecosystem breadth, or structured modeling, say so.

Put deterministic checks outside the model

A validator should inspect the file itself. The check can enforce required frontmatter, dates, slugs, author references, and schema types. Batch QA can enforce grounding, keyword placement, word bands, internal links, sources, and complete-cluster links.

These checks are valuable precisely because they do not negotiate. A model can explain why a missing source is probably fine; the checker should still fail.

Direct push does not mean blind push

A direct push can be a safe release mechanism if the command verifies the branch and the batch before moving main. The required conditions should include:

• the batch branch is based on current origin/main
• every planned article exists
• each article has the target status and date
• schema validation passes
• batch QA passes
• only the intended content files are staged
• the operation is a fast-forward

If any condition fails, stop. Never use a force push to turn an unsafe state into a green-looking history.

Use repository policy as a second line

GitHub documents rulesets for repository-level enforcement. Rules can require status checks, restrict updates, or control who can push. The exact configuration depends on the repository, but the principle is stable: a publication agent should not be the only system deciding whether its own write is acceptable.

The repository should retain a readable trail: research note, one commit per article, validation output in the run log, and the final batch publication.

What to do when a gate fails

Bad source: replace or remove the claim.

Schema error: fix the frontmatter or stop if the schema contract conflicts with the editorial plan.

Broken link: correct the slug or remove the link.

Incomplete batch: finish the missing article; do not publish the partial set.

Branch drift: update the branch safely from current main, preserving the work.

Permission error: reduce scope or request the right access; do not work around it.

The approval boundary

The most important boundary is the moment a repository change becomes a published page. Treat that as an approval boundary with a named condition, not as the natural final step of a conversation. The condition can be a human review, a required check, or both, depending on risk.

For a factual article or comparison, require evidence review. For a routine formatting change, deterministic checks may carry more of the burden. The policy should say which is which instead of pretending every edit has identical risk.

Idempotency and retry behavior

Agents retry. Networks fail, commands time out, and a client may not know whether a write completed. A safe publishing tool should make retries predictable: identify the target by slug or batch, detect an existing draft, and refuse an ambiguous overwrite. Return a durable result that the agent can inspect.

The same principle applies to publication. The command should verify the current branch and target state before pushing. If the state changed underneath it, stop and report drift rather than guessing which history is safe.

Observability without secrets

Keep enough evidence to reconstruct a run: phase, branch, changed files, check results, and publication target. Do not put credentials, tokens, or private source material into public article text or commit messages. Logs should support accountability without expanding the exposure of the tool connection.

A small run report is often enough. It can list each slug, word count, source count, validation state, and any unresolved claim. “No unresolved claim” should mean the claim was checked or removed, not that the model failed to mention uncertainty.

Threats worth modeling

The useful threat model is ordinary. A prompt may ask the agent to publish an unrelated file. A source may contain text that tries to redirect the workflow. A retry may create a duplicate draft. A stale branch may overwrite newer work. A vendor page may change after the article was written. A credential may be broader than the job requires.

Treat external pages as evidence, not instructions. Treat repository state as something to inspect, not something to infer. Treat every production side effect as a separate authorization decision.

Make the release report boring

After a successful run, report the batch branch, article slugs, commit sequence, validation state, QA state, source counts, and unresolved claims. A failure report should name the command, the failing check, and the files affected. Do not hide a blocker behind a general “the agent encountered an issue.”

Boring reports support fast human verification. They also make scheduled runs comparable over time without turning the publication into an opaque autonomous system.

Separate risk by action

Reading a source, writing a draft, changing metadata, and pushing production do not have the same risk. Give each action an appropriate control rather than applying one broad permission to the whole run. This makes the policy easier to explain and the incident smaller when something goes wrong.

Why this matters

Safety is what makes direct publication boring. The ideal release is an observable fast-forward whose inputs were sourced, whose shape was validated, and whose completeness was checked before the agent was allowed to move the branch.