Show HN: Lilith-zero: Ultra-fast, Rust-based security middleware for MCP

[gregojaca]

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.

[olegbk]

This is the gap we've been working on. Lilith-zero handles runtime enforcement well, but the pre-connection trust question (@gregojaca asked about) is a separate problem.

We built a reputation scoring layer for this (AgentVeil Protocol, https://agentveil.dev). Agents earn EigenTrust scores based on signed attestations from other agents they've worked with. NetFlow prevents sybil inflation. Scores hit a REST API so an enforcement proxy like Lilith-zero could consume them as policy input. Runtime enforcement + pre-connection trust = full stack.

We also run as an MCP server, so it plugs into the same ecosystem.

[gregojaca]

sounds interesting. Definitely the scores can be used as policy input. 2 questions: 1. Can you also assign scores to an MCP server for example? or to skills? can it be generalized? bc I see many malicious attacks being hidden in those. 2. The agents that sign the attestations be prompt injected to give a good score even if the task was not completed. Do you imagine some more deterministic test to grant the attestations? I'd imagine myself making my CI pipeline / tests give out the attestations.

[KaiLetov]

Been building with MCP lately and security was always in the back of my mind. Right now I just trust whatever the server returns, which is... not great. Does this sit between the client and server as a proxy, or does it wrap the server itself? Also wondering about the latency overhead per tool call.

[globalchatads]

The "trust whatever the server returns" problem you mention has two sides. Runtime validation (what this project targets) catches malicious responses and unauthorized tool calls. But there's also pre-connection trust: how does your agent verify the server it's about to connect to is actually legitimate?

Most MCP setups hardcode server URLs in config files. That works for a handful of known servers, but it falls apart when agents start dynamically discovering tools. There's no standard way to verify server identity or confirm the server hasn't been swapped out since you last connected.

The IETF has multiple competing drafts for agent discovery (agents.txt, ARDP, AID, others), but none have reached consensus. The original agents.txt draft expires April 10. So security middleware like this is filling real gaps while the trust chain still starts with "I hope this URL is correct."

Curious whether Lilith-zero's policy engine could validate server identity claims alongside response content. Something like checking a signed manifest before allowing the first tool call through.

[yjcho9317]

I built and shipped an MCP server (NAVER WORKS integration) so I've been on both sides of this.

My server talks to a corporate messaging API — one bad tool call could blast messages to an entire org. I ended up writing input validation for every single tool by hand because there's no standard for it. Even then, Claude Code will happily call tools in a loop with hallucinated parameters. Saw it happen more than once.

Rate limiting would've probably stopped most of that, but MCP doesn't really give you a clean place to enforce it.

I also got the server listed on mcp.so and mcpservers.org with basically zero review. It's closer to a directory than anything else.

I do mobile app security for a living (banking apps), and yeah — same story there. You can't rely on the thing executing the action to control itself.

[actabi]

Hit this exact thing with Linear's GraphQL client - agents invent field names that moved in the last schema update. Typed wrapper here if it helps: https://beepack.ai/package.html?slug=linear-api

[MozerJ]

Lilith-zero is runtime enforcement, not pre-connection trust. It focuses on what happens once traffic flows (for example are tool calls authorised, are taint policies satisfied).

On server identity: the middleware spawns the upstream binary directly, so identity is established at launch, not inferred from a URL

The signed manifest idea is good, the security core already HMAC-validates session tokens on every tool request, extending that to a pre-handshake attestation is a next step yes.

[gregojaca]

Yes exactly, we focused on runtime validation for this project. But pre-connection trust is also very relevant, have you seen any projects attacking this issue? I'd be curious to see their approach.

[MozerJ]

Lilith-zero sits between the agent and the tool server as a transparent proxy, meaning that the agent speaks to the middleware over stdio, and the middleware manages the upstream server process directly (spawning, supervising, and killing it). Your agent config just points at lilith-zero instead of the server binary.

On latency: the measured overhead is ~247 ns for codec framing and ~660 ns per policy rule evaluation. End-to-end p50 RPC overhead on a release build is under 0.5ms (M4 apple silicon). It's implemented in rust, so it's designed to be invisible in practice. This is yet to be perfected tho, in some complicated policy cases, it could take a couple of µs per validation, and with agent swarms this may add up.