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