Intent Provenance Protocol (IPP)

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

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

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

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
+------------------------------------------+

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",
    "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:¶

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

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

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

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

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

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

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

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

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)