🤫husshhussh
🤫husshhusshOnePuppy
Implemented · Distributed systems · authorization · agents

Can consent become a type system for agents?

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.

Read the companion essayAll open problems
Problem statement

The hard question.

Define a grant algebra in which a plan cannot gain authority by composition: every executed tool call must remain inside the active subject, purpose, exact scope, validity window, and revocation state.

Agents increasingly plan across tools, connectors, and services. A permission string that is clear for one RPC becomes ambiguous once the model can compose five calls and retry them.

Status

What is true today.

The code has signed, subject-bound, TTL-capped tokens, a generated scope registry, and an action-tool consent gate. Registry validation at mint and a unified durable grant model remain open seams.

Primary source: PCHP implementation status

Constraints

The work is only useful if these survive.

  • A published registry and token mint need one vocabulary.
  • Read paths cannot become covert mutations.
  • Expiry and revocation must invalidate a plan already in flight.
  • Receipts must explain a decision without recording the private payload.
Evaluation

How we would know.

Property tests for intersection, expiry, revocation, delegation, and retries.
Adversarial plans that attempt scope widening across connectors.
A trace showing the exact grant used for every action-capable tool call.
A first contribution

Start with something that can fail.

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 it plainly, then make it better.

The companion essay is written for a broader technical audience. The repository and developer community are the places to turn a claim into a contribution.

Companion essayJoin Discord

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.