| Internet-Draft | Intent Provenance Protocol | March 2026 |
| Haberkamp | Expires 17 September 2026 | [Page] |
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.¶
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 2 September 2026.¶
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.¶
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.¶
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:¶
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.¶
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).¶
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.¶
IPP is designed according to the following principles:¶
Every compliant IPP implementation MUST guarantee the following four properties:¶
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 | +------------------------------------------+¶
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.",
"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"
}
¶
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.¶
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"]
}
¶
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:¶
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.¶
"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:¶
The Founding Key pair was generated according to the following procedure, designed to maximize security and establish a clear, witnessed chain of custody:¶
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¶
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.¶
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¶
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.¶
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.¶
All hash operations in this specification use SHA3-256 [FIPS202]. Hash values are represented as lowercase hexadecimal strings prefixed with "sha3-256:".¶
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.¶
When an agent derives a child token from a parent, it MUST:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
{
"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"
}
¶
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.¶
When an agent from Organization A must interact with an agent from Organization B, the inter-organization trust handshake proceeds as follows:¶
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)¶
Implementers MUST be aware of the following security 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.¶
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.¶