Intent Provenance Protocol (IPP)
draft-haberkamp-ipp-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Amanda Haberkamp | ||
| Last updated | 2026-03-16 | ||
| RFC stream | (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-00
Internet Engineering Task Force A. Haberkamp
Internet-Draft KH Sovereign, Inc.
Intended status: Informational March 2026
Expires: 17 September 2026
Intent Provenance Protocol (IPP)
draft-haberkamp-ipp-00
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 17 September 2026 [Page 1]
Internet-Draft Intent Provenance Protocol March 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 2 September 2026.
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 . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6
3.2. The Four Foundational Properties . . . . . . . . . . . . 7
3.3. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 8
4. The Intent Token . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Token Structure . . . . . . . . . . . . . . . . . . . . . 8
4.2. The Intent Scope Envelope . . . . . . . . . . . . . . . . 9
4.3. Quantitative Bounds . . . . . . . . . . . . . . . . . . . 10
5. The Genesis Seal . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Purpose and Design . . . . . . . . . . . . . . . . . . . 10
5.2. Genesis Seal Structure . . . . . . . . . . . . . . . . . 10
5.3. Key Generation Ceremony . . . . . . . . . . . . . . . . . 11
5.4. Authorship Attribution Requirements . . . . . . . . . . . 12
6. Cryptographic Mechanisms . . . . . . . . . . . . . . . . . . 12
6.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 12
6.2. Decentralized Identifiers (DIDs) . . . . . . . . . . . . 13
6.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 13
6.4. The Narrowing Invariant . . . . . . . . . . . . . . . . . 13
7. Delegation and Derived Tokens . . . . . . . . . . . . . . . . 13
7.1. Derivation Rules . . . . . . . . . . . . . . . . . . . . 13
7.2. Delegation Depth . . . . . . . . . . . . . . . . . . . . 14
7.3. Sub-Agent Spawning . . . . . . . . . . . . . . . . . . . 14
8. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 14
Haberkamp Expires 17 September 2026 [Page 2]
Internet-Draft Intent Provenance Protocol March 2026
8.1. Revocation Registry . . . . . . . . . . . . . . . . . . . 14
8.2. Polling Requirements . . . . . . . . . . . . . . . . . . 14
8.3. Mid-Chain Revocation . . . . . . . . . . . . . . . . . . 15
9. Provenance Chain . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Append-Only Structure . . . . . . . . . . . . . . . . . . 15
9.2. Provenance Record Format . . . . . . . . . . . . . . . . 15
10. Interoperability . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Framework Integration . . . . . . . . . . . . . . . . . 15
10.2. Cross-Organization Trust . . . . . . . . . . . . . . . . 15
10.3. Domain Taxonomy . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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
-- 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 17 September 2026 [Page 3]
Internet-Draft Intent Provenance Protocol March 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).
Haberkamp Expires 17 September 2026 [Page 4]
Internet-Draft Intent Provenance Protocol March 2026
2. Terminology and Definitions
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.
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.
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.
Haberkamp Expires 17 September 2026 [Page 5]
Internet-Draft Intent Provenance Protocol March 2026
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 KH Sovereign, Inc. and open for community
contribution. Examples: financial.treasury,
healthcare.records.read, infrastructure.compute.provision.
DID:
Decentralized Identifier. A W3C standard identifier that 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.
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.
Haberkamp Expires 17 September 2026 [Page 6]
Internet-Draft Intent Provenance Protocol March 2026
* *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:
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.
Haberkamp Expires 17 September 2026 [Page 7]
Internet-Draft Intent Provenance Protocol March 2026
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) |
| - Intent Tokens |
| - Delegation and Derivation |
| - Provenance Chain |
| - Revocation |
+------------------------------------------+
| Cryptographic Identity Layer |
| <- DIDs, Ed25519, TLS |
+------------------------------------------+
| Transport / Infrastructure |
| <- HTTP, gRPC, cloud APIs |
+------------------------------------------+
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:
{
"$schema": "https://ipp.khsovereign.com/schema/v0.1/intent-token.json",
"version": "0.1",
"genesis": {
"spec_hash": "sha3-256:a3f9c2d8e1b74f6a...",
"author_did": "did:key:z6MkHaberkamp...",
"author_name": "Amanda Haberkamp",
"org": "KH Sovereign, Inc.",
"genesis_sig": "ed25519:BASE64URL..."
},
"token_id": "ipp: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, Inc.",
Haberkamp Expires 17 September 2026 [Page 8]
Internet-Draft Intent Provenance Protocol March 2026
"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": "ipp:agent:langchain:treasury-optimizer-v1",
"agent_framework": "langchain",
"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. The Intent Scope Envelope
The intent field encodes the human's goal as a Structured Intent
Envelope. The natural_language field is human-readable but NOT
machine-enforceable. Enforcement is performed against the structured
fields only.
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." (e.g.,
x.mycompany.custom_domain) to avoid collision with future taxonomy
additions.
Haberkamp Expires 17 September 2026 [Page 9]
Internet-Draft Intent Provenance Protocol March 2026
4.3. Quantitative Bounds
The quantitative_bounds object is domain-specific. Standard bound
fields for the financial domain are defined below. Domain-specific
extensions are published in the IPP Domain Taxonomy registry.
"quantitative_bounds": {
"min_balance_threshold": integer,
"max_single_transaction": integer,
"max_total_exposure": integer,
"currency": "ISO 4217 code",
"time_window": "named window or ISO 8601 interval",
"geographic_restriction": ["ISO 3166-1 alpha-2 codes"],
"counterparty_allowlist": ["DID or entity identifier"],
"counterparty_blocklist": ["DID or entity identifier"]
}
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 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
Haberkamp Expires 17 September 2026 [Page 10]
Internet-Draft Intent Provenance Protocol March 2026
"genesis": {
"spec_hash": "sha3-256:[HASH OF IPP SPECIFICATION DOCUMENT]",
"author_did": "did:key:z6MkHaberkampXXXXXXXXXXXXXXXXXXXXXXXX",
"author_name": "Amanda Haberkamp",
"org": "KH Sovereign, Inc.",
"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 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 Amanda Haberkamp's 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. 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:
1. An air-gapped machine (disconnected from all networks) was used
for all key generation operations.
2. The Ed25519 key pair was generated using OpenSSL 3.x:
Haberkamp Expires 17 September 2026 [Page 11]
Internet-Draft Intent Provenance Protocol March 2026
openssl genpkey -algorithm ed25519 \
-out amanda_haberkamp_founding_private.pem
openssl pkey -in amanda_haberkamp_founding_private.pem \
-pubout \
-out amanda_haberkamp_founding_public.pem
3. A DID was generated from the public key using the did:key method.
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 in separate physical locations, and deleted
from all digital media.
6. The public key, DID, and Genesis Seal were committed to the IPP
specification repository with a cryptographic timestamp.
SECURITY NOTE: The Founding Private Key is used exactly once. If the
Founding Private Key is ever compromised, 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.
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, KH Sovereign, Inc., 2026.
https://ipp.khsovereign.com
6. Cryptographic Mechanisms
6.1. Signature Algorithm
All signatures in this protocol MUST use Ed25519 as defined in
[RFC8032]. Signature values are encoded as Base64URL without
padding, prefixed with "ed25519:".
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.
Haberkamp Expires 17 September 2026 [Page 12]
Internet-Draft Intent Provenance Protocol March 2026
6.2. Decentralized Identifiers (DIDs)
All Principal and Agent identities MUST be expressed as DIDs
conforming to the W3C DID Core specification [W3C-DID]. This
specification RECOMMENDS the did:key method for its self-sovereign
properties. 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.
6.3. Hash Functions
All hash operations in this specification use SHA3-256 [FIPS202].
Hash values are represented as lowercase hexadecimal strings prefixed
with "sha3-256:".
6.4. The Narrowing Invariant
For any Derived Token D with Parent Token P, the following MUST hold:
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 ⊆ P.intent.resource_scope
D.intent.quant_bounds ⊆ P.intent.quant_bounds
D.intent.prohibited ⊇ P.intent.prohibited_actions
Any receiving agent MUST independently verify this invariant before
accepting a 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.
Haberkamp Expires 17 September 2026 [Page 13]
Internet-Draft Intent Provenance Protocol March 2026
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. Propagate the genesis field unchanged from the parent token. The
Genesis Seal is never re-derived.
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.
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.
8. Revocation
8.1. Revocation Registry
The Revocation Registry accepts token revocation notices from
authorized principals and returns revocation status for token IDs.
Revocation is keyed on token_id_hash -- the SHA3-256 hash of the
token_id -- to preserve 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. If the revocation registry is
unreachable, agents MUST NOT proceed with actions unless an
offline_grace_period_ms is specified and has not been exceeded.
Haberkamp Expires 17 September 2026 [Page 14]
Internet-Draft Intent Provenance Protocol March 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.
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": "ipp:pr:uuid4",
"token_id": "ipp:tok:parent-token-id",
"agent_id": "ipp:agent:uuid4",
"timestamp": "ISO8601_UTC",
"action_type": "financial.treasury.transfer",
"action_summary": "Human-readable description of action",
"resource_id": "Identifier of resource acted upon",
"outcome": "success | failure | partial | blocked",
"within_bounds": true,
"agent_sig": "ed25519:BASE64URL"
}
10. Interoperability
10.1. Framework Integration
The IPP SDK MUST 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. Integration MUST NOT require
rewriting existing agent logic.
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:
Haberkamp Expires 17 September 2026 [Page 15]
Internet-Draft Intent Provenance Protocol March 2026
1. Organization A's agent presents its Derived Token to Organization
B's agent.
2. Organization B's agent verifies the Genesis Seal, 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 downstream actions.
5. Both agents append provenance records to their respective tokens
for the interaction.
10.3. Domain Taxonomy
The IPP Domain Taxonomy is maintained at https://ipp.khsovereign.com/
taxonomy as an open standard with community contribution via pull
request. KH Sovereign, Inc. serves as the taxonomy steward. Current
top-level domains include:
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, 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.
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.
Haberkamp Expires 17 September 2026 [Page 16]
Internet-Draft Intent Provenance Protocol March 2026
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 when
the registry is unreachable and no offline grace period applies.
12. Privacy Considerations
Intent Tokens contain sensitive information about organizational
operations. Implementations MUST transmit tokens only over encrypted
channels (TLS 1.3 minimum). 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.
13. IANA Considerations
This document requests registration of the URI scheme "ipp:" for use
as the prefix for Intent Token identifiers (ipp:tok:*), Agent
identifiers (ipp:agent:*), and Provenance Record identifiers
(ipp:pr:*). This document also requests registration of the media
type application/ipp+json for serialized Intent Token payloads.
14. References
14.1. Normative References
[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", FIPS PUB 202, August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
[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>.
[RFC3161] Adams, C., "Internet X.509 Public Key Infrastructure Time-
Stamp Protocol (TSP)", RFC 3161, August 2001,
<https://www.rfc-editor.org/rfc/rfc3161>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
Haberkamp Expires 17 September 2026 [Page 17]
Internet-Draft Intent Provenance Protocol March 2026
[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>.
[W3C-DID] Sporny, M., "Decentralized Identifiers (DIDs) v1.0", July
2022, <https://www.w3.org/TR/did-core/>.
14.2. Informative References
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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
KH Sovereign, Inc.
Chicago, Illinois
United States
Email: amanda@khsovereign.com
URI: https://ipp.khsovereign.com
Haberkamp Expires 17 September 2026 [Page 18]