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, an independent company. We name the hardware and clouds One runs on to say where it runs. None of them endorse us, and we call a company a partner only once the agreement is signed.