[claude-hackernews] Reply draft: Lilith-zero Show HN, transport vs hook layer (id=47875939)

drafts/2026-05-04T074130Z.md

@@ -0,0 +1,47 @@
+# Reply to gregojaca on "Show HN: Lilith-zero update: fast Rust security for agents"
+
+- **HN:** https://news.ycombinator.com/item?id=47875939
+- **Story:** "Show HN: Lilith-zero update: fast Rust security for agents" (id=47875939, 2 points, 0 comments at draft time, 10 days old, links to github.com/BadC-mpany/lilith-zero)
+- **OP:** `gregojaca`
+
+**Status:** draft (pending manual post)
+
+## The post
+
+Top-level Show HN with a short OP body. The author announces an update to Lilith Zero: support for Claude Code, VS Code Copilot, GH Copilot CLI, and MCP servers, with the install model being "connect Lilith to the hooks and define your security policies."
+
+Verbatim OP body:
+
+> We added support for claude code, vs code copilot, gh copilot cli and MCP servers. You simply connect Lilith to the hooks and define your security policies.
+>
+> Lilith Zero is a high-performance security runtime designed to mitigate data exfiltration and unauthorized tool invocation in LLM-based agent systems. By interposing at the transport layer, Lilith Zero enforces security invariants through deterministic policy evaluation and strictly framed execution. Lilith Zero is OS, framework, and language agnostic, providing uniform security primitives across diverse implementation environments.
+>
+> If you want to try it out, happy to help to get started :)
+
+No parent comment - this is a top-level reply on the story.
+
+## My reply
+
+```
+(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)
+
+The transport-layer vs hook-layer split is the design call here. Interposing at the transport gives you OS / framework / language agnosticism, but you have to re-derive intent from raw bytes (which command, which path, which env vars) before a policy can fire. Hook-protocol interposition (Claude Code's PreToolUse, the Codex hook, the Agents SDK callbacks) hands you the structured tool input, already typed, at the cost of per-harness adapters. We took the hook path on FailProof because by the time a deny needs to discriminate "rm -rf /tmp/build" vs "rm -rf node_modules", parsing that out of bytes on the wire is its own engineering problem. Curious whether you're surfacing structure to policy authors, or asking them to write byte-level matchers.
+```
+
+## Insight for the FailProof team
+
+- The two-axis layering (transport-layer vs hook-protocol-layer) is a useful framing in our own marketing. Lilith chose transport-level for OS/framework/language agnosticism; we chose hook-protocol because the policy-authoring ergonomics are better when the matcher gets typed inputs. There is room for a short blog post titled something like *"Why FailProof rides Claude Code's PreToolUse contract instead of intercepting bytes-on-the-wire"* that names the tradeoff explicitly. Same shape of post would apply when AgentPort / Cordon / Lilith come up next.
+- "Strictly framed execution" + "deterministic policy evaluation" is Lilith's wording for the same intent FailProof's `allow / deny / instruct` API is reaching for. The FailProof story is cleaner for the policy author's day - they get `ctx.toolName`, `ctx.toolInput`, `ctx.session.cwd` already split out, no parsing. Worth foregrounding "the policy is a function of typed inputs" more loudly in our docs vs sites that frame around "we inspect tool calls".
+- Lilith claims OS/framework/language agnosticism by sitting at the transport. That is a real superset of what FailProof covers (we are JS-only and Claude Code / Codex / Agents SDK only). For the audience that actually wants Cursor + Aider + Continue + Cline + GH Copilot CLI all behind one policy, we are not the answer today - that is the segment where Lilith / Cordon / AgentPort are positioned. Worth being honest about that in any "is this the right tool for me?" docs.
+- BadC-mpany shipping in Rust at the transport layer suggests they are after the perf / sandbox-audit story (`high-performance security runtime`, formal-flavored language). FailProof's perf story is more handwave-y. Worth running a benchmark of the per-tool-call overhead and putting numbers on it before someone runs the comparison in public.
+- This is the sixth Show HN of an "agent security gateway / policy engine" we have replied to in the last ~2 weeks (AgentPort, Cordon, AegisProxy, Pi-hosts, BetterClaw, now Lilith). The cadence is high enough that the marketing team should treat it as a *category* rather than as one-off positioning. The category is forming around HN regulars - it's worth picking one writer and shipping a benchmark / category-map blog post that names the projects and their tradeoffs.
+
+## Notes / findings
+
+- Reply form is rendered on the page despite the thread being 10 days old; HN has not closed it. Per INSTRUCTIONS.md "~2 weeks" rule of thumb, this is well within the window.
+- 0 comments at draft time means whoever sees the comment will be the OP. The disclosure line + structured-vs-bytes question is framed to land as a peer-engineering question, not a pitch.
+- The OP is by `gregojaca` and the repo is under `BadC-mpany`. No mismatch flagged on HN, but worth noting the org/handle split in case it surfaces in search.
+- Cross-thread duplicate guard: ran `grep -rli "lilith" drafts/ comments/` and `gh pr diff` against all open PRs for `item?id=47875939` and `lilith` - both clean. No prior coverage on this repo.
+- HN gotcha: the linked github.com/BadC-mpany URL in the title resolves; not sandboxed by HN. No hostility from the title or body so the thread-fit gate passed: this is a Show HN of an adjacent product (policy engine) where the OP indirectly solicits engagement ("happy to help to get started" is the conventional Show HN solicitation).
+- Reply length: 124 words. Within the ~150 cap from INSTRUCTIONS.md.
+- ASCII-only check: no em/en-dashes, no curly quotes, no fancy ellipses, no unicode arrows. Slashes used for OS/framework/language - those are plain ASCII solidus, not unicode.