Intent Provenance Protocol (IPP)
draft-haberkamp-ipp-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Amanda Haberkamp | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-haberkamp-ipp-01
Network Working Group A. Haberkamp
Internet-Draft 2 July 2026
Intended status: Informational
Expires: 3 January 2027
Intent Provenance Protocol (IPP)
draft-haberkamp-ipp-01
Abstract
This document specifies the Intent Provenance Protocol (IPP), a
cryptographic infrastructure standard for carrying verified human
intent through chains of autonomous artificial intelligence agent
actions. IPP defines the Intent Token, a signed, bounded, and
tamper-evident data structure that travels with every agentic action,
preserving an unbroken, auditable lineage from the originating human
principal to each terminal action executed on their behalf.
As AI agents become primary actors in enterprise environments,
executing transactions, accessing sensitive data, orchestrating sub-
agents, and operating across organizational boundaries, the absence
of a shared trust substrate creates systemic risk to organizational
accountability, regulatory compliance, and legal liability
attribution. IPP addresses this gap by establishing a protocol layer
that operates above cryptographic authentication and below
application logic, making human intent a first-class, verifiable
primitive in agentic systems.
IPP introduces four foundational properties, Lineage, Boundedness,
Non-repudiation, and Interoperability, enforced through a combination
of Ed25519 digital signatures, Decentralized Identifiers (DIDs), and
a Narrowing Invariant that prevents any derived token from exceeding
its parent's authorized scope. The protocol is framework-agnostic,
cloud-agnostic, and designed for open implementation across the
ecosystem of AI orchestration platforms.
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/.
Haberkamp Expires 3 January 2027 [Page 1]
Internet-Draft Intent Provenance Protocol July 2026
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 3 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Motivation . . . . . . . . . . . . . . . . 3
1.2. The Authorship Problem in Agentic Systems . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6
3.2. The Four Foundational Properties . . . . . . . . . . . . 6
3.3. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 7
4. The Intent Token . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Token Structure . . . . . . . . . . . . . . . . . . . . . 8
4.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 9
4.3. The Intent Scope Envelope . . . . . . . . . . . . . . . . 11
4.4. Quantitative Bounds . . . . . . . . . . . . . . . . . . . 12
5. The Genesis Seal . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Purpose and Design . . . . . . . . . . . . . . . . . . . 12
5.2. Genesis Seal Structure . . . . . . . . . . . . . . . . . 13
5.3. Key Generation Ceremony . . . . . . . . . . . . . . . . . 13
5.4. Authorship Attribution Requirements . . . . . . . . . . . 14
6. Cryptographic Mechanisms . . . . . . . . . . . . . . . . . . 14
6.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 15
6.2. Decentralized Identifiers (DIDs) . . . . . . . . . . . . 15
6.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15
6.4. The Narrowing Invariant . . . . . . . . . . . . . . . . . 15
7. Delegation and Derived Tokens . . . . . . . . . . . . . . . . 16
7.1. Derivation Rules . . . . . . . . . . . . . . . . . . . . 16
7.2. Delegation Depth . . . . . . . . . . . . . . . . . . . . 16
7.3. Sub-Agent Spawning . . . . . . . . . . . . . . . . . . . 17
Haberkamp Expires 3 January 2027 [Page 2]
Internet-Draft Intent Provenance Protocol July 2026
8. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Revocation Registry . . . . . . . . . . . . . . . . . . . 17
8.2. Polling Requirements . . . . . . . . . . . . . . . . . . 17
8.3. Mid-Chain Revocation . . . . . . . . . . . . . . . . . . 18
9. Provenance Chain . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Append-Only Structure . . . . . . . . . . . . . . . . . . 18
9.2. Provenance Record Format . . . . . . . . . . . . . . . . 18
10. Interoperability . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Framework Integration . . . . . . . . . . . . . . . . . 19
10.2. Cross-Organization Trust . . . . . . . . . . . . . . . . 19
10.3. Domain Taxonomy . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
1.1. Background and Motivation
For three decades, enterprise security has operated under a single
foundational assumption: that every consequential digital action
originates from, and is ultimately accountable to, a human being.
Access control systems, identity governance frameworks, audit logging
infrastructures, and regulatory compliance regimes all derive their
validity from this assumption. A human authenticates. A human is
authorized. A human acts. A human is accountable.
The emergence of autonomous artificial intelligence agents, software
entities capable of perceiving their environment, reasoning about
goals, taking sequences of actions, and spawning additional agents to
fulfill sub-tasks, fundamentally invalidates this assumption. In
agentic environments, the majority of consequential actions are
executed by software entities operating without real-time human
supervision. A human sets a goal. An agent, or a hierarchy of
agents, determines and executes the means.
This creates a category of risk that existing security infrastructure
is architecturally unequipped to address: not the risk of
unauthorized access, but the risk of authorized-but-misaligned
action. This is agent behavior that is technically permitted by
access control systems but inconsistent with the human intent that
originally authorized the agent's deployment.
Haberkamp Expires 3 January 2027 [Page 3]
Internet-Draft Intent Provenance Protocol July 2026
1.2. The Authorship Problem in Agentic Systems
Consider a scenario in which a Chief Financial Officer instructs an
AI assistant to "optimize cash positions across all subsidiaries and
move any idle balances over ten million dollars into short-term
treasuries." The assistant spawns three sub-agents: one to query
treasury balances, one to evaluate current rates, and one to execute
transfers. The transfer agent, drawing on outputs from the other
two, initiates eleven separate wire transfers totaling three hundred
forty million dollars.
At the moment the eleventh transfer is executed, no existing system
can answer the following questions with cryptographic certainty: (a)
What specific human intent authorized this action? (b) What
constraints bounded that intent? (c) What is the complete chain of
delegation from the CFO's instruction to this specific transfer? (d)
Is this action consistent with what the CFO meant, or merely
consistent with what the CFO said? (e) Who bears legal accountability
if this action causes harm?
The Intent Provenance Protocol is designed to make all five of these
questions answerable with cryptographic precision, in real time,
without requiring a central authority, and in a form that is legally
defensible across jurisdictions.
1.3. Scope
This specification defines: the structure and semantics of the Intent
Token; the Genesis Seal mechanism for permanent authorship
attribution; the cryptographic mechanisms underlying token signing
and verification; the Narrowing Invariant governing token derivation;
the revocation protocol; the provenance chain format; and the
interoperability requirements for compliant implementations.
This specification does not define: specific AI agent architectures
or orchestration frameworks; natural language processing mechanisms
for intent parsing; application-layer authorization policies; or
legal standards for accountability attribution, though it is designed
to support such standards.
2. Terminology and Definitions
The following terms are used throughout this specification:
Agent: An autonomous software entity capable of perceiving inputs,
reasoning about goals, taking sequences of actions, and
potentially spawning additional agents. Agents are the primary
non-human actors governed by this protocol.
Haberkamp Expires 3 January 2027 [Page 4]
Internet-Draft Intent Provenance Protocol July 2026
Principal: A human being or legally accountable organization at the
root of an intent chain. Every valid Intent Token chain MUST have
a human Principal at its origin. There is no such thing as an
agent-originated intent chain under this protocol.
Intent Token: The atomic unit of this protocol. A cryptographically
signed, bounded, and time-limited data structure that carries
verified human intent through a chain of agentic actions.
Genesis Seal: A cryptographic artifact embedded in every Intent
Token that permanently links the token to the original IPP
specification and its author, Amanda Haberkamp. The Genesis Seal
contains a hash of the specification document signed by the
Founding Key.
Founding Key: The Ed25519 private key generated by Amanda Haberkamp
during the Key Generation Ceremony and used exclusively to produce
the Genesis Seal signature. This key is never used after the
ceremony and is stored in offline cold storage.
Narrowing Invariant: The protocol rule that a Derived Token MUST be
strictly less than or equal to its Parent Token in every dimension
of scope, delegation depth, and expiry. Violations of this
invariant are detectable by any participant without contacting a
central authority.
Derived Token: An Intent Token produced by an agent from a Parent
Token. A Derived Token carries narrowed scope and reduced
delegation depth, and is signed by both the issuing agent and
linked to the Parent Token's signature.
Delegation Depth: A non-negative integer field in the Intent Token
specifying how many additional levels of sub-agent spawning are
authorized. A value of zero means the token holder may act but
may not spawn sub-agents.
Provenance Chain: An append-only, cryptographically linked sequence
of records within an Intent Token documenting every action taken
under that token's authority.
Domain Taxonomy: The hierarchical dot-notation vocabulary for
classifying intent domains, maintained by Amanda Haberkamp and
open for community contribution. Examples: financial.treasury,
healthcare.records.read, infrastructure.compute.provision.
DID: Decentralized Identifier. A W3C standard identifier that
Haberkamp Expires 3 January 2027 [Page 5]
Internet-Draft Intent Provenance Protocol July 2026
enables verifiable, self-sovereign identity without relying on a
centralized registry. All Principal and Agent identities in this
protocol are expressed as DIDs.
Revocation Registry: A distributed service providing real-time token
revocation status. Agents MUST check the registry before taking
any action under a token.
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Overview
3.1. Design Principles
IPP is designed according to the following principles:
* Decentralized enforcement: Token validity is verifiable by any
participant without contacting a central authority. The
cryptographic structure of the token itself makes violations
detectable.
* Human primacy: Every intent chain MUST originate from a human
Principal. This is not a policy choice. It is a structural
requirement enforced by the token schema.
* Minimal footprint: The SDK integration surface is intentionally
small. Developers add governance capability to existing agents
without rewriting their architecture.
* Open interoperability: The protocol is framework-agnostic, cloud-
agnostic, and jurisdiction-agnostic. Any conformant
implementation can interoperate with any other.
* Permanent authorship: The Genesis Seal embeds cryptographic
attribution to the protocol's author in every token, making the
authorship record tamper-evident and permanent by design.
3.2. The Four Foundational Properties
Every compliant IPP implementation MUST guarantee the following four
properties:
Haberkamp Expires 3 January 2027 [Page 6]
Internet-Draft Intent Provenance Protocol July 2026
*Lineage.* Every action taken by any agent under an Intent Token MUST
be traceable, through an unbroken chain of cryptographic signatures,
to a human Principal. The chain may pass through any number of
intermediate agents, but the terminal node in the backwards trace
MUST always be a DID resolving to a human or human-accountable legal
entity.
*Boundedness.* Every Intent Token MUST carry explicit, machine-
readable constraints on the scope of authorized action. These
constraints MUST be enforced by the SDK before any action is taken.
Constraints travel with the token through every delegation level and
MUST NOT be expanded by any intermediate agent.
*Non-Repudiation.* Every Intent Token MUST be cryptographically
signed such that the signing Principal or Agent cannot credibly deny
having issued the token. The signature MUST be verifiable by any
third party using only the signer's public key, without requiring
communication with the signer or any central authority.
*Interoperability.* Compliant implementations MUST be capable of
consuming and producing Intent Tokens regardless of the AI framework,
cloud environment, or programming language used. The token format is
defined in JSON with a canonical serialization for signature
purposes. SDK implementations SHOULD be available in at minimum
Python, JavaScript, Go, and Java.
3.3. Protocol Layers
IPP operates as a distinct protocol layer between cryptographic
identity infrastructure and application logic:
+------------------------------------------+
| Application Logic | <- Agent goals,
| | actions, outputs
+------------------------------------------+
| Intent Provenance Protocol (IPP) | <- This specification
| - Intent Tokens |
| - Delegation and Derivation |
| - Provenance Chain |
| - Revocation |
+------------------------------------------+
| Cryptographic Identity Layer | <- DIDs, Ed25519, TLS
+------------------------------------------+
| Transport / Infrastructure | <- HTTP, gRPC,
| | cloud APIs
+------------------------------------------+
Haberkamp Expires 3 January 2027 [Page 7]
Internet-Draft Intent Provenance Protocol July 2026
4. The Intent Token
4.1. Token Structure
The Intent Token is a JSON object with a canonical structure. The
following is a complete example of a root Intent Token, issued by a
Principal, not derived from a parent:
{
"$schema": "https://ipp.khsovereign.com/schema/v0.1/intent-token.json",
"$id": "IntentToken",
"version": "0.1",
"genesis": {
"spec_hash": "sha3-256:a3f9c2d8e1b74f6a...",
"author_did": "did:key:z6MkHaberkamp...",
"author_name": "Amanda Haberkamp",
"org": "KH Sovereign",
"genesis_sig": "ed25519:BASE64URL..."
},
"token_id": "iprov:tok:550e8400-e29b-41d4-a716-446655440000",
"schema_version": "0.1",
"created_at": "2026-09-01T14:32:00Z",
"expires_at": "2026-09-01T22:32:00Z",
"principal": {
"did": "did:key:z6MkPrincipalXXX...",
"name": "Amanda Haberkamp",
"org": "KH Sovereign",
"legal_jurisdiction": "US-IL",
"signature": "ed25519:BASE64URL..."
},
"intent": {
"natural_language": "Optimize cash positions across subsidiaries",
"domain": "financial.treasury",
"resource_scope": ["subsidiary:*", "account_type:cash"],
"quantitative_bounds": {
"min_balance_threshold": 10000000,
"currency": "USD",
"max_single_transaction": 50000000,
"time_window": "business_hours_CT"
},
"prohibited_actions": ["equity_purchase", "account_closure"]
},
"delegation": {
"parent_token_id": null,
"depth_remaining": 3,
"depth_original": 3,
"agent_id": "iprov:agent:langchain:treasury-optimizer-v1",
"agent_framework": "langchain",
Haberkamp Expires 3 January 2027 [Page 8]
Internet-Draft Intent Provenance Protocol July 2026
"agent_version": "0.1.0",
"spawned_by_principal": true
},
"revocation": {
"registry_endpoint": "https://revoke.khsovereign.com/v1",
"token_id_hash": "sha3-256:HASH...",
"check_interval_ms": 5000
},
"provenance_chain": [],
"token_signature": "ed25519:BASE64URL_SIGNED_BY_PRINCIPAL"
}
4.2. Field Definitions
The following table defines all top-level fields of the Intent Token:
Haberkamp Expires 3 January 2027 [Page 9]
Internet-Draft Intent Provenance Protocol July 2026
+==================+========+======================================+
| Field | Type | Description |
+==================+========+======================================+
| genesis | Object | The Genesis Seal. REQUIRED in all |
| | | tokens. See Section 5. |
+------------------+--------+--------------------------------------+
| token_id | String | A globally unique token identifier |
| | | in the format iprov:tok:{UUIDv4}. |
| | | REQUIRED. |
+------------------+--------+--------------------------------------+
| schema_version | String | The IPP schema version used to |
| | | construct this token. REQUIRED. |
+------------------+--------+--------------------------------------+
| created_at | String | ISO 8601 UTC timestamp of token |
| | | creation. REQUIRED. |
+------------------+--------+--------------------------------------+
| expires_at | String | ISO 8601 UTC timestamp of token |
| | | expiry. REQUIRED. Agents MUST NOT |
| | | act under expired tokens. |
+------------------+--------+--------------------------------------+
| principal | Object | The human Principal at the root of |
| | | this intent chain. REQUIRED for |
| | | root tokens. |
+------------------+--------+--------------------------------------+
| intent | Object | The structured intent scope |
| | | envelope. REQUIRED. See |
| | | Section 4.3. |
+------------------+--------+--------------------------------------+
| delegation | Object | Delegation metadata including parent |
| | | token reference, depth, and agent |
| | | identity. REQUIRED. See Section 7. |
+------------------+--------+--------------------------------------+
| revocation | Object | Revocation registry endpoint and |
| | | polling configuration. REQUIRED. |
| | | See Section 8. |
+------------------+--------+--------------------------------------+
| provenance_chain | Array | Append-only array of provenance |
| | | records. Initially empty. See |
| | | Section 9. |
+------------------+--------+--------------------------------------+
| token_signature | String | Ed25519 signature over the canonical |
| | | serialization of all other fields. |
| | | REQUIRED. |
+------------------+--------+--------------------------------------+
Table 1
Haberkamp Expires 3 January 2027 [Page 10]
Internet-Draft Intent Provenance Protocol July 2026
4.3. The Intent Scope Envelope
The intent field encodes the human's goal as a Structured Intent
Envelope consisting of four components. The natural_language field
is human-readable but NOT machine-enforceable. Enforcement is
performed against the structured fields only.
+=====================+========+================================+
| Field | Type | Description |
+=====================+========+================================+
| natural_language | String | Human-readable description of |
| | | the intent. Informational |
| | | only. REQUIRED. |
+---------------------+--------+--------------------------------+
| domain | String | Dot-notation domain from the |
| | | IPP Domain Taxonomy. |
| | | REQUIRED. Example: |
| | | financial.treasury |
+---------------------+--------+--------------------------------+
| resource_scope | Array | Array of resource patterns |
| | | defining which systems, |
| | | accounts, or data types are in |
| | | scope. Supports wildcard |
| | | notation. REQUIRED. |
+---------------------+--------+--------------------------------+
| quantitative_bounds | Object | Numerical and temporal |
| | | constraints on authorized |
| | | actions. Contents are domain- |
| | | specific. OPTIONAL but |
| | | RECOMMENDED. |
+---------------------+--------+--------------------------------+
| prohibited_actions | Array | Explicit list of action types |
| | | that are prohibited regardless |
| | | of resource scope. OPTIONAL. |
| | | Agents MUST NOT perform |
| | | prohibited actions even if |
| | | technically permissible. |
+---------------------+--------+--------------------------------+
Table 2
IMPORTANT: The domain field value MUST be drawn from the IPP Domain
Taxonomy maintained at https://ipp.khsovereign.com/taxonomy.
Implementations using non-standard domain values MUST prefix them
with "x." (for example, x.mycompany.custom_domain) to avoid collision
with future taxonomy additions.
Haberkamp Expires 3 January 2027 [Page 11]
Internet-Draft Intent Provenance Protocol July 2026
4.4. Quantitative Bounds
The quantitative_bounds object is domain-specific. This
specification defines standard bound fields for the financial domain.
Domain-specific extensions are published in the IPP Domain Taxonomy
registry. Implementations SHOULD use standard field names where they
exist.
// Standard financial domain bounds
"quantitative_bounds": {
"min_balance_threshold": integer, // Min balance to trigger action
"max_single_transaction": integer, // Max single transaction value
"max_total_exposure": integer, // Max aggregate action value
"currency": string, // ISO 4217 currency code
"time_window": string, // Named window or ISO 8601 range
"geographic_restriction": [string], // ISO 3166-1 alpha-2 codes
"counterparty_allowlist": [string], // DID or entity identifiers
"counterparty_blocklist": [string] // DID or entity identifiers
}
5. The Genesis Seal
5.1. Purpose and Design
The Genesis Seal is a cryptographic artifact embedded in every Intent
Token that permanently and irrevocably links the token to this
specification and to its author, Amanda Haberkamp. The Genesis Seal
serves three simultaneous functions:
* Protocol versioning: The spec_hash field uniquely identifies the
exact version of the IPP specification under which the token was
issued.
* Authorship attribution: The author_did and genesis_sig fields
constitute a permanent, cryptographically verifiable record that
Amanda Haberkamp is the originator of this protocol.
* Ecosystem integrity: Because the Genesis Seal is required in all
tokens, any token that omits or falsifies it is detectable as non-
compliant without reference to any external authority.
The design is inspired by the genesis block pattern used in
blockchain systems, where the initial block contains a timestamp and
authorship record that is cryptographically chained to every
subsequent block. In IPP, the Genesis Seal plays the analogous role:
it is the permanent origin record embedded in every token the
protocol ever produces.
Haberkamp Expires 3 January 2027 [Page 12]
Internet-Draft Intent Provenance Protocol July 2026
The genesis_sig is produced using the Founding Key, an Ed25519
private key generated by Amanda Haberkamp and used ONLY ONCE, during
the Key Generation Ceremony described in Section 5.3. The private
component of this key is stored in offline cold storage and is never
used again. The public component is published in this specification
and in the IPP specification repository.
5.2. Genesis Seal Structure
"genesis": {
"spec_hash": "sha3-256:[HASH OF IPP SPECIFICATION DOCUMENT]",
"author_did": "did:key:z6MkHaberkampXXXXXXXXXXXXXXXXXXXXXXXX",
"author_name": "Amanda Haberkamp",
"org": "KH Sovereign",
"founding_pubkey": "ed25519-pub:[BASE64URL PUBLIC KEY]",
"genesis_sig": "ed25519:[BASE64URL SIGNATURE]"
}
Where genesis_sig = Ed25519Sign(private_key = FOUNDING_PRIVATE_KEY,
message = SHA3-256(spec_hash + author_did + author_name + org +
timestamp)).
Verification of the Genesis Seal MUST proceed as follows:
1. Retrieve the IPP specification document from the canonical
location: https://ipp.khsovereign.com/spec/v0.1
2. Compute SHA3-256 of the specification document and compare with
spec_hash. If they do not match, the token was issued under a
modified or forged specification.
3. Retrieve the founding public key from the specification
repository at https://ipp.khsovereign.com/keys/
founding_public.pem
4. Verify the genesis_sig using the founding public key against the
message defined above. If verification fails, the Genesis Seal
is invalid.
5. If both checks pass, the token is certified as issued under the
authentic IPP specification authored by Amanda Haberkamp.
5.3. Key Generation Ceremony
The Founding Key pair was generated according to the following
procedure, designed to maximize security and establish a clear,
witnessed chain of custody:
Haberkamp Expires 3 January 2027 [Page 13]
Internet-Draft Intent Provenance Protocol July 2026
1. An air-gapped machine, never connected to any network, was used
for all key generation operations.
2. The Ed25519 key pair was generated using OpenSSL 3.x.
3. A DID was generated from the public key using the did:key method
[W3C-DID].
4. The Genesis Seal payload was constructed and signed using the
private key.
5. The private key was printed to paper (two copies), placed in
fireproof storage, and deleted from all digital media. The air-
gapped machine was permanently decommissioned.
6. The public key, DID, and Genesis Seal were committed to the IPP
specification repository with a cryptographic timestamp from a
trusted timestamping authority [RFC3161].
SECURITY NOTE: The Founding Private Key is used exactly once. If the
Founding Private Key is ever compromised or disclosed, a Key
Compromise event MUST be declared via a signed notice published at
https://ipp.khsovereign.com/security, and a successor key ceremony
MUST be conducted. All tokens issued before the compromise date
remain verifiable against the legitimate key.
5.4. Authorship Attribution Requirements
Any implementation, derivative protocol, or software product that
uses, embeds, or interoperates with Intent Tokens MUST include the
following attribution:
Implements the Intent Provenance Protocol (IPP) v0.1,
authored by Amanda Haberkamp, 2026.
https://ipp.khsovereign.com
Implementations that correctly embed the Genesis Seal in every token
they produce satisfy this attribution requirement at the token level.
Human-readable attribution in documentation, about pages, or license
notices is additionally REQUIRED.
6. Cryptographic Mechanisms
Haberkamp Expires 3 January 2027 [Page 14]
Internet-Draft Intent Provenance Protocol July 2026
6.1. Signature Algorithm
All signatures in this protocol MUST use Ed25519 as defined in
[RFC8032]. Ed25519 is chosen for its combination of high security
(128-bit security level), small key and signature sizes (32-byte
keys, 64-byte signatures), fast verification, and resistance to side-
channel attacks.
Signature values are encoded as Base64URL without padding, prefixed
with "ed25519:". Example: ed25519:47DEQpj8HBSa-_TImW-
5JCeuQeRkm5NMpJWZG3hSuFU
The canonical serialization for signing MUST be produced by: (1)
removing the token_signature field, (2) sorting all keys
lexicographically at every nesting level, (3) serializing to JSON
with no extraneous whitespace, and (4) encoding as UTF-8. This
guarantees deterministic serialization across all conformant
implementations.
6.2. Decentralized Identifiers (DIDs)
All Principal and Agent identities MUST be expressed as DIDs
conforming to the W3C DID Core specification. This specification
recommends the did:key method for its self-sovereign properties. A
did:key DID requires no external registry and is fully resolvable
from the key material alone. Implementations MAY additionally
support did:web, did:ion, or other conformant DID methods provided
they satisfy the following requirements: (a) the DID is resolvable
without requiring communication with the token issuer; (b) the
resolved DID document contains a verificationMethod with the public
key material; and (c) the DID is persistent and does not become
unresolvable if a registry is decommissioned.
6.3. Hash Functions
All hash operations in this specification use SHA3-256 [FIPS202].
SHA3-256 is chosen over SHA2-256 for its different internal
structure, providing defense-in-depth against any future weaknesses
discovered in SHA2-family functions. Hash values are represented as
lowercase hexadecimal strings prefixed with "sha3-256:".
6.4. The Narrowing Invariant
The Narrowing Invariant is the central enforcement mechanism of the
delegation system. It states: for any Derived Token D with Parent
Token P, the following MUST hold for every dimension of the token:
Haberkamp Expires 3 January 2027 [Page 15]
Internet-Draft Intent Provenance Protocol July 2026
D.expires_at <= P.expires_at
D.delegation.depth < P.delegation.depth
D.intent.domain is a sub-domain of P.intent.domain
D.intent.resource_scope is a subset of P.intent.resource_scope
D.intent.quantitative_bounds is a subset of P.intent.quant_bounds
D.intent.prohibited_actions is a superset of P.intent.prohibited
The narrowing_proof field in the delegation object of a Derived Token
contains a signed assertion by the parent agent that the Derived
Token satisfies this invariant. Any receiving agent MUST
independently verify this assertion before accepting the Derived
Token. Verification failure MUST result in token rejection.
7. Delegation and Derived Tokens
7.1. Derivation Rules
When an agent derives a child token from a parent, it MUST:
1. Set parent_token_id to the token_id of the parent.
2. Reduce depth_remaining by exactly one.
3. Set the intent scope to a subset of the parent's scope,
satisfying the Narrowing Invariant.
4. Set expires_at to be no later than the parent's expires_at.
5. Set the agent_id to a unique identifier for the spawned sub-
agent.
6. Compute and embed a valid narrowing_proof.
7. Sign the new token with the parent agent's private key.
8. Link the genesis field identically to the parent. The Genesis
Seal is never re-derived. It propagates unchanged.
7.2. Delegation Depth
The depth_remaining field represents the number of additional sub-
agent spawning levels authorized. An agent holding a token with
depth_remaining = 0 MAY act under the token but MUST NOT issue
Derived Tokens. Attempting to issue a Derived Token from a
depth_remaining = 0 token is a protocol violation.
Haberkamp Expires 3 January 2027 [Page 16]
Internet-Draft Intent Provenance Protocol July 2026
The depth_original field records the delegation depth set by the
original Principal and is preserved across all derived tokens. This
allows auditors to determine how deep in the delegation chain any
given token sits.
7.3. Sub-Agent Spawning
An agent spawning a sub-agent MUST provide the Derived Token to the
sub-agent as its authorization credential. The sub-agent MUST NOT
accept instructions that are inconsistent with its token's intent
scope, even if those instructions come from the spawning parent
agent. The token is the authority, not the parent agent.
CRITICAL SECURITY PROPERTY: An agent MUST refuse instructions from
any source, including its parent agent, that would require it to act
outside its token's authorized scope. This guarantees that a
compromised parent agent cannot instruct a sub-agent to exceed the
scope originally authorized by the human Principal.
8. Revocation
8.1. Revocation Registry
The Revocation Registry is a distributed service that accepts token
revocation notices from authorized principals and returns revocation
status for token IDs. The registry endpoint is specified in the
revocation field of every token.
Revocation is keyed on token_id_hash, the SHA3-256 hash of the
token_id, rather than the token_id itself, to prevent the registry
from constructing a map of all active tokens in the ecosystem. This
preserves privacy while maintaining revocability.
8.2. Polling Requirements
Agents MUST poll the revocation registry at the interval specified by
check_interval_ms before taking any action. The RECOMMENDED default
interval is 5000 milliseconds. For high-stakes actions (financial
transactions above defined thresholds, data deletion, external
communications), agents SHOULD check revocation immediately before
the action regardless of the polling interval.
If the revocation registry is unreachable, agents MUST NOT proceed
with actions unless the token contains an offline_grace_period_ms
field and the offline duration is within that grace period. Agents
MUST NOT cache a "not revoked" status beyond the polling interval.
Haberkamp Expires 3 January 2027 [Page 17]
Internet-Draft Intent Provenance Protocol July 2026
8.3. Mid-Chain Revocation
Revocation of a parent token MUST propagate to all derived tokens.
The registry MUST maintain the full ancestry tree of token derivation
so that when a root or intermediate token is revoked, all descendant
tokens are simultaneously marked as revoked. Agents that have cached
a non-revoked status for a descendant token MUST invalidate that
cache on the next polling cycle.
9. Provenance Chain
9.1. Append-Only Structure
The provenance_chain is an append-only array. Agents MUST append a
record to the chain before taking any action under the token.
Records MUST NOT be modified or removed once appended. Each record
is signed by the acting agent, creating a cryptographically linked
sequence of accountability records.
9.2. Provenance Record Format
{
"record_id": "iprov:pr:uuid4",
"token_id": "iprov:tok:parent-token-id",
"agent_id": "iprov:agent:uuid4",
"timestamp": "ISO8601_UTC",
"action_type": "financial.treasury.transfer | data.read | ...",
"action_summary": "Human-readable description of the action taken",
"resource_id": "Identifier of the resource acted upon",
"outcome": "success | failure | partial",
"within_bounds": true,
"agent_sig": "ed25519:BASE64URL"
}
The within_bounds field is a signed attestation by the agent that the
action fell within the token's authorized scope. This does not
replace independent verification. It provides a convenient audit
field. Any action with within_bounds = false MUST have been blocked.
An action that was not blocked but carries within_bounds = false
indicates a protocol implementation error.
10. Interoperability
Haberkamp Expires 3 January 2027 [Page 18]
Internet-Draft Intent Provenance Protocol July 2026
10.1. Framework Integration
The IPP SDK SHOULD provide integration adapters for the following AI
orchestration frameworks at minimum: LangChain (Python and
JavaScript), AutoGen (Microsoft), CrewAI, Microsoft Semantic Kernel,
and Google Vertex AI Agent Builder. Additional framework adapters
are RECOMMENDED and will be maintained in the IPP SDK repository.
Integration MUST NOT require rewriting existing agent logic. The SDK
MUST provide a wrapper pattern (for example, a decorator in Python, a
higher-order function in JavaScript) that adds IPP governance to
existing agents without modifying their internal structure.
10.2. Cross-Organization Trust
When an agent from Organization A must interact with an agent from
Organization B, the inter-organization trust handshake proceeds as
follows:
1. Organization A's agent presents its Derived Token to Organization
B's agent.
2. Organization B's agent verifies the Genesis Seal (Section 5),
validates the token signature chain back to a Principal DID,
verifies the token has not expired, and checks revocation status.
3. Organization B's agent verifies that the requested interaction
falls within the scope defined in the presented token.
4. If all checks pass, Organization B's agent may respond and
optionally issue its own Derived Token for any downstream actions
on its side.
5. Both agents append provenance records to their respective tokens
for the interaction.
10.3. Domain Taxonomy
The IPP Domain Taxonomy is a hierarchical vocabulary of intent
domains maintained at https://ipp.khsovereign.com/taxonomy. It is
governed as an open standard with community contribution via pull
request to the IPP specification repository. Amanda Haberkamp serves
as the taxonomy steward and has final authority over additions to the
standard namespace. Current top-level domains include:
Haberkamp Expires 3 January 2027 [Page 19]
Internet-Draft Intent Provenance Protocol July 2026
financial.* - Financial operations (treasury, payments, trading)
healthcare.* - Healthcare data and clinical operations
infrastructure.* - Cloud and system infrastructure operations
analytics.* - Data analysis and reporting
communications.* - Email, messaging, and external communications
hr.* - Human resources and personnel operations
legal.* - Legal document and compliance operations
security.* - Security monitoring and response operations
x.* - Private/experimental namespace (not standardized)
11. Security Considerations
Implementers MUST be aware of the following security considerations:
*Private Key Compromise.* If a Principal's private key is
compromised, an attacker can issue Intent Tokens on behalf of that
Principal. Revocation of all tokens issued under the compromised key
MUST be performed immediately. Key compromise does not affect the
Genesis Seal or the founding key.
*Replay Attacks.* Intent Tokens are time-bounded by the expires_at
field. Implementations MUST reject expired tokens. The token_id
SHOULD be checked against a short-term cache of recently used token
IDs to prevent replay of valid, non-expired tokens.
*Scope Creep.* The Narrowing Invariant prevents scope expansion in
derived tokens. However, implementations MUST verify the invariant
independently. They MUST NOT trust the narrowing_proof field without
cryptographic verification.
*Registry Availability.* The Revocation Registry is a critical
dependency. Implementations MUST design for registry unavailability
and MUST fail safe (refuse to act) when the registry is unreachable
and no offline grace period applies.
*Genesis Seal Integrity.* The Genesis Seal binds every Intent Token
to the specification under which it was issued. Implementations MUST
reject tokens with a missing or malformed genesis field, and MUST NOT
issue tokens with a genesis field that does not verify against the
canonical founding public key. Implementations SHOULD cache the
founding public key at first verification and treat any subsequent
change as a security event requiring manual review.
Haberkamp Expires 3 January 2027 [Page 20]
Internet-Draft Intent Provenance Protocol July 2026
12. Privacy Considerations
Intent Tokens contain sensitive information about organizational
operations, including the natural_language description of intent and
resource scope identifiers. Implementations MUST transmit tokens
only over encrypted channels (TLS 1.3 minimum [RFC8446]). The
provenance chain SHOULD be stored in access-controlled infrastructure
with audit logging of all access events.
The Revocation Registry uses token_id_hash rather than token_id to
prevent the registry operator from building a map of active tokens.
Implementations MUST NOT send the full token to the revocation
registry, only the token_id_hash.
13. IANA Considerations
This document requests registration of the URI scheme "iprov:" for
use as the prefix for Intent Token identifiers (iprov:tok:*), Agent
identifiers (iprov:agent:*), and Provenance Record identifiers
(iprov:pr:*). This document also requests registration of the media
type application/intent-token+json for serialized Intent Token
payloads.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC3161] Adams, C., "Internet X.509 Public Key Infrastructure Time-
Stamp Protocol (TSP)", RFC 3161, August 2001,
<https://www.rfc-editor.org/rfc/rfc3161>.
[W3C-DID] Sporny, M., "Decentralized Identifiers (DIDs) v1.0", July
2022, <https://www.w3.org/TR/did-core/>.
Haberkamp Expires 3 January 2027 [Page 21]
Internet-Draft Intent Provenance Protocol July 2026
[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
14.2. Informative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Author's Address
Amanda Haberkamp
Chicago, Illinois
United States
Email: amanda@khsovereign.com
URI: https://ipp.khsovereign.com
Haberkamp Expires 3 January 2027 [Page 22]