PoHI for Bounded Agent Delegation
Overview
As software agents gain access to wallets, APIs, enterprise tools, and payment systems, the core security challenge is no longer limited to authentication.
The harder problem is authorization:
how can a human decision be transformed into a bounded, verifiable, machine-consumable authorization artifact for a sensitive agent action?
Interstellar’s long-term direction is to address this gap through a PoHI-based authorization layer.
This layer is not designed to replace identity systems, passkeys, OAuth, or agent protocols.
Its role is to add a missing primitive:
a human-approved authorization unit bound to the critical parameters of an action or delegation.
The Core Idea
A human approval should not remain a vague consent event.
It should become a structured artifact that binds:
- who approved,
- which agent or workflow was authorized,
- which action type was allowed,
- on which resource,
- within which limits,
- for how long,
- and under which assurance level.
We refer to this artifact as a:
PoHI Authorization Receipt
This receipt is intended to become the core machine-consumable object of the authorization layer.
What This Layer Is — and Is Not
| Category | What It Is | What It Is Not |
| Primary role | A human authorization layer for bounded delegation | A generic identity platform |
| Core object | A bounded, verifiable authorization receipt | A reusable master credential |
| Relation to passkeys | Can offer passkey-grade UX for approvals | A replacement for passkeys |
| Relation to OAuth / agent protocols | Compatible enforcement and integration layer | A replacement for OAuth or agent connectivity standards |
| Relation to decentralized storage | May use decentralized trust anchors where useful | A generic decentralized credential vault |
Design Principle
The authorization layer should follow a simple rule:
Decentralize the trust-critical invariants. Keep fast-changing operational logic off-chain or off-consensus.
This avoids turning every runtime authorization decision into a heavy decentralized workflow while preserving strong guarantees where they matter most.
Core Invariant Envelope
The PoHI Authorization Receipt should bind the parameters that materially define the meaning and risk of the approval.
Actor invariants
- human principal reference
- approving device or trusted execution context
- target agent, workflow, or session identity
Action invariants
- action class
- target resource or tool scope
- canonical action digest
- execution correlation handle
Risk invariants
- quantitative limits
- temporal bounds
- replay protection
- delegability rule
Assurance invariants
- assurance level
- step-up markers
- revocation handle
These parameters form the core invariant envelope.
Extension Envelope
Not every parameter belongs in the decentralized or portable core.
The following elements may exist in the broader authorization flow while remaining outside the core receipt model:
- real-time risk scoring
- workflow-local context
- prompt history
- compliance metadata
- enterprise-specific policy logic
- dynamic routing details
- UX rendering information
- ephemeral execution state
This distinction is essential to keep the system both usable and performant.
Hybrid Trust Model
| Component | Recommended Model | Reason |
| Authorization receipt commitment | Decentralized | Improves trust, portability, and auditability |
| Revocation transparency | Decentralized | Enables verifiable invalidation and dispute analysis |
| Attestation registries | Decentralized | Useful as cross-domain trust anchors |
| Threshold approval evidence | Decentralized | Supports verifiable multi-party approval models |
| Live risk scoring | Off-chain / local | Too dynamic for consensus-based handling |
| Session state | Off-chain / local | Operational and rapidly changing |
| Execution tokens | Off-chain / local | Must remain short-lived and efficient |
| Enterprise policy logic | Off-chain / local | Needs flexibility and frequent updates |
Protocol Sketch
1. Agent submits a bounded request
An agent requests a narrowly scoped authority, for example:
- a specific action class
- a target tool or resource
- a hard limit
- a time window
- an optional plan or workflow hash
2. Gateway canonicalizes the request
The system transforms the request into a canonical authorization envelope.
If the request cannot be normalized into a stable and understandable structure, it should not be approved.
3. User performs a PoHI confirmation
The user reviews the bounded request through a trusted approval flow and confirms it via PoHI.
4. A PoHI Authorization Receipt is generated
The system issues a bounded receipt tied to the critical action parameters.
5. Runtime derives narrow execution rights
The receipt is converted into a narrow execution grant such as:
- a one-time signer release
- a short-lived token
- a session-bound capability
- a bounded API authorization
6. Execution is correlated
The execution is linked back to the receipt using an execution correlation handle.
7. Revocation or step-up remains possible
If the context changes before execution, the system can:
- revoke the authorization
- or require a stronger PoHI approval
Why This Matters for Agents
Most agent systems can request permissions and consume delegated access.
What they generally lack is a strong guarantee that:
- the human approval was intentional,
- the approved scope was bounded,
- the authorized action can be verified later,
- and the agent cannot silently reinterpret the approval after issuance.
This is the role of the PoHI authorization layer.
Initial Use Cases
A first version of the model could apply to:
- smart-account transaction approval
- payment approval for agentic workflows
- custody or signer release
- bounded tool access for a session
- high-risk enterprise actions requiring explicit human authorization
These use cases are narrow enough to be modeled precisely and valuable enough to justify a stronger approval primitive.
Key Challenges
Canonicalization
The hardest problem is not storage or signatures.
The hardest problem is defining a canonical action envelope that is:
- precise enough to be secure,
- understandable enough to be approved by a human,
- and stable enough to be enforced by machines.
Receipt-to-execution binding
A second critical challenge is ensuring that the final machine action truly corresponds to the approved authorization receipt.
Without strong execution binding, the system risks becoming only a better approval interface.
Usability
The receipt must bind the parameters that materially define risk without forcing the user to inspect excessive implementation detail.
Long-Term Direction
The long-term goal is not to replace the broader identity and authorization ecosystem.
It is to introduce a missing middle-layer primitive:
Layer 1
Human PoHI decision
Layer 2
Bounded authorization receipt
Layer 3
Execution adapters and enforcement rails
This architecture makes it possible to remain compatible with evolving standards while preserving a clear and differentiated core.
Summary
Interstellar’s future authorization layer for agents can be understood as follows:
PoHI turns a human approval into a bounded, verifiable authorization receipt that machines can consume but not freely reinterpret.
That is the strategic direction:
- stronger than a simple consent UI,
- narrower and more credible than a new identity standard,
- and compatible with the execution rails that will continue to evolve around it.