Corey James- ~500tool descriptions treated as untrusted text
- 3servers whose catalogs are read, never called
Tool text treated as untrusted data
In FAFOHive I wanted readable guides to every tool across its servers, most of them published by vendors. Asking a model to summarise each tool has a trap in it: a tool's name, description and schema are text written by whoever published the tool, and a model that reads them with any authority can be steered by them. I decided every tool description is untrusted data and built a tool explorer around that.
Discovery is read-only. The explorer reads each server's catalog and never calls a tool, so exploring cannot cause a side effect. Official descriptions and AI-written guides are stored and shown separately and never merge, so a reader always knows which one they are reading.
Audits in a locked-down session
Guides are produced only when I start an audit, scoped to stale tools, one suite or everything, so there is no standing access. The audit runs in a locked-down command-line model session that can write nothing except its output file; a model that reads third-party tool text has no authority beyond that one checked file. Every output entry must name an exact tool identifier and the exact source hash it was written against.
I build AI features on the assumption that model inputs can be hostile: the model gets text without trust, and its output is checked against facts it could not forge.
Platform events are never instructions
The in-house social modules follow the same stance in both directions. The gateway around them is told in Agents with real tools and no keys.
This is an operator tool for understanding a large tool estate, built from hashing, a sandboxed session and strict checks.