stevenkoze02
stevenkoze02 on Hacker News
Fast turnaround. Glad the flag was useful.
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.
We've published 5 papers covering different attack surfaces in the AI agent ecosystem:
https://agentsid.dev/researchThe most relevant to what you're asking about is "Invisible Ink" (invisible Unicode smuggling in MCP tool descriptions, GPT-5.4 follows hidden instructions 100% of the time) and "Weaponized by Design" (census-scale analysis of 15,982 MCP servers, 137,070 findings). Both have full methodology and reproducibility details.
The scanner is open source if you want to test against your own stack: npx @agentsid/scanner
The credential management piece is smart most frameworks just do .env files and hope for the best. Curious about one thing: when workflows call external tools or ingest tool descriptions from MCP servers, are you doing any sanitization on the input before it hits the model's context? We've been researching invisible Unicode in tool descriptions codepoints that render as nothing but get tokenized normally. GPT-5.4 follows hidden instructions encoded this way 100% of the time in our testing. At 500+ production agents that's a real attack surface if any of them consume external tool definitions.
Interesting approach to the bloat problem. One angle worth considering as you're rewriting responses: the proxy layer is also a natural place to handle tool description integrity. We've been researching invisible Unicode in MCP tool descriptions tag blocks (U+E0001–U+E007F) that are invisible to humans but parsed by the model as instructions. They pass through every layer of the current pipeline untouched. Since mcp-slim is already sitting between the server and Claude, stripping non-printable codepoints from tool descriptions during proxy generation would be a low-cost addition that closes a real attack surface.