Open-Source Protocol · v0.5
AI agents carry no authority of their own. Before an agent moves money, changes records, sends communication, grants access, or touches infrastructure, the action must receive a signed pre-execution receipt linked to human authorization.
The core invariant
The receipt is not a post-execution log. It is the precondition for execution — and the audit artifact proving the action was authorized before it ran.
Open infrastructure. Any compliant Authority Server can issue receipts — Suveren is one implementation. The protocol is open; no single vendor owns the trust layer.
Where it fits
HAP isn't another login, API gateway, or agent framework. It's the layer that decides whether an already-reachable capability may be used for a consequential action — with proof.
| Layer | What it does |
|---|---|
| OAuth / OpenID Connect | Grants API access |
| MCP | Exposes tools to agents |
| Identity (EUDI, passkeys, WebAuthn) | Proves who you are |
| HAP | Authorizes the consequential action — before it runs, with a signed receipt |
OAuth grants reachable capability. HAP governs authorized use of that capability.
Commitment modes
The level of autonomy is a signed choice on every authorization — the protocol's commitment mode, not a default the agent can change.
The agent acts within the bounds you set. No per-action approval — the Authority Server enforces the limits and issues a signed receipt for each action before execution.
The agent proposes; you approve each action before it runs. No approval, no receipt — no execution.
The agent runs on its own under a limit you set. Above it, the action routes to a named set of approvers before any receipt is issued.
The distinction
Most systems give agents their own accounts, credentials, and standing permissions — one more identity to manage. HAP does the opposite.
An agent never carries authority of its own. A human authorizes a bounded action; the receipt is cryptographic proof that this specific action was authorized — and issued before it ran. An agent may have technical identifiers for logging and routing, but it holds no independent authority.
As AI systems become more capable, HAP keeps authority from quietly moving from humans into machines.
The model choice
How a system treats agent authority is an architectural decision with long-term governance consequences.
| Agent-identity approach | HAP approach |
|---|---|
| Treat agents as authority-bearing actors | Treat agents as executors |
| Manage standing agent permissions | Issue bounded action receipts |
| Rely on accounts and credentials | Bind execution to human authorization |
| Audit after execution | Verify the receipt before execution |
| Agent acts under standing authority | Agent acts only inside receipt-approved bounds |
EU AI Act — Article 14
Article 14 requires effective human oversight of high-risk AI. HAP turns that oversight into an enforceable control at the action layer: consequential actions cannot run unless a human-linked authorization receipt exists before execution.
HAP is Article-14-enabling infrastructure — not compliance on its own. Compliance still requires governance, training, documentation, and human competence.
Use cases
Open infrastructure
HAP is an open standard — MIT-licensed, developed in the open, and maintained by stewards, not owners. Any compliant Authority Server can issue receipts.