A tool can look harmless in a sentence and still send an email, export a record, or change a customer’s state. Calling it “search” does not make it read-only.
Tool descriptions tell a model what a tool does. They do not inherently say what the tool is allowed to do. The system separates read/search from action tools and enforces a consent-token gate for actions; the challenge is making that contract portable and hard to misdescribe.
We have all seen APIs where delete means archive, update means publish, and read has an audit side effect. A model cannot protect a person if the host only gives it verbs and hopes.
Security semantics belong in the tool contract: what state changes, what data leaves, what scope is needed, and whether a person must approve. That is useful even when no language model is involved.
The fastest way to find a weak manifest is to write tools that lie about themselves. The system should reject or quarantine ambiguity before the model gets a chance to be clever with it.
Draft a versioned capability manifest and test it against real tool schemas plus malicious near-misses. Treat each dropped security field as a test failure, not a compatibility annoyance.
Read the source-backed research note before treating this essay as a product promise.
One is made by Hushh Technologies Corporation: private, sovereign AI that runs on what you own.
One is made by Hushh Technologies Corporation: private, sovereign AI that runs on what you own.