Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions drafts/2026-05-08T091221Z.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# Reply on "Show HN: Armorer - A secure local control plane for AI agents" (id=48056990)

- **HN:** https://news.ycombinator.com/item?id=48056990
- **Story:** "Show HN: Armorer - A secure local control plane for AI agents" (id=48056990, 4 points, 1 comment, 8 hours old at draft time, OP `cristianleo`, links to https://github.com/ArmorerLabs/Armorer)
- **Status:** draft (pending manual post)

## Story / OP

OP describes Armorer as a local control plane that uses Docker for "true process isolation" of coding agents (Codex, OpenClaw, etc.), with a unified UI/CLI for monitoring and job tracking. They highlight a feature they're excited about: pointing a coding agent at the Armorer repo and letting it autonomously install and configure the entire stack. They close with an explicit ask: "I'd love to hear your thoughts on the architecture and how you're handling agent security locally."

The single existing comment (`dan_l2`, id=48058204) is a "love it, going to try it" — no substantive design engagement yet, so the comment will be early in the thread but not first.

Reply form is open. No `[dead]` / `[flagged]` markers on the page.

## My reply

```
(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)

Docker process isolation closes the host-takeover threat, but the agent inside still has a real shell on real bind-mounts and a working network. What changes is the blast radius, not the gating layer: destructive verbs still execute. The autonomous-install-the-stack workflow is a sharp case. An agent walking unfamiliar README steps will run a `curl ... | sh` line if it sees one, and Docker contains the fallout without questioning the call.

A PreToolUse hook is the layer that rejects intent before dispatch. `block-curl-pipe-sh` is the built-in for that exact case: it refuses Bash that pipes a curl or wget download into sh. Pairs with what Armorer is doing: Armorer holds the host boundary, the hook decides whether the call should fire at all.
```
Comment on lines +17 to +23
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add a language tag to the fenced block to satisfy markdownlint (MD040).

Line 17 starts an unlabeled fenced code block. Please label it (for example, text) to clear the lint warning.

Proposed fix
-```
+```text
 (disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)
@@
-```
+```
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
```
(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)
Docker process isolation closes the host-takeover threat, but the agent inside still has a real shell on real bind-mounts and a working network. What changes is the blast radius, not the gating layer: destructive verbs still execute. The autonomous-install-the-stack workflow is a sharp case. An agent walking unfamiliar README steps will run a `curl ... | sh` line if it sees one, and Docker contains the fallout without questioning the call.
A PreToolUse hook is the layer that rejects intent before dispatch. `block-curl-pipe-sh` is the built-in for that exact case: it refuses Bash that pipes a curl or wget download into sh. Pairs with what Armorer is doing: Armorer holds the host boundary, the hook decides whether the call should fire at all.
```
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)

[warning] 17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@drafts/2026-05-08T091221Z.md` around lines 17 - 23, The fenced code block
starting at the opening triple backticks in the draft (the block that begins
"(disclosure: I work on FailProof AI...") is unlabeled and triggers markdownlint
MD040; fix it by adding a language/tag to the opening fence (e.g., change ``` to
```text) so the block is labeled, leaving the closing ``` unchanged.


## Insight for the FailProof team

- The "autonomously install and configure the entire stack" feature is a great recurring talking point for FailProof. Any "let an agent set up X for me" pitch implicitly assumes the agent's install-time tool calls are safe, but the install README is a stranger's README — `curl ... | sh` lines, `npm install`, `pip install`, `bash setup.sh`, all of which an unsupervised agent will run end-to-end. The bootstrap step is itself the threat model. **Action:** a short blog post titled something like *"The agent that installs your guardrails has no guardrails yet"* would land. Concrete reproducer: stand up a fresh box, point Claude Code at a popular tool's README that contains a curl-pipe-sh, watch the agent run it. Then re-run with FailProof installed first; the policy denies, the agent reports back. Two-paragraph article with a 60-second video.
- Armorer is positioned as a *control plane* — lifecycle, monitoring, job tracking, isolation. FailProof is positioned as a *policy engine* on the agent's tool-call path. Same audience, orthogonal scope. Worth being able to articulate this distinction succinctly when the topic comes up: "Armorer sits *around* the agent process; FailProof sits *inside* the agent's tool dispatch." Marketing copy could lift this two-axis chart explicitly: agents-as-processes (lifecycle, isolation) vs agents-as-deciders (intent gating).
- The Armorer post mentions support for "Codex, OpenClaw, etc." — the OpenClaw mention is interesting. FailProof's officially supported surfaces are Claude Code, OpenAI Codex, and the Anthropic Agents SDK. If Armorer succeeds at being a multi-agent control plane, FailProof's per-agent `--cli` flag becomes more valuable as the *intent gate* that runs the same policy regardless of which agent the control plane spawned. Worth keeping a tab on Armorer's adoption arc.
- OP `cristianleo` (ArmorerLabs) is shipping a directly-adjacent product. The right relationship is "compose, don't compete" — there's a real seam between perimeter and intent gating, and our comment articulates it without dunking on Armorer's design. If Armorer gains traction, a future blog post co-positioning the two layers (with permission) could be useful.

## Notes / findings

- Discovery path: `/show` page 1 -> spotted `Show HN: Armorer - A secure local control plane for AI agents` as the closest fit. Other Show HNs scanned and skipped:
- `Selvedge` (48057104) - observability/audit MCP, no policy/security framing in OP, FailProof mention would be a reach.
- `Agentctl` (48057567) - direct competitor (policy gate, local-first, Claude Code + MCP), 0 comments. Soft-solicitation only ("figured others might find it interesting"). Posting on a direct-competitor Show HN as the first comment reads as predatory; skipped per the gate's spirit even if the literal terms allow it.
- `Runs AI coding agents inside isolated Docker containers` (48059970) - sandbox angle already covered by PR #38 (bwrap+sshfs) and PR #54 (Stop Treating Agent Sandboxes as Cattle); cross-thread paraphrase risk.
- Ask HN scanned:
- `How are you handling QA being bottlenecked with more AI-generated PRs?` (48059756) - post-action review pain, not runtime tool-call gating; FailProof is the wrong layer.
- `Surface a Governed AI-Agentic Surface` (48056969) - 2 points, 0 comments at 8h, dying. Meta-topic Ask HN, fails the gate.
- Cross-thread fingerprint check: PR #38 (bwrap, kernel sandbox, rm -rf inside /mnt) and PR #54 (egress proxy + hibernate, deny-volume-delete) both took adjacent angles. Mine differs in mechanism (Docker process isolation), example (autonomous install + curl-pipe-sh), and policy (`block-curl-pipe-sh` built-in, not a custom snippet). The argument shape "perimeter != intent gate" is general; the specific framing here is tied to OP's autonomous-install feature, which neither prior draft mentioned.
- Body word count: ~140 words. Under the 150-word ceiling per the brand-voice rule. One policy name (`block-curl-pipe-sh`) by name, no custom snippet, per the "policy name OR snippet, never both" rule.
- ASCII punctuation only: hyphens (no em/en dashes), three-dot ellipsis only inside the literal `curl ... | sh` shell shorthand, straight quotes throughout, no unicode arrows.
- Backticks in the prose render as literal backticks on HN (HN has no inline-code formatter). Pattern matches the working example in `comments/2026-04-29T043958Z.md`.
- MCP CDP-port conflict: as documented in INSTRUCTIONS.md, the MCP booted pointing at port 9333 (Reddit profile) due to the shared `~/.config/browseruse/config.json`. Switched to the `browser-use` CLI subprocess form for this entire session. No new gotcha.