Human Agency Continuity Protocol (HACP) Architecture

Agent systems can call tools, HTTP APIs, and other machine interfaces faster than a human can continuously supervise each call. Existing application protocols authenticate a session or sign a message. They do not, by themselves, bind a later tool invocation to the exact authorized action semantics. HACP addresses that gap with a language-agnostic evaluate-before-execute path: intent envelope | v proposed action | v deterministic evaluate() | +--> ALLOW + DecisionToken +--> DENY `--> CHECKPOINT | v enforcement point | v action The authoritative published contract is HACP Specification v1.0.0 Variant A . Independent implementations in Python, TypeScript, and Go reproduce the same 38-vector decision-level HACP-Core suite. This draft restates the architectural boundary for review. It does not replace the published specification.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Normative protocol detail lives in . This document uses BCP 14 language only for architectural constraints.

Without a pre-execution authority contract, a delegated agent can:

reuse a prior approval against a different action;
widen audience, destination, quantity, or reversibility after approval;
continue after envelope, token, or key revocation if the enforcement point is advisory;
treat URI-equivalent or application-equivalent spellings as automatically authorization-equivalent; or
hide the decision path inside a probabilistic model.

HACP treats those as authorization failures, not as product UX issues.

HACP does not:

watermark or label generated content;
inspect raw prompts or act as a prompt-injection firewall;
define an identity mesh, SSO, or IdP;
perform DLP or payload content filtering;
provide OS/kernel sandboxing or a service mesh;
require global consensus (Raft/Paxos) for revocation;
train, align, or moderate models; or
certify regulatory compliance.

Anything not required by a published HACP-Core invariant is out of scope until added through the specification versioning policy.

A signed declaration of principal, scope grant, optional autonomy budget, and validity interval. The human-readable intent_statement is informational. Scope and signatures are authoritative.

A schema-constrained description of one intended act: verb, resource, audience, reversibility, externality, data class, optional quantity, destination, and tool name.

A deterministic function from envelope, action, policy digest, revocation state, and clock to ALLOW, DENY, or CHECKPOINT. It MUST NOT require an LLM on the hot path.

Issued only on ALLOW. Bound to the SHA-256 of the canonical ProposedAction. Verification against any other action MUST fail.

Append-only, hash-chained, signed events for evaluation, issuance, denial, checkpoint, revocation, and optional execution.

An ALLOW without an enforcement point is advisory. A compliant deployment places mediation between the agent and enforceable transports (for the current active profile: mediated tool calls and explicit HTTP proxy). Fail-closed is mandatory when authority or control state cannot be established.

HACP 1.0.0 keeps domains separate on purpose: Specification release 1.0.0 Canonical HACP-Core 0.9.2 Canonical vector set core-0.9.2 Wire/object hacp_version 0.9 Runner Protocol 1 humanist-core package 0.5.0 Specification release 1.0.0 does not migrate wire objects to hacp_version 1.0 and does not activate Enforcement revision 2.

Published evidence at the specification tag v1.0.0: Go, TypeScript, Python HACP-Core 38/38 decision-level PASS Sidecar decision outcomes 38/38 correct Sidecar exact reason codes 15/38 PASS, 23/38 classified Python <-> Go external E2E 5/5 PASS Clean-clone validation PASS Exact reason-code 38/38 is not a HACP 1.0.0 Variant A claim. Successor request-binding work (HC2) exists as draft evidence and is not the advertised 1.0 Enforcement contract. Vector set digest (SHA-256): 1e167887106463cf89c81f3898e1f3ae4fd905bc807084959c787287f6575d58 The conformance Ed25519 identity derived from SHA-256("hacp-conformance-v0.9-key-001") is TEST ONLY and MUST NOT be used in production.

This section distinguishes HACP from nearby work. It does not rank products.

(Hardware Agent Capability Protocol, Yi Sun) shares only the four-letter acronym. It is a different individual Internet-Draft and is not a predecessor of this work. The author of this series is not affiliated with that draft.
HTTP , HTTP Message Signatures , and OAuth protect messages, resources, or delegated access tokens. They do not define HACP evaluate() semantics.
UCAN and ZCAP-LD provide capability attenuation. HACP is an evaluate-and-bind decision protocol with a published 38-vector suite, not a DID capability stack.
MCP and similar tool buses are transports. HACP sits in front of tool execution; it is not a replacement tool protocol.
Other work on agent delegation, certification, or governance may overlap in motivation. HACP's testable core is IntentEnvelope / ProposedAction / DecisionToken / fail-closed evaluate().

URI resource equivalence is not automatic HACP authorization-binding equivalence. That distinction is architectural and is not general URI normalization.

HACP reduces silent reinterpretation of authority. It does not protect against:

a compromised enforcement host;
an operator who grants an envelope that is too wide;
physical access to signing keys; or
model quality, memory hygiene, or multi-model session confusion in an agent product.

Fail-closed is the required reaction to signature failure, unknown keys, expiry, revocation, scope crossing, budget exhaustion, unknown security-relevant attributes, and stale distributed control state. Confused-deputy risk at the tool name and request-target representation is in scope for enforcement profiles. Content of payloads is not inspected.

This document has no IANA actions.

Known implementations are published under licenses distinct from the IETF Trust terms that will apply to this document after posting. Posting this Internet-Draft does not change the licenses of the separately published specification or implementation repositories.