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 a product of Hushh Technologies Corporation (brand: 🤫 “hussh”), an independent company. One runs on third-party silicon, systems, and cloud; platform names are used solely to describe where One software runs and imply no affiliation, endorsement, or sponsorship by those platforms. Our own go-to-market and bill-of-materials partner programs are real and actively in pursuit; we name a partner only once an agreement is executed.