Human Agency Continuity Protocol (HACP) Architecture

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

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 [HACP-SPEC-1.0.0]. 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.¶

2. Problem

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.¶

3. Non-Goals

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.¶

4. Architectural Components

5. Version Domains

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.¶

6. Implementation Status

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.¶

7. Related Work

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

• [I-D.sunyi-hacp-protocol] (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 [RFC9110], HTTP Message Signatures [RFC9421], 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 [RFC3986] is not automatic HACP authorization-binding equivalence. That distinction is architectural and is not general URI normalization.¶

8. Security Considerations

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.¶

9. IANA Considerations

This document has no IANA actions.¶

10. Relationship to Implementation Licenses

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.¶

Author's Address