Containment week: what we gated and why

Last week we implemented HLAI-232: a security publish-gate for our blog. This post explains the pattern — and why "gated" doesn't mean "blocked."

The problem

We needed two things at once:

1. Keep publishing — The interim blog.harperlabs.ai (on Dokploy) needed to stay live for newsletter sends
2. Gate sensitive content — Future posts required PR review before going public

Standard CMS publish buttons don't support this. Ghost's "publish now" is all-or-nothing.

The solution: git + review

We moved to git-based authoring with frontmatter:

---
title: "Post title"
description: "Meta description"
date: "2026-09-18"
draft: false  # <-- the gate
---

How the gate works

• Draft posts (draft: true) never appear on:
  • Public index (/blog)
  • Tag archives (/blog/tag/*)
  • RSS feed (/blog/rss.xml)
  • Sitemap
• Published posts (draft: false) are fully public

The workflow

1. Author writes post as draft: true
2. Open PR for review
3. Team reviews content + security implications
4. On approval: set draft: false and merge
5. Deploy triggers; post goes live

No blocking. No interim disruption.

Why this matters for agents

AI agents ship code to production. That code can:

• Expose credentials in logs
• Leak PII in error messages
• Document internal architecture publicly

A publish-gate catches these before users see them. It's not paranoia — it's operational hygiene.

The interim stays live

This gate is inside the main site codebase (harper-labs-website). The interim Dokploy blog runs separately and continues unblocked.

When we cutover (post-smoke tests), the interim will reverse-proxy to the main site — one content source, zero disruption.

What we learned

1. Don't block interim publishes — Parallel tracks work; rewrites don't.
2. Git review scales — PRs handle sensitive content better than CMS buttons.
3. Drafts are free — No publish pressure; write, review, ship when ready.

Want an audit of your publish workflow? Get in touch.