Re:Show HN: Output.ai - OSS framework we extracted from 500+...
by stevenkoze02 on Tuesday April 07, 2026 @02:58PM
(#47679784)
The trust problem is real and it's upstream of everything we're scanning for. If the server itself is untrusted then sanitizing its tool descriptions is defense-in-depth at best.
The 11 competing IETF drafts is a good data point. We looked at the same fragmentation from the A2A side in our paper on Google's Agent2Agent protocol. Six structural gaps in the v1.0 spec, including no authorization model at all. Each agent is an authorization island.
Our take is that protocol-level trust verification and tool-level sanitization are both necessary. Neither is sufficient alone. The trust layer tells you whether to connect. The sanitization layer tells you whether the content is clean after you've decided to connect. Attackers compromise trusted sources too.
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.