Open Protocol · v0.6
A human sets what the automation may do — scope, limits, duration. Every consequential action is checked against that mandate before it runs, and produces a signed receipt proving the authorization existed first. Not a log written afterwards. A precondition.
The core invariant
The receipt is not a post-execution log. It is the precondition for execution — and, afterwards, the verifiable proof that authorization existed before it ran. Agents request execution; they do not hold the keys.
Open infrastructure. Any compliant Authority Server can issue receipts — Suveren is one implementation. 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 receipt and they verify the signature and the content themselves — no account, no relationship with you. Cryptography, not testimony.
Evidence created before the act, not reconstructed after: which mandate, which bounds, which content. What an auditor, an insurer, or a court asks for.
What holds today, and what comes next
Today the Authority Server signs that the human authorized it — the chain holds as far as you trust one operator's key. Next, the human's own key co-signs the mandate. Then it holds without trusting any operator, including us.
The same receipt 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 (e.g. Entra Agent ID) | Governs which agents exist and what they may reach |
| Agent platforms and policy engines (e.g. Bedrock AgentCore) | Run agents and evaluate configured rules per call |
| HAP | Authorizes the consequential execution — against a mandate a named human committed to, before it runs, with a signed receipt |
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 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 accounts, credentials, and standing permissions — turning them into authority-bearing actors. HAP does the opposite.
An agent never carries authority or raw credentials 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 |
| Hand agents standing credentials | Keep credentials behind the execution boundary |
| Audit after execution | Verify the receipt before execution |
| Agent acts under standing authority | Agent acts only inside receipt-approved bounds |
| Post-incident, the answer is “the agent was permitted” | Post-incident, the answer is “this named person mandated this scope — 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: consequential actions cannot run unless a human-linked authorization receipt exists before execution.
Wherever an organization must show a human stood behind an automated act — regulation, audit, insurance, or litigation — the receipt is the artifact.
HAP is Article-14-enabling infrastructure — not compliance on its own. Compliance still requires governance, training, documentation, and human competence.
For whom
Deploy agents on the infrastructure you already have. One enforcement point, no new stack, whichever model you run.
The same gate produces the evidence: who mandated it, what it covered, proven before it ran.
Proof that survives leaving your organization — verifiable without trusting the operator.
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.