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