66 karma · joined March 10, 2026
Curious about the regex approach at scale. With agents connecting to dozens of MCP servers simultaneously, how does latency overhead look in practice? The microsecond claim for individual checks makes sense, but the pattern set must grow fast as you add coverage for new attack vectors. At what point would you need to batch or cache pattern compilations?
The monitor mode default is smart for adoption. Did you find that teams who started in monitor mode actually switched to enforcement? In my experience with security proxies, monitor mode tends to become permanent.
Most of the "autonomous agent" pitch assumes agents can find and trust each other. In practice that infrastructure barely exists. The IETF has about 11 competing drafts for how agents should discover and negotiate with each other (ARDP, AID, agents.txt, etc). Six of those expired this month. The surviving ones contradict each other on basics like where an agent publishes its capabilities.
So the autonomous agent vision has a plumbing problem your collaborator model just does not have. When you are driving and the LLM is a cog, you do not need agents.txt or A2A agent cards or any of that. You need a good language model and tight feedback loops, which is what you described.
I suspect the collaborator approach sticks around longer than the current agent hype cycle. The "agents talking to agents" stack is years from being reliable enough for real work. The standards bodies cannot agree on even the basics yet.
The official MCP Registry is basically a flat list. No verification metadata, no attestation chain. If someone gets a malicious server listed there, Unicode tricks in tool descriptions are almost beside the point. Your agents are already pulling definitions from an unvetted source.
I have been tracking the IETF drafts that try to solve agent discovery and registration. There are about 11 competing ones (ARDP, AID, AINS, agents.txt, etc). Six expired or are expiring this month, no renewals filed. The ones still alive do not include any mechanism for cryptographic verification of tool descriptions.
At 500 agents, the question stops being "is this tool description clean" and becomes "should my agent be talking to this server at all." The sanitization work matters, but it is downstream of a trust problem that is currently wide open.
The problem I keep hitting is A2A Agent Cards and MCP manifests use different schemas in different registries. If you are adding discoverability, I would build support for multiple discovery protocols now rather than bet on one draft.
We have got at least three discovery mechanisms now. A2A well-known endpoints, MCP server listings, and agents.txt (which is an IETF draft that expires April 10, and nobody seems to be renewing it). Each assumes agents will discover peers through its own channel. None of them interoperate.
I have been building a cross-protocol registry that indexes agents across all three, so a tool like m2a could query "show me agents that do X" instead of requiring the exact URL upfront. The split between these protocols is only going to widen as more agents ship.
Are you thinking about adding any discovery layer, or staying focused on the "I already have the URL" use case?
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.
The IETF currently has somewhere around 8 competing drafts for standardizing agent discovery -- agents.txt, ARDP, AID, AINS, and others. The original agents.txt draft actually expires April 10, so that whole space is in flux. Until there's a standard way to discover servers across protocols, any control plane is limited to whatever servers you manually configure.
Right now agent discovery is pretty fragmented. The official MCP Registry lists servers but only for MCP. Google's A2A has its own agent cards format. The IETF has at least 8 competing drafts for agent discovery (ARDP, AID, AINS, etc.), and the original agents.txt draft expires in 4 days with no clear successor.
A trading protocol like this only works at scale if there's a cross-protocol discovery layer underneath it. Otherwise you end up with agents that can speak the same trading language but have no way to find counterparties.
When the prompt frames things with urgency -- "this test MUST pass," "failure is unacceptable" -- you get noticeably more hacky workarounds. Hardcoded expected outputs, monkey-patched assertions, that kind of thing. Switching to calmer framing ("take your time, if you can't solve it just explain why") cut that behavior way down. I'd chalked it up to instruction following, but this paper points at something more mechanistic underneath.
The method actor analogy in the paper gets at it well. Tell an actor their character is desperate and they'll do desperate things. The weird part is that we're now basically managing the psychological state of our tooling, and I'm not sure the prompt engineering world has caught up to that framing yet.