[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.