Permissions are usually the last uninteresting thing in a system. A checkbox, a string in a database, maybe a banner that somebody clicks past. That is fine until you give a machine permission to make a plan.
PCHP names identity, purpose, exact scope, validity, delivery, and receipt. The engineering question is whether those attributes can become machine-checkable invariants across a multi-tool agent plan, instead of natural-language promises around one.
A model does not see one request. It sees possible next steps. It can read, search, assemble, retry, and hand work to another tool. If the authority attached to those steps is vague, the vague part becomes the security boundary.
The useful unit is not “allowed.” It is: this person, for this purpose, over this exact scope, until this time, subject to revocation. A good implementation makes that sentence hard to accidentally shorten.
Start with a tiny grant algebra, then throw strange plans at it. A retry after expiry. A read that triggers an export. Two narrow grants that look temptingly combinable. If the invariants survive, the rest becomes engineering work instead of wishful thinking.
Build a minimal typed grant algebra and property-based test suite. The first success condition is simple: no composed plan may execute outside the intersection of its live grants.
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.