Open Protocol · v0.8
A human sets what the automation may do — scope, limits, duration. Every consequential action is checked against that mandate before it runs, and obtains a signed mandate ticket proving the mandate existed first. Not a log written afterwards. A precondition.
The core invariant
The ticket is not a post-execution log. It is the precondition for execution — and, afterwards, the verifiable proof that a mandate existed before it ran, with an identifiable person behind it. Agents request execution; they do not hold the keys.
Open infrastructure. Any compliant Authority Server can issue tickets. The protocol is open; no single vendor owns the trust layer.
One signed act
Most systems make you choose: a gate that blocks, or a log that explains. The same signed artifact does both, and a third thing neither can.
Every consequential action is checked against the mandate before it happens. Not caught in a log afterwards. Prevented.
Hand someone the ticket and they check the signature against an issuer they trust and, where the content is bound, the content too — without an account, without asking you. Where only part of it may be shown, the Authority Server can sign a public view that verifies on its own.
Evidence created before the act, not reconstructed after: which mandate, which bounds, which content. What an auditor, an insurer, or a court asks for.
Who you have to trust
With the Authority Server's signature alone, the chain holds as far as you trust that operator's key. The protocol also defines the human's own co-signature on the mandate. With it, the mandate and each approval are attributable to the person's own key, not the operator's word. Cumulative totals and the order of events still rest on the Authority Server.
The same ticket does all three. That is what a signed artifact can do and a permission cannot.
Where it fits
HAP isn't another login, API gateway, agent framework, sandbox, or policy engine. 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 |
| Identity (EUDI, passkeys, WebAuthn) | Proves who you are |
| MCP | Exposes tools to agents |
| Agent identity and lifecycle | Governs which agents exist and what they may reach |
| Agent platforms and policy engines | Run agents and evaluate configured rules per call |
| HAP | Authorizes the consequential execution — against a mandate an identifiable person committed to, before it runs, with a signed ticket |
Every other layer here answers can this system reach that? — an access question, and each answers it well. None of them holds a bounded mandate a named human committed to, and none produces an artifact a third party can verify for themselves. HAP adds that layer and replaces none of them: keep your identity provider, your agent platform, your policy engine, your sandbox and secrets manager. Point them at the agent path, and put the mandate above.
OAuth grants reachable capability. HAP governs authorized use of that capability.
Agent platforms decide what an agent may reach. HAP records what a human actually mandated — and proves this act was inside it.
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 ticket for each action before execution.
The agent proposes; you approve each action before it runs. No approval, no ticket — no execution. What the agent proposes reaches the Authority Server encrypted to you and the people who decide: a server that follows the protocol cannot read it, and keeps only a fingerprint.
The agent runs on its own under a limit you set. Above it, the action becomes a proposal for the approvers named in the mandate — the person it acts for never counts as one of them — before any ticket is issued. A cap can also be hard: above it, the action is refused.
The distinction
Most systems give agents accounts, credentials, and standing permissions — turning them into authority-bearing actors. HAP does the opposite.
An agent never carries authority of its own, or a credential that by itself can cause a consequential effect. A human authorizes a bounded action; the ticket 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 | Give a bounded mandate |
| Hand agents standing credentials | Keep credentials behind the execution boundary |
| Audit after execution | Obtain a ticket before execution |
| Agent acts without a mandate | Agent acts only inside the mandate |
| Post-incident, the answer is “the agent was permitted” | Post-incident, the answer is “this person mandated these bounds — here is the proof” |
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: on every path HAP mediates, consequential actions cannot run unless a ticket under a person's mandate exists before execution.
Wherever an organization must show a human stood behind an automated act — regulation, audit, insurance, or litigation — the ticket is the artifact.
HAP is Article-14-enabling infrastructure — not compliance on its own. Compliance still requires governance, training, documentation, and human competence.
What needs a mandate
The protocol defines a consequential action as any operation that affects external state, human wellbeing, financial position, legal standing, or reputation. That is the test — not a category on a list. If an action passes it, it needs a mandate and a ticket.
Those are the authority profiles published today, not the boundary of what HAP governs. A profile is data — it declares which limits exist for one kind of authority — and anyone can publish one: no approval, no registry, no central list to be added to. Whatever your agents do that you would want a name against, that is what a profile describes.
Open infrastructure
HAP is an open-source protocol — MIT-licensed, developed in the open, and owned by no one. Any compliant Authority Server can issue tickets, and the answer key an implementation must reproduce is published.