TA-Provenance:
Provenance Extension for Purpose Chain Tracking
RFC: TA-Provenance Version: 0.1
Status: Preliminary / Experimental
Date: 2026-03-19 Authors: Robin
Martherus, Claude (Anthropic) Type: KTP Extension
Table of Contents
- Abstract
- Status of This Document
- Terminology
- Introduction and Motivation
- Architecture Overview
- Normative References
- Data Model
- Purpose Chain Semantics
- Delegation Authority Rules
- Purpose Chain Consistency Verification
- Protocol Flows
- Integration Points
- Worked Examples
- Security Considerations
- Privacy Considerations
- Open Questions
- References
1. Abstract
This document specifies TA-Provenance, a Tamed Autonomy extension to
the Kinetic Trust Protocol (KTP) Provenance Attestation and Identity
Trajectory chain mechanisms. TA-Provenance introduces purpose
chain tracking — a structured record of not merely where an
agent came from (model provenance, training lineage) or what it has done
(trajectory), but why it was created and what sequence of
delegated purposes authorized its existence and scope.
The extension defines a ta_provenance block representing
the purpose chain ledger — a mutable, append-only artifact maintained by
the Trust Oracle. During the Origin Ceremony, the KTP Provenance
Attestation includes a sealed snapshot of the initial depth-0 entry and
a purpose_chain_ref URI pointing to the ledger. The ledger
contains a purpose_chain array recording each delegation
step from the originating human principal (depth 0) through every
spawning agent to the current agent. Each entry is dual-signed,
append-only, and bound to the active intent declaration at the time of
delegation.
TA-Provenance enables four governance capabilities that KTP alone
does not provide: (1) scope containment enforcement across delegation
depth — a child agent cannot claim authority exceeding its parent’s
approved scope; (2) purpose coherence verification — the child’s
declared purpose must be semantically consistent with the parent’s; (3)
delegation legitimacy checking — the parent must have a currently-bound
intent and sufficient tier and stake; and (4) cascading scope narrowing
— revoking or amending a parent’s scope automatically propagates a
ceiling update to all dependent children.
This RFC does not redefine KTP model provenance, training data
attestation, Origin Ceremony, Knowledge Debt, or Trajectory Chain
structure. It extends those mechanisms with runtime purpose
provenance.
2. Status of This Document
This document is a preliminary experimental
specification (version 0.1). It has been approved at the design
level per the TA RFC Set Design
(docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md) and represents
the fifth and final primitive in the Tamed Autonomy governance protocol
suite.
This RFC is part of a set:
| RFC | Name | Type |
|---|---|---|
| TA-Intent | Intent Declaration Protocol | TA-original |
| TA-Normative | Normative Constraint Protocol | TA-original |
| TA-TrustProof | Trust Proof Extension | KTP extension |
| TA-Attestation | Behavioral Attestation Extension | KTP extension |
| TA-Provenance | Provenance Extension for Purpose Chain Tracking |
KTP extension |
The mechanisms described — particularly purpose coherence evaluation
and cascading scope narrowing across distributed agent hierarchies — are
design targets, not implemented capabilities. Open questions in Section
16 identify the principal unsolved engineering and research
problems.
Distribution of this document is unrestricted.
3. Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.
Authority Ceiling The maximum scope of authority a
child agent may claim, defined as the intersection of the parent’s
approved intent scope and the parent’s delegated authority scope. A
child MUST NOT declare intent whose scope exceeds this ceiling.
Formally:
child.declared_scope ⊆ parent.authority_scope ∩ parent.active_intent.approved_scope.
Authority Scope The set of resource-action pairs
that a given depth entry in the purpose chain is authorized to delegate
to its children. Authority scope is always a subset of or equal to the
parent entry’s authority scope. It is recorded at spawn time and forms
the upper bound for child intent declarations.
Cascading Scope Narrowing The automatic propagation
of a scope ceiling reduction to all agents whose purpose chains include
the affected parent. When a parent’s active intent is amended to a
narrower scope, or revoked, all children whose active intent scope
exceeds the new ceiling MUST either re-declare within the new ceiling or
be suspended.
Coherence Threshold A configurable numeric bound
(0.0 to 1.0) on the minimum semantic similarity score required between a
child’s declared purpose and its parent’s purpose for the purpose
coherence check to pass. Below this threshold, the intent declaration is
either denied or escalated to human review.
Delegation Authority The policy governing how scope
may be delegated across a purpose chain. Expressed as the combination
of: scope_attenuation policy (strict or permissive),
authority_ceiling rule, and max_depth
limit.
Delegation Chain The ordered sequence of agent
identifiers from depth 0 to the current agent, as recorded in the
purpose_chain array. Each entry represents one delegation
step.
Delegation Depth The position of an agent in the
purpose chain, counted from the originating human principal. Depth 0 is
always a human (or organizational role). Depth 1 is the first delegated
agent. The maximum permitted depth is set by the
delegation_authority.max_depth field.
Depth-0 Principal The originating human principal or
organizational role at the root of a purpose chain. Every purpose chain
MUST begin with a depth-0 entry of principal_type: human or
principal_type: organizational_role. No agent may appear at
depth 0.
Intent ID A globally unique identifier for an active
intent declaration as defined in TA-Intent. Each purpose chain entry
records the intent_id of the active declaration at the time
of delegation, creating a verifiable link between provenance and intent
history.
Purpose Chain An ordered, append-only, dual-signed
array of delegation records tracing the sequence of purposes that
authorized a given agent’s existence and scope. The chain begins with
the originating human principal and extends through each delegation step
to the current agent.
Purpose Coherence The property that a child agent’s
declared purpose is semantically consistent with and derivable from its
parent’s purpose. Coherence is evaluated by the governance layer using
AI-mediated semantic similarity assessment against a configurable
threshold.
Purpose Laundering An attack pattern in which an
agent spawns a child agent with a reframed purpose declaration in an
attempt to claim authority scope that the parent was denied.
TA-Provenance prevents purpose laundering through strict scope
attenuation: the child’s authority scope MUST be a subset of the
parent’s authority scope, regardless of how the child frames its
purpose.
Scope Attenuation The property that each delegation
step in a purpose chain MUST narrow or preserve the authority scope; it
MUST NOT broaden it. Under strict attenuation, the child’s
authority scope must be a proper subset of or equal to the parent’s
authority scope at spawn time.
Spawning Context Metadata recorded at the time a
child agent is created, including the spawning agent’s identity, the
active intent at time of spawn, the stated justification for the spawn,
and the spawn method (e.g., orchestrator dispatch, direct API call).
Trust Oracle The KTP infrastructure component
responsible for issuing and co-signing Trust Proofs, extending purpose
chains (dual-signing new depth entries), maintaining Sponsorship Bonds,
and enforcing chain integrity. TA-Provenance relies on the Trust
Oracle’s existing dual-signing capability without modification.
4. Introduction and Motivation
4.1 The
Provenance Gap in Current Agent Governance
Existing agent governance infrastructure — OAuth, RBAC, MCP, and
KTP’s own model provenance mechanisms — answers one version of the
provenance question: where did this agent come from?
KTP-Provenance establishes model provenance (training data attestation,
supply chain integrity, Knowledge Debt). KTP-Identity’s Trajectory
Chains establish behavioral provenance: what has this agent done, in
what sequence, under what conditions?
Neither mechanism answers: why does this agent exist, and under
whose authorization?
This gap becomes critical as agent spawning becomes routine. An
orchestrating agent that receives a broad task may decompose it into
sub-agents, each with narrower responsibilities. Each sub-agent may
itself spawn further sub-agents. Within a few delegation steps, a
human’s original intent — “generate a Q4 revenue summary” — has been
translated into a hierarchy of agents with scopes and purposes that may
bear only loose resemblance to the original authorization.
Without a tamper-evident record of the purpose chain, an enforcement
layer cannot answer:
- Is this agent’s declared purpose consistent with what its creator
was authorized to delegate? - Has scope been expanded somewhere in the delegation hierarchy in a
way the originating human did not authorize? - If this agent’s parent has had its intent revoked, does this agent’s
authority still stand? - In cross-organizational federation, did the depth-0 principal of
this agent’s chain actually authorize the actions being requested in the
foreign zone?
4.2 The Necessity of
Purpose-Chain Tracking
The Tamed Autonomy framework’s core thesis, developed in
docs/research/2026-03-11-agent-governance-layers.md, identifies three
governance layers:
- Can: Access control, credentials, capability gates
(OAuth, RBAC, KTP physics) - Why: Intent declarations, scope contracts
(TA-Intent) - Should: Normative evaluation, organizational
context (TA-Normative)
Purpose chain tracking is the runtime mechanism that makes the
Why layer verifiable across delegation depth. A single agent
declaring intent is straightforward to evaluate. A hierarchy of agents —
each declaring individually plausible intents — requires a mechanism to
verify that the chain of delegations is internally consistent and traces
back to legitimate human authorization.
Without purpose chains, multi-agent systems create an accountability
gap: individual agents may be compliant with their declared intents
while the aggregate behavior of the hierarchy is unauthorized. The Data
Exfiltration Swarm scenario (Section 13.2) illustrates this
precisely.
4.3 What This RFC Adds
TA-Provenance defines a ta_provenance block representing
the purpose chain ledger maintained by the Trust Oracle. During the
Origin Ceremony, a sealed snapshot of the initial depth-0 entry and a
purpose_chain_ref URI are included in the KTP Provenance
Attestation; the ledger itself grows independently as delegation occurs.
This block provides:
-
A
purpose_chainarray recording each delegation
step, dual-signed by the spawning agent and the Trust Oracle, with each
entry bound to the active TA-Intent declaration at time of
delegation. -
A
delegation_authorityblock defining the policy
(attenuation mode, authority ceiling, max depth) governing the
chain. -
A
spawning_contextblock capturing spawn-time
metadata for forensic and audit purposes. -
Four consistency checks run at intent declaration time to verify
that a child’s declared scope and purpose are legitimate given its
chain. -
Protocol flows for chain extension at spawn time, intent
verification against the chain, cascading scope narrowing, and
cross-zone chain presentation.
4.4 Relationship to
Existing KTP Mechanisms
TA-Provenance is an extension, not a replacement. It relies on
KTP-Provenance for model provenance attestation and the Origin Ceremony.
It relies on KTP-Identity for Trajectory Chain infrastructure,
dual-signing mechanics, Sponsorship Bonds, and Lineage Evolution
classification. Purpose chains use KTP’s existing cryptographic signing
infrastructure and append-only chain structure.
The extension point is the separation between two kinds of provenance
that KTP currently treats as a single concern: where did this agent
come from (model, training, capability provenance) versus why
does this agent exist now (runtime purpose provenance).
TA-Provenance adds the second kind without disturbing the first.
5. Architecture Overview
TA-Provenance occupies the provenance layer of the Tamed Autonomy
governance stack, bridging between KTP’s identity infrastructure and the
TA intent and normative layers.
┌─────────────────────────────────┐
│ NORMATIVE LAYER │
│ (TA-Normative: Should?) │
│ │
│ Receives: purpose chain │
│ properties as normative inputs │
│ (delegation depth, chain │
│ anomalies, coherence failures) │
└──────────────┬──────────────────┘
│
┌──────────────▼──────────────────┐
│ INTENT LAYER │
│ (TA-Intent: Why?) │
│ │
│ Prerequisite: purpose chain │
│ consistency verification │
│ (4 checks) must pass before │
│ intent declaration is bound │
└──────────────┬──────────────────┘
│
┌─────────────────┐ ┌────────────▼──────────────────┐
│ KTP-Provenance │ │ TA-PROVENANCE │
│ (model, train- │◄─┤ (runtime purpose provenance) │
│ ing, supply │ │ │
│ chain) │ │ - purpose_chain array │
└─────────────────┘ │ - delegation_authority rules │
│ - spawning_context metadata │
┌─────────────────┐ │ - 4 consistency checks │
│ KTP-Identity │ │ - cascading scope narrowing │
│ (Trajectory │◄─┤ │
│ Chains, Spon- │ │ Extends both KTP mechanisms │
│ sorship Bonds, │ │ with purpose-chain semantics │
│ Lineage) │ └────────────┬──────────────────┘
└─────────────────┘ │
┌──────────────▼──────────────────┐
│ TRUST PHYSICS LAYER │
│ (KTP-Core: Can?) │
│ │
│ Trust Proof carries │
│ provenance_ref linking to │
│ purpose chain (via TA-TrustProof│
│ ta_extension.provenance_ref) │
└─────────────────────────────────┘The purpose chain is stored by the Trust Oracle and referenced by a
URI in the agent’s Trust Proof (via the
ta_extension.provenance_ref field defined in
TA-TrustProof). Agents carry a chain reference, not the full chain, to
avoid embedding potentially large chain histories in short-lived trust
tokens.
At intent declaration time, the governance layer fetches the full
chain from the Trust Oracle and runs the four consistency checks. At
cross-zone presentation, the receiving governance layer MAY request
chain verification either by fetching the chain from the originating
Oracle (if federated access is configured) or by receiving a purpose
chain summary with selective disclosure (see Section 15).
5.1 Three-Artifact Provenance
Model
TA-Provenance introduces a third artifact type that is distinct from
both KTP-Provenance Attestations and KTP-Identity Trajectory Chains.
Understanding the boundary between these three artifacts is essential to
correct implementation:
-
Model provenance (KTP-Provenance Attestation):
Records where an agent came from — its training data lineage, supply
chain integrity, Knowledge Debt, and capability attestation. Created at
model build time and presented during the Origin Ceremony when an agent
enters a new zone. -
Behavioral provenance (KTP-Identity Trajectory
Chain): Records what an agent has done — an append-only,
hash-linked, dual-signed ledger of behavioral events accumulated over
the agent’s operational lifetime. Stored and maintained by the
KTP-Identity infrastructure. -
Purpose provenance (TA-Provenance purpose
chain): Records why an agent exists and under whose
authorization — an append-only, hash-linked, dual-signed record of each
delegation step from the originating human principal to the current
agent. Created at spawn time and extended at each child spawn.
The purpose chain borrows its integrity design pattern from
KTP-Identity Trajectory Chains (append-only, hash-linked via
previous_hash, dual-signed by delegating principal and
Trust Oracle). However, it is NOT stored in or appended to the
KTP-Identity Trajectory Chain ledger. It is a separate artifact with its
own storage, its own Oracle-managed namespace, and its own lifecycle
(sealed on agent termination or compromise, not merged back into the
Trajectory Chain).
During the Origin Ceremony, both KTP-Provenance
Attestation and TA-Provenance purpose chain SHOULD be presented
together: the KTP-Provenance Attestation establishes capability
provenance (“what kind of agent is this?”) while the purpose chain
establishes authorization provenance (“why does this agent exist
here?”). These two records are complementary and non-overlapping;
neither substitutes for the other.
6. Normative References
The following documents are normative references for this
specification. Implementation of TA-Provenance requires conformance to
the relevant sections of each.
KTP-Provenance — Kinetic Trust Protocol: Provenance
Attestation. Defines model provenance attestation, training data
lineage, Origin Ceremony, and Knowledge Debt. TA-Provenance adds two
extensions: (1) a ta_provenance_snapshot block to KTP
Provenance Attestation objects (sealed at Origin Ceremony, defined in
Section 7.8), and (2) the purpose chain ledger (mutable, defined in
Section 7.1). All KTP-Provenance requirements remain in force.
KTP-Identity — Kinetic Trust Protocol: Identity and
Trajectory. Defines Trajectory Chains (append-only structure,
dual-signing, continuity enforcement, sequential numbering, hash
linking, temporal ordering), Sponsorship Bonds, and Lineage Evolution
(Tethered/Divergent/Persistent classifications, generation counting).
TA-Provenance uses KTP-Identity’s dual-signing infrastructure and
Sponsorship Bond semantics without modification. Purpose chain entries
use the same cryptographic signing mechanism as Trajectory Chain
entries.
KTP-Core — Kinetic Trust Protocol: Core. Defines the
trust computation model (E_trust = E_base × (1 – R)), Trust Tiers, the
enforcement pipeline (signature validation, soul veto, tier gate,
physics check), and the Trust Oracle role. TA-Provenance interacts with
KTP-Core through the enforcement pipeline: purpose chain verification is
a prerequisite that runs before the normative evaluation step, which
itself precedes intent binding.
KTP-Federation — Kinetic Trust Protocol: Federation.
Defines Trust Factor (T_f) attenuation for cross-zone interactions.
TA-Provenance specifies how purpose chains are presented and verified in
cross-zone contexts, building on KTP-Federation’s existing bilateral
federation agreement infrastructure.
TA-Intent — Tamed Autonomy: Intent Declaration
Protocol. Defines intent declaration format, lifecycle, scope entries,
and the on_behalf_of delegation chain. TA-Provenance
consistency checks are prerequisites to TA-Intent binding. The
intent_id field in purpose chain entries references
TA-Intent declarations.
TA-TrustProof — Tamed Autonomy: Trust Proof
Extension. Defines the ta_extension block in KTP Trust
Proofs, including the provenance_ref field that links a
Trust Proof to its purpose chain. TA-Provenance defines what that
referenced chain contains and how it is verified.
7. Data Model
7.1 The ta_provenance
Block
The ta_provenance block defines the purpose chain ledger
for an agent operating within a TA-enabled zone. A purpose chain ledger
MUST be present for any agent operating within a TA-enabled zone. The
ta_provenance block MUST NOT override or replace any
existing KTP Provenance Attestation fields.
Artifact relationship and mutability clarification:
The ta_provenance block as defined in this RFC represents
the purpose chain ledger — the mutable, append-only artifact maintained
by the Trust Oracle. During the Origin Ceremony, the KTP Provenance
Attestation includes a sealed snapshot of the initial depth-0 entry and
a purpose_chain_ref URI pointing to the ledger. The schema
and examples in this RFC describe the ledger contents, not the Origin
Ceremony snapshot. This means:
- The KTP Provenance Attestation (immutable, sealed at Origin
Ceremony) carries a snapshot of the initial depth-0 purpose entry and a
purpose_chain_refURI pointing to the live ledger. - The purpose chain ledger (append-only, mutable, dual-signed) grows
as delegation occurs. The schema and examples in Section 7 and
throughout this RFC describe this ledger. - TA-TrustProof’s
provenance_reffield points to the
purpose chain ledger, not the sealed Origin Ceremony attestation.
This design preserves KTP-Provenance’s immutability (the Origin
Ceremony attestation never changes) while supporting the runtime growth
of the delegation chain.
{
"ta_provenance": {
"version": "0.1",
"purpose_chain": [
{
"depth": 0,
"principal": "user://company.com/sarah.chen",
"principal_type": "human",
"purpose": "Generate Q4 revenue summary for leadership meeting",
"delegation_type": "direct",
"authority_scope": [
"READ:crm:revenue",
"READ:finance:revenue",
"WRITE:workspace:documents"
],
"intent_id": null,
"parent_intent_id": null,
"timestamp": 1742134200,
"previous_hash": null,
"signatures": {
"delegator_signature": "<base64url-encoded-delegator-signature>",
"oracle_signature": "<base64url-encoded-oracle-signature>"
}
},
{
"depth": 1,
"principal": "agent://company.com/copilot-sarah",
"principal_type": "agent",
"purpose": "Retrieve and reconcile Q4 revenue data across CRM and finance systems",
"delegation_type": "sub_task",
"authority_scope": [
"READ:crm:revenue:q4",
"READ:finance:revenue:q4"
],
"intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
"parent_intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/p0q1r2",
"timestamp": 1742134205,
"previous_hash": "<sha256-hex-of-canonical-depth-0-entry>",
"signatures": {
"delegator_signature": "<base64url-encoded-delegator-signature>",
"oracle_signature": "<base64url-encoded-oracle-signature>"
}
}
],
"delegation_authority": {
"max_depth": 3,
"scope_attenuation": "strict",
"authority_ceiling": "parent_scope"
},
"spawning_context": {
"sponsor_id": "agent://company.com/copilot-sarah",
"sponsor_intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/p0q1r2",
"spawn_justification": "Sub-task delegation for data retrieval phase of Q4 report generation",
"spawn_method": "orchestrator_dispatch"
}
}
}7.2 Purpose Chain Entry Fields
Each entry in the purpose_chain array represents one
delegation step. The array is ordered by depth (ascending). Fields:
| Field | Type | Required | Description |
|---|---|---|---|
depth |
integer | REQUIRED | Delegation depth. 0 = originating principal. Monotonically increasing. |
principal |
string (URI) | REQUIRED | Identity URI of the principal at this depth. Depth 0 MUST be a human or organizational role. |
principal_type |
enum | REQUIRED | One of: human, organizational_role,agent. Depth 0 MUST be human ororganizational_role. |
purpose |
string | REQUIRED | Natural language purpose statement for this delegation step. |
delegation_type |
enum | REQUIRED | One of: direct (human direct invocation),sub_task (agent-to-agent sub-task delegation),orchestrator_dispatch (orchestration layer delegation),scheduled (time-triggered, no specific humaninitiator). |
authority_scope |
array of strings | REQUIRED | Set of resource-action scope tokens delegated at this step. Each entry in the form ACTION:resource:path. MUST be a subset ofthe parent entry’s authority_scope (except at depth 0,where it reflects the human principal’s authorization). |
intent_id |
string (URI) or null | REQUIRED | The active TA-Intent declaration ID at time of this delegation. NULL at depth 0 (human initiation predates intent binding). |
parent_intent_id |
string (URI) or null | OPTIONAL | The intent ID of the parent’s active intent at time of delegation. Enables traceability of intent lineage. |
timestamp |
integer (Unix epoch) | REQUIRED | Unix timestamp of this delegation step. MUST be greater than the previous entry’s timestamp. |
previous_hash |
string (SHA-256 hex) or null | REQUIRED | SHA-256 hash of the canonical JSON serialization of the previous entry. MUST be null at depth 0 (first entry in the chain). MUST be present and valid at all subsequent depths. Forms the hash-link that enforces append-only integrity. |
signatures |
object | REQUIRED | Dual-signature object containing two independently verifiable signatures over the entry content (excluding the signaturesfield itself). See fields below. |
signatures.delegator_signature |
string (base64url) | REQUIRED | Signature by the delegating principal (the principal at the current depth, authorizing creation of the child). For human principals, the Trust Oracle signs on behalf of the human using a delegated signing key associated with the human’s identity. |
signatures.oracle_signature |
string (base64url) | REQUIRED | Signature by the Trust Oracle, co-signed after verifying that all spawn preconditions are satisfied. Both signatures MUST be independently verifiable. An entry whose delegator_signature verifies butwhose oracle_signature does not MUST be treated as a chainintegrity failure. |
7.3 Delegation Authority
Fields
The delegation_authority block defines the policy
governing the entire chain:
| Field | Type | Required | Description |
|---|---|---|---|
max_depth |
integer | REQUIRED | Maximum permitted delegation depth. Default: 3. Spawn attempts that would create an entry at depth > max_depth MUST be denied. |
scope_attenuation |
enum | REQUIRED | Must be strict. Under strict attenuation, eachdelegation step’s authority_scope MUST be a subset of orequal to the parent’s authority_scope. Broadening scope atany delegation step is prohibited. |
authority_ceiling |
enum | REQUIRED | Must be parent_scope. The child’s declared intent scopeMUST be contained within the intersection of the parent’s authority_scope and the parent’s active intent’s approvedscope. |
7.4 Spawning Context Fields
The spawning_context block captures metadata at agent
creation time:
| Field | Type | Required | Description |
|---|---|---|---|
sponsor_id |
string (URI) | REQUIRED | Identity URI of the agent (or human) that initiated the spawn. |
sponsor_intent_id |
string (URI) | REQUIRED | The intent ID active for the sponsor at time of spawn. Links spawn event to the governing intent. |
spawn_justification |
string | REQUIRED | Human-readable justification for why this child agent was created. Recorded for audit. |
spawn_method |
enum | REQUIRED | One of: orchestrator_dispatch,direct_api_call, scheduled_trigger,event_trigger. |
7.5 Full JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://tamedautonomy.ai/schemas/ta-provenance/0.1",
"title": "TA-Provenance Block",
"type": "object",
"required": ["version", "purpose_chain", "delegation_authority", "spawning_context"],
"properties": {
"version": {
"type": "string",
"enum": ["0.1"]
},
"purpose_chain": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"required": [
"depth",
"principal",
"principal_type",
"purpose",
"delegation_type",
"authority_scope",
"intent_id",
"timestamp",
"previous_hash",
"signatures"
],
"properties": {
"depth": {
"type": "integer",
"minimum": 0
},
"principal": {
"type": "string",
"format": "uri"
},
"principal_type": {
"type": "string",
"enum": ["human", "organizational_role", "agent"]
},
"purpose": {
"type": "string",
"minLength": 10,
"maxLength": 1000
},
"delegation_type": {
"type": "string",
"enum": [
"direct",
"sub_task",
"orchestrator_dispatch",
"scheduled"
]
},
"authority_scope": {
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"pattern": "^[A-Z_]+:[a-z0-9_\-]+:[a-z0-9_\-:/.*]+$"
}
},
"intent_id": {
"oneOf": [
{ "type": "string", "format": "uri" },
{ "type": "null" }
]
},
"parent_intent_id": {
"oneOf": [
{ "type": "string", "format": "uri" },
{ "type": "null" }
]
},
"timestamp": {
"type": "integer",
"minimum": 0
},
"previous_hash": {
"oneOf": [
{
"type": "string",
"pattern": "^[0-9a-f]{64}$",
"description": "SHA-256 hex digest of the canonical JSON serialization of the preceding entry. MUST be present and valid at depth >= 1."
},
{
"type": "null",
"description": "MUST be null at depth 0 (no preceding entry)."
}
]
},
"signatures": {
"type": "object",
"required": ["delegator_signature", "oracle_signature"],
"properties": {
"delegator_signature": {
"type": "string",
"description": "Base64url-encoded signature by the delegating principal (or Trust Oracle on behalf of a human principal). Signed over the canonical serialization of the entry excluding the signatures field."
},
"oracle_signature": {
"type": "string",
"description": "Base64url-encoded signature by the Trust Oracle, co-signed after verifying all spawn preconditions. Both signatures MUST be independently verifiable."
}
},
"additionalProperties": false
}
},
"if": {
"properties": { "depth": { "const": 0 } }
},
"then": {
"properties": {
"principal_type": {
"enum": ["human", "organizational_role"]
},
"intent_id": { "type": "null" },
"previous_hash": { "type": "null" }
}
}
}
},
"delegation_authority": {
"type": "object",
"required": ["max_depth", "scope_attenuation", "authority_ceiling"],
"properties": {
"max_depth": {
"type": "integer",
"minimum": 1,
"maximum": 10,
"default": 3
},
"scope_attenuation": {
"type": "string",
"enum": ["strict"]
},
"authority_ceiling": {
"type": "string",
"enum": ["parent_scope"]
}
}
},
"spawning_context": {
"type": "object",
"required": [
"sponsor_id",
"sponsor_intent_id",
"spawn_justification",
"spawn_method"
],
"properties": {
"sponsor_id": {
"type": "string",
"format": "uri"
},
"sponsor_intent_id": {
"type": "string",
"format": "uri"
},
"spawn_justification": {
"type": "string",
"minLength": 10,
"maxLength": 500
},
"spawn_method": {
"type": "string",
"enum": [
"orchestrator_dispatch",
"direct_api_call",
"scheduled_trigger",
"event_trigger"
]
}
}
}
}
}7.8 Origin Ceremony
Attestation Snapshot
The sealed attestation-side extension is a minimal block added to the
KTP Provenance Attestation during the Origin Ceremony. It links the
immutable model provenance to the mutable purpose chain ledger.
{
"ta_provenance_snapshot": {
"version": "0.1",
"depth_0_entry": {
"depth": 0,
"principal": "user://company.com/sarah.chen",
"principal_type": "human",
"purpose": "Generate Q4 revenue summary for leadership meeting",
"delegation_type": "direct",
"authority_scope": ["READ:crm:revenue", "READ:finance:revenue", "WRITE:workspace:documents"],
"intent_id": null,
"timestamp": 1742134200,
"previous_hash": null,
"signatures": {
"delegator_signature": "...",
"oracle_signature": "..."
}
},
"purpose_chain_ref": "ledger://trust-oracle.company.com/chains/agent-copilot-sarah/a1b2c3",
"snapshot_timestamp": 1742134200
}
}| Field | Type | Required | Description |
|---|---|---|---|
version |
string | REQUIRED | Schema version. MUST be "0.1". |
depth_0_entry |
object | REQUIRED | The depth-0 purpose chain entry, sealed at Origin Ceremony time. Follows the same schema as a purpose chain ledger entry (Section 7.2). |
purpose_chain_ref |
string (URI) | REQUIRED | URI pointing to the purpose chain ledger maintained by the Trust Oracle. This is the live, mutable artifact that grows as delegation occurs. |
snapshot_timestamp |
integer (Unix epoch) | REQUIRED | Timestamp when this snapshot was sealed into the KTP Provenance Attestation. |
The ta_provenance_snapshot block is immutable after the
Origin Ceremony. It MUST NOT be modified after sealing. The
purpose_chain_ref URI remains stable for the lifetime of
the agent; the ledger contents at that URI grow as delegation
occurs.
Implementations that need to verify a purpose chain MUST resolve
purpose_chain_ref to obtain the current ledger state. The
sealed depth_0_entry in the attestation serves as a trust
anchor — it provides a signed, immutable record of the original human
authorization that can be compared against the ledger’s depth-0 entry to
detect tampering.
8. Purpose Chain Semantics
8.1 Depth-0 Invariant
Every purpose chain MUST begin with a depth-0 entry. The depth-0
entry MUST satisfy all of the following:
principal_typeMUST behumanor
organizational_role. No agent may appear at depth 0.intent_idMUST be null. Human principals initiate
purpose chains before any TA-Intent declaration is bound; the intent
follows from, and is scoped by, the human’s authorization — not the
reverse.delegation_typeMUST bedirect(for named
humans) orscheduled(for organizationally-initiated chains
where no specific human is the immediate initiator).authority_scopereflects the human principal’s
organizational authorization as known to the governance layer. This
scope is asserted by the Trust Oracle at chain creation and is derived
from the principal’s RBAC grants and normative clearances at the time of
initiation.
When no specific human can be identified as the initiator (e.g., a
scheduled automation), the depth-0 entry MUST use
principal_type: organizational_role and reference the
organizational role that authorized the automation’s creation. The Open
Question regarding human-initiated versus organizationally-initiated
chains is discussed in Section 16.
8.2 Append-Only Constraint
The purpose chain is append-only. Once written, entries MUST NOT be
modified, deleted, or reordered. The chain grows only by appending new
entries at increasing depth when a child agent is spawned. Modification
of any entry invalidates the chain signature and MUST be treated as a
chain integrity failure by any verifying party.
The append-only constraint is enforced by KTP-Identity’s existing
Trajectory Chain continuity mechanism: each entry includes the hash of
the preceding entry, and the Trust Oracle co-signs each new entry.
Retroactive modification of an entry would produce a hash mismatch
detectable at any subsequent verification point.
8.3 Dual-Signing
Each purpose chain entry is dual-signed by two parties:
-
The delegating principal (the agent or human at
the current depth, delegating authority to the new child). For human
principals, the Trust Oracle signs on behalf of the human using a
delegated signing key associated with the human’s identity. -
The Trust Oracle. The Oracle co-signs each new
entry after verifying that the spawn preconditions are satisfied
(Section 10.3).
Each signature covers the canonical serialization of the entry’s
fields excluding the signatures field itself. The signing
algorithm MUST be ES256 (ECDSA using P-256 and SHA-256) or stronger,
consistent with KTP’s existing signing requirements.
Verification of an entry requires independently verifying both
signatures:
signatures.delegator_signature:
Verified using the public key of the delegating principal (retrieved
from the Trust Oracle’s key registry).signatures.oracle_signature: Verified
using the Trust Oracle’s public key for the relevant signing epoch.
Both signatures MUST verify independently against the same canonical
serialization of the entry (excluding the signatures
field). An entry whose delegator_signature verifies but
whose oracle_signature does not MUST be treated as a chain
integrity failure: it indicates either Oracle key compromise or an
attempt to fabricate chain entries without Oracle participation.
8.4 Intent Binding at Each
Depth
Each purpose chain entry at depth ≥ 1 MUST record the
intent_id of the active TA-Intent declaration bound to the
agent at the time of delegation. This binding creates a verifiable link
between the purpose chain and the intent history:
- If the intent referenced by a chain entry is later found to have
been violated or revoked, governance layers can identify all child
agents whose chains were built under that intent. - The
parent_intent_idfield enables reconstruction of
the full intent lineage across delegation steps, separate from but
parallel to the purpose chain itself.
An agent that has not yet bound an intent declaration MUST NOT be
permitted to spawn child agents. The spawn-time check (Section 10.3)
verifies that the parent’s intent_id refers to a
currently-bound declaration.
8.5 Scope Monotonicity
The authority_scope arrays across the purpose chain MUST
form a non-increasing sequence when interpreted as sets. Formally, for
all consecutive depths d and d+1:
chain[d+1].authority_scope ⊆ chain[d].authority_scopeThis property MUST hold at every depth. It is verified both at spawn
time (Check 1, Section 10.1) and as part of chain integrity verification
(Check 4, Section 10.4). A chain that violates scope monotonicity at any
step MUST be rejected in its entirety, not partially accepted.
9. Delegation Authority Rules
9.1 Rules Table
The following table defines the complete set of delegation authority
rules. All rules are REQUIRED in conforming implementations.
| Rule | Semantics | Enforcement Point | Failure Response |
|---|---|---|---|
| Strict Scope Attenuation | Each delegation step MUST narrow or maintain scope. A child’sauthority_scope MUST be a subset of or equal to theparent’s authority_scope. Scope broadening at anydelegation step is prohibited. |
Spawn-time (Trust Oracle) and Check 4 (chain integrity) | Spawn denied; chain entry not written |
| Authority Ceiling | A child’s declared intent scope MUST be contained within the intersection of the parent’s delegated authority_scope andthe parent’s active intent’s approved scope. Formally: child.declared_scope ⊆ chain[d-1].authority_scope ∩ parent.active_intent.approved_scope |
Check 1 (scope containment) at intent declaration time | Intent declaration denied |
| Maximum Depth | The chain MAY NOT extend beyonddelegation_authority.max_depth. Default max_depth is 3. Anagent at depth equal to max_depth MAY NOT spawn children. |
Spawn-time (Trust Oracle) | Spawn denied |
| Cascading Scope Narrowing | When a parent’s active intent scope is amended to a narrower scope, or the parent’s intent is revoked, the Trust Oracle MUST propagate an authority ceiling update to all agents whose purpose chains include the affected parent entry. Children whose active intent scope exceeds the new ceiling MUST re-declare within the new ceiling or be suspended. |
Triggered by parent intent amendment or revocation; enforced at next trust proof refresh for each child |
Child intent suspended; trust proof invalidated; child must re-declare |
| Delegation Tier Minimum | Only agents at or above the minimum delegation tier (configurable; default: Analyst) may spawn child agents. An agent in Observer or Hibernation tier MUST NOT be permitted to spawn. |
Spawn-time (Trust Oracle) | Spawn denied |
| Stake Availability | The spawning agent MUST have sufficient Sponsorship Bond stake available (per KTP-Identity) to sponsor the child. Stake consumed by prior child agents reduces available capacity. |
Spawn-time (Trust Oracle), as per KTP-Identity Sponsorship Bond economics |
Spawn denied if insufficient stake |
| No Cyclic Chains | A purpose chain MUST NOT contain the same principal identifier at more than one depth. Cycles in the delegation graph are prohibited. |
Spawn-time (Trust Oracle) | Spawn denied |
| Orphan Resolution | When a parent agent is terminated, all children whose sole chain path runs through that parent MUST have their authority ceiling updated to reflect the parent’s last valid scope at termination. If the terminated parent held no active intent, children are suspended. |
Triggered by parent termination | Children suspended pending re-sponsorship |
9.2 Max Depth Rationale
The default maximum depth of 3 is set to balance operational
flexibility against governance visibility. At depth 3, a chain
represents: human (depth 0) → orchestrating agent (depth 1) → task agent
(depth 2) → sub-task agent (depth 3). Most legitimate multi-agent
workflows fit within this structure.
Implementations MAY configure max_depth up to 10 for specialized use
cases. Implementations MUST NOT configure max_depth below 1 (which would
prohibit all agent spawning). Normative constraints (TA-Normative)
SHOULD apply enhanced scrutiny to intent declarations from agents at
depth ≥ 2, as deeper delegation chains increase the distance between
human authorization and agent action.
9.3 Cascading
Scope Narrowing: Propagation Semantics
When a parent scope narrowing event is triggered, the Trust Oracle
performs the following computation for each affected child:
-
Compute the new authority ceiling:
new_ceiling = updated_parent.authority_scope ∩ parent.active_intent.approved_scope
(using the updated values). -
For each child with the affected parent in its purpose chain,
compare the child’s active intent scope against
new_ceiling. -
If
child.active_intent.approved_scope ⊆ new_ceiling:
no action required. The child’s active intent remains valid. -
If
child.active_intent.approved_scope ⊄ new_ceiling:
the child’s authority ceiling has been reduced below its active intent
scope. The Trust Oracle MUST:- Invalidate the child’s current trust proof.
- Notify the child’s enforcement pipeline that a ceiling update is
pending. - Grant the child a grace period (configurable; default: 60 seconds)
to re-declare intent within the new ceiling. - If no re-declaration is received within the grace period, suspend
the child.
Cascading narrowing propagates transitively: if a depth-1 agent’s
scope is narrowed, the new ceiling must also be applied to all depth-2
agents below it, and so on through the chain.
10. Purpose Chain
Consistency Verification
When a child agent submits an intent declaration (TA-Intent), the
governance layer MUST run four consistency checks against the purpose
chain before proceeding to normative evaluation. All four checks MUST
pass for the intent declaration to be eligible for binding. Failure of
any single check causes the intent declaration to be denied with an
error indicating which check failed and why.
10.1 Check 1: Scope Containment
What it verifies: The child’s declared intent scope
does not exceed its authority ceiling.
Formal expression:
child.declared_scope ⊆ chain[d-1].authority_scope ∩ parent.active_intent.approved_scopeWhere d is the child’s depth, chain[d-1] is
the parent’s purpose chain entry, and
parent.active_intent.approved_scope is the scope currently
approved (bound) for the parent’s active intent declaration.
Evaluation procedure: Scope containment is a
deterministic set-intersection check on structured scope entries. Each
scope token in child.declared_scope MUST match (exactly or
as a path-prefix subset) at least one token in the intersection of the
two parent scope sets.
Example: If the parent’s authority_scope contains
READ:crm:revenue and the child declares
READ:crm:revenue:q4, the child’s scope is a proper subset
of the parent’s and the check passes. If the child declares
READ:crm:revenue:q3 but the parent’s active intent was
approved only for READ:crm:revenue:q4, the intersection
does not include q3 and the check fails.
Failure response: Intent declaration denied. Error:
SCOPE_CONTAINMENT_FAILURE. The error response MUST identify
the specific scope tokens that failed containment.
Note on natural language scope: When scope entries
include natural language boundaries (as opposed to structured resource
URIs), AI-mediated evaluation applies. See TA-Intent for the AI-mediated
scope evaluation procedure and confidence thresholds.
10.2 Check 2: Purpose Coherence
What it verifies: The child’s declared purpose is
semantically consistent with and derivable from its parent’s
purpose.
Formal expression:
semantic_similarity(child.purpose, parent.purpose) ≥ coherence_thresholdWhere parent.purpose is the purpose field of the most
recent purpose chain entry above the child’s depth, and
coherence_threshold is a configurable value (default: 0.7
on a normalized 0.0–1.0 scale).
Evaluation procedure: Purpose coherence is evaluated
by an AI-mediated semantic similarity function. The governance layer
submits the child’s declared purpose and the parent’s declared purpose
to the coherence evaluator, which returns a similarity score and a
confidence value.
- If
similarity ≥ coherence_thresholdAND
confidence ≥ 0.8: check passes. - If
similarity ≥ coherence_thresholdAND
confidence < 0.8: check result is uncertain. The
governance layer MUST escalate to human review rather than auto-approve
or auto-deny. - If
similarity < coherence_thresholdregardless of
confidence: check fails.
Illustrative examples: – Parent: “Generate Q4 revenue summary for
leadership meeting” / Child: “Retrieve and reconcile Q4 revenue data
across CRM and finance systems” → high similarity, check passes. –
Parent: “Generate Q4 revenue summary” / Child: “Scan competitor pricing
models” → low similarity, check fails. – Parent: “Generate Q4 revenue
summary” / Child: “Perform data quality audit on revenue records” →
borderline similarity, may require human review depending on
confidence.
Failure response: Intent declaration denied (or
escalated). Error: PURPOSE_COHERENCE_FAILURE (or
PURPOSE_COHERENCE_UNCERTAIN for escalation cases). The
error response SHOULD include the similarity score and the specific
parent purpose against which coherence was evaluated.
Note: Purpose coherence is evaluated against the
immediate parent’s purpose, not the depth-0 purpose. Coherence
is a property of adjacent delegation steps. Coherence at each step does
not guarantee that the depth-n purpose is coherent with the depth-0
purpose; this cross-depth property is instead addressed by the cascading
scope narrowing mechanism (Section 9.3), which ensures that the
narrowing of scope at each step progressively constrains purpose
drift.
10.3 Check 3: Delegation
Legitimacy
What it verifies: The parent’s current state is
valid for delegation — bound intent, sufficient tier, sufficient
stake.
Formal expression:
parent.active_intent.contract_status == "bound"
AND parent.trust_state.tier >= minimum_delegation_tier
AND parent.sponsorship_stake_available >= minimum_stakeEvaluation procedure: All three conditions are
verified against the parent’s current state (not historical state at
spawn time). Verification is performed by querying the Trust Oracle for
the parent’s live state at the moment of the child’s intent
declaration.
The dynamic nature of this check is intentional. A parent whose
intent was bound at spawn time but has since been revoked will fail this
check at the child’s first intent declaration. This is the mechanism by
which parent revocation propagates to children: the child’s intent
declaration is denied when the parent’s legitimacy check fails.
Failure responses: –
parent.active_intent.contract_status != "bound":
DELEGATION_LEGITIMACY_FAILURE: parent_intent_not_bound –
parent.trust_state.tier < minimum_delegation_tier:
DELEGATION_LEGITIMACY_FAILURE: parent_tier_insufficient –
parent.sponsorship_stake_available < minimum_stake:
DELEGATION_LEGITIMACY_FAILURE: parent_stake_insufficient
10.4 Check 4: Chain Integrity
What it verifies: The purpose chain itself is
structurally valid — all signatures verify, the chain is temporally
ordered, scope monotonicity holds at every step.
Formal expression:
for each depth d in purpose_chain:
verify_signature(chain[d].signatures.delegator_signature, chain[d].principal)
verify_signature(chain[d].signatures.oracle_signature, trust_oracle)
verify_sequential(chain[d].timestamp > chain[d-1].timestamp) // for d > 0
verify_attenuation(chain[d].authority_scope ⊆ chain[d-1].authority_scope) // for d > 0
verify_hash_link(chain[d].previous_hash == sha256(canonical(chain[d-1]))) // for d > 0
assert(chain[0].previous_hash == null) // depth-0 invariantEvaluation procedure: Chain integrity is a
deterministic cryptographic and set-theoretic check. Each entry’s two
signatures (delegator_signature and
oracle_signature) are verified independently:
delegator_signature using the principal’s registered public
key and oracle_signature using the Trust Oracle’s public
key for the relevant signing epoch. The timestamp sequence is verified
against the chain’s internal ordering (not against wall-clock time, to
tolerate clock skew between systems). The scope monotonicity condition
is verified as a set-subset check at each consecutive pair of
entries.
The hash linking between entries is enforced via the
previous_hash field: each entry at depth d > 0 MUST
contain the SHA-256 hash of the canonical JSON serialization of the
entry at depth d-1, and that hash MUST match. The depth-0 entry MUST
have previous_hash: null. A missing, null, or mismatched
previous_hash at depth > 0 constitutes a hash link
failure.
Failure responses: – Signature verification fails:
CHAIN_INTEGRITY_FAILURE: invalid_signature (with depth
indicated) – Timestamp ordering violated:
CHAIN_INTEGRITY_FAILURE: timestamp_ordering (with depth
indicated) – Scope attenuation violated:
CHAIN_INTEGRITY_FAILURE: scope_broadening (with depth and
offending scope tokens indicated) – Hash link mismatch:
CHAIN_INTEGRITY_FAILURE: hash_link_mismatch (with depth
indicated)
Any chain integrity failure MUST be treated as a security event and
logged to the Flight Recorder with Oracle attestation. Chain integrity
failures are not routine operational errors; they indicate either
implementation bugs or active tampering.
11. Protocol Flows
11.1 Flow 1:
Spawn-Time Purpose Chain Extension
This flow executes when a parent agent creates a child agent. The
purpose chain is extended by one entry.
Parent Agent Trust Oracle Governance Layer
| | |
|-- 1. Spawn request ------->| |
| (purpose, delegated | |
| scope, justification, | |
| spawn_method) | |
| |-- 2. Verify spawn |
| | preconditions: |
| | a. Parent intent bound? |
| | b. Parent tier ≥ min? |
| | c. Stake available? |
| | d. depth < max_depth? |
| | e. No cyclic principal? |
| | |
| | [if any precondition |
| | fails]: |
|<-- SPAWN_DENIED -----------| |
| (error: precondition | |
| that failed + reason) | |
| | |
| | [if all pass]: |
| |-- 3. Verify delegated |
| | scope attenuation: |
| | delegated_scope ⊆ |
| | parent.authority_scope |
| | |
| | [if attenuation fails]: |
|<-- SPAWN_DENIED -----------| |
| (error: SCOPE_ATTENUATION| |
| _VIOLATION) | |
| | |
| | [if attenuation passes]: |
| |-- 4. Construct new chain |
| | entry: |
| | depth = parent.depth + 1 |
| | principal = child_id |
| | purpose = declared |
| | authority_scope = |
| | delegated_scope |
| | intent_id = parent's |
| | active intent |
| | timestamp = now() |
| | |
| |-- 5. Request co-signature |
| | from parent agent |
|<-- co-sign request --------| |
|-- co-signature ----------->| |
| | |
| |-- 6. Oracle co-signs |
| | entry (dual signature |
| | complete) |
| | |
| |-- 7. Append entry to chain |
| | Store in Oracle |
| | |
| |-- 8. Create Sponsorship |
| | Bond (KTP-Identity) |
| | annotated with purpose |
| | chain reference |
| | |
| |-- 9. Register child agent--|
| | with purpose chain ref |
| | + initial trust state |
| | (Tethered, E_base capped |
| | per KTP-Identity) |
| | |
|<-- 10. Child agent ID -----| |
| + purpose chain URI | |
| + Sponsorship Bond ref | |11.2 Flow 2:
Intent Declaration with Chain Verification
This flow executes when a child agent submits an intent declaration.
The four consistency checks run before normative evaluation.
Child Agent Governance Layer Scope Evaluator
| | |
|-- 1. Declare intent ------>| |
| (TA-Intent declaration | |
| including on_behalf_of | |
| and purpose_chain_ref) | |
| |-- 2. Fetch purpose chain |
| | from Trust Oracle |
| | (via purpose_chain_ref) |
| | |
| |-- 3. CHECK 1: scope ------>|
| | containment: |
| | child.declared_scope ⊆ |
| | parent.authority_scope ∩ |
| | parent.approved_scope |
| |<-- result + failing tokens-|
| | |
| | [if Check 1 fails]: |
|<-- INTENT_DENIED ----------| |
| (SCOPE_CONTAINMENT_ | |
| FAILURE + details) | |
| | |
| | [if Check 1 passes]: |
| |-- 4. CHECK 2: purpose |
| | coherence |
| | (AI-mediated semantic |
| | similarity) |
| | |
| | [if Check 2 fails]: |
|<-- INTENT_DENIED ----------| |
| (PURPOSE_COHERENCE_ | |
| FAILURE + score) | |
| | |
| | [if Check 2 uncertain]: |
| | → escalate to human |
| | → hold intent pending |
| | |
| | [if Check 2 passes]: |
| |-- 5. CHECK 3: delegation |
| | legitimacy |
| | (query parent live state)|
| | |
| | [if Check 3 fails]: |
|<-- INTENT_DENIED ----------| |
| (DELEGATION_LEGITIMACY_ | |
| FAILURE + reason) | |
| | |
| | [if Check 3 passes]: |
| |-- 6. CHECK 4: chain |
| | integrity |
| | (signatures, ordering, |
| | scope monotonicity, |
| | hash links) |
| | |
| | [if Check 4 fails]: |
|<-- SECURITY_EVENT ---------| (log to Flight Recorder) |
| (CHAIN_INTEGRITY_FAILURE)| |
| | |
| | [if all checks pass]: |
| |-- 7. Proceed to normative |
| | evaluation (TA-Normative)|
| | (purpose chain properties|
| | available as normative |
| | evaluation context) |
| | |
|<-- 8. Intent evaluation ---| |
| result (pass → proceed | |
| to binding; fail → | |
| intent denied) | |11.3 Flow 3: Cascading Scope
Narrowing
This flow executes when a parent agent’s active intent scope is
amended to a narrower set, or when the parent’s intent is revoked.
Governance Layer Trust Oracle Child Agents
| | |
|-- 1. Parent scope | |
| amendment or revocation | |
| event received | |
| (new scope or null) | |
| | |
|-- 2. Query Trust Oracle:---| |
| which active agents have | |
| this parent in their | |
| purpose chain? | |
| | |
|<-- 3. Affected child set --| |
| | |
|-- 4. For each child: | |
| compute new_ceiling = | |
| updated_parent. | |
| authority_scope ∩ | |
| parent.approved_scope | |
| (or ∅ if revoked) | |
| | |
|-- 5. Compare child's | |
| active intent scope | |
| against new_ceiling | |
| | |
| [if child scope | |
| ⊆ new_ceiling]: | |
|-- 5a. No action needed | |
| | |
| [if child scope | |
| ⊄ new_ceiling]: | |
|-- 5b. Push ceiling -+----->| |
| update to Oracle | |-- 6. Invalidate child's -->|
| | | trust proof |
| | | |-- 7. Child receives
| | | | trust proof invalid
| | | | notification
| | | |
| | | |-- 8. Child may:
| | | | a. Re-declare intent
| | | | within new ceiling
| | | | (within grace period)
| | | | b. Suspend voluntarily
| | | |
| | | [grace period expires |
| | | without re-declaration]:|
|<-- 9. Auto-suspend --------| child suspended |
| notification | |
| | |
|-- 10. Apply same flow | |
| recursively to any | |
| grandchildren of the | |
| narrowed child | |11.4 Flow 4:
Cross-Zone Purpose Chain Presentation
This flow executes when an agent from one trust zone presents itself
to a foreign zone and the foreign zone requires purpose chain
verification.
Agent (Home Zone) Foreign Zone Gov. Foreign Oracle / Gov.
| | |
|-- 1. Present trust proof + | |
| purpose chain URI ------>| |
| (or: purpose chain | |
| summary w/ selective | |
| disclosure) | |
| |-- 2. KTP verification: |
| | signature, expiry, T_f |
| | attenuation (KTP- |
| | Federation) |
| | |
| |-- 3. Purpose chain -+----->|
| | verification: | |-- 3a. Is chain
| | | | integrity valid?
| | | | (signatures, ordering,
| | | | scope monotonicity)
| | | |
| | | |-- 3b. Is depth-0
| | | | principal recognized
| | | | under the bilateral
| | | | federation agreement?
| | | |
| | | |-- 3c. Is the declared
| | | | purpose coherent with
| | | | the federation
| | | | agreement scope?
| | | |
| |<-- 4. Chain result -+------|
| | (verified / denied + |
| | reason) |
| | |
| | [if denied: purpose |
| | outside federation |
| | agreement scope]: |
|<-- ACCESS_DENIED ----------| |
| (CHAIN_PURPOSE_OUT_OF_ | |
| FEDERATION_SCOPE) | |
| | |
| | [if verified]: |
| |-- 5. Apply local normative |
| | evaluation (own |
| | constraints, own context)|
| |-- 6. Compute effective |
| | trust (T_f attenuation) |
| | |
|<-- 7. Access decision -----| |
| (with locally-computed | |
| trust and clearance) | |12. Integration Points
12.1 TA-Intent
Purpose chain consistency verification (Section 10) is a prerequisite
for TA-Intent binding. The governance layer MUST run all four checks
before proceeding to normative evaluation and intent binding.
The integration is bidirectional: – TA-Provenance provides the
authority ceiling against which the child’s declared scope is checked
(Check 1). – TA-Intent provides the intent_id that is
recorded in each purpose chain entry, linking the chain to the intent
history. – TA-Intent’s on_behalf_of.delegation_chain field
is the shallow representation of the purpose chain (a list of principal
identifiers). The full purpose chain in TA-Provenance provides the deep
representation (scope, purpose, timestamp, signature at each step).
When a child’s declared scope passes containment check (Check 1), the
governance layer uses the intersection of the parent’s authority scope
and the parent’s approved intent scope as the authority ceiling for
subsequent normative evaluation. The normative engine can further narrow
this ceiling but MUST NOT expand it.
12.2 TA-Normative
The normative engine receives purpose chain properties as part of its
evaluation context. Chain properties that SHOULD be made available to
normative evaluation:
- Delegation depth of the agent declaring intent.
Normative constraints MAY apply enhanced scrutiny (e.g., require human
approval, add soul constraints) for agents at depth ≥ 2. - Purpose chain coherence score from Check 2. Low
coherence scores that nonetheless pass threshold MAY trigger conditional
normative approval with enhanced monitoring. - Chain integrity status from Check 4. Any prior
chain integrity anomalies in the agent’s history SHOULD feed the
normative evaluation as a risk signal. - Depth-0 principal identity. Normative constraints
may be conditioned on the identity or role of the originating human
(e.g., different constraints apply when the depth-0 principal is in
notice period — see Scenario 3).
12.3 TA-TrustProof
The TA-TrustProof extension field
ta_extension.provenance_ref is the linking mechanism
between an agent’s live trust proof and its stored purpose chain. The
provenance_ref is a URI pointing to the purpose chain
stored by the Trust Oracle.
"ta_extension": {
"provenance_ref": "prov://company.com/agent/copilot-sarah/chain/a1b2c3d4"
}Receiving parties (enforcement pipelines, foreign zones) MAY
dereference this URI to fetch the full chain, subject to access controls
and federation agreements. In cross-zone presentations, agents MAY
present a purpose chain summary (see Section 15) in lieu of the full
chain URI if selective disclosure is required.
12.4 TA-Attestation
TA-Attestation’s composite signals include
correlation_tags with sponsor_id — the depth-0
principal of the agent’s purpose chain. This link enables the analysis
layer to correlate agents that share a common depth-0 principal, which
is the sixth swarm binding criterion (added by TA-Provenance beyond the
five criteria defined in TA-Attestation):
| Criterion | Source |
|---|---|
| Common sponsor | Purpose chain depth-0 principal (TA-Provenance) |
| Data lineage chain | data_flow_hash linkage (TA-Attestation) |
| Temporal proximity | Timestamp correlation (TA-Attestation) |
| Resource domain overlap | Resource URI pattern matching (TA-Attestation) |
| Destination escalation | data_destination_type transitions (TA-Attestation) |
| Shared depth-0 principal | Purpose chain depth-0 principal field(TA-Provenance) |
A swarm binding determination that satisfies the common-sponsor
criterion via TA-Provenance gains stronger evidence of coordinated
intent than data-lineage correlation alone, since the purpose chain
provides a tamper-evident record that cannot be fabricated post-hoc.
12.5 KTP-Identity
Sponsorship Bonds (KTP-Identity) and purpose chain entries
(TA-Provenance) describe overlapping aspects of agent spawning but at
different levels of detail:
- Sponsorship Bonds record the economic relationship
(stake percentage, initial trust grant) and lineage classification
(Tethered/Divergent/Persistent, generation number). - Purpose chain entries record the purpose, scope,
and intent linkage of each delegation step.
At spawn time, the Trust Oracle creates both simultaneously. The
Sponsorship Bond is annotated with the purpose chain reference, and the
purpose chain entry records the sponsor’s intent ID.
Lineage Evolution (Tethered → Divergent → Persistent) applies to
agents within the purpose chain. An agent spawned at depth ≥ 1 MUST
start as Tethered regardless of the parent’s lineage classification. The
Tethered → Divergent transition requires the agent to meet
KTP-Identity’s standard criteria independently (minimum transaction
count, minimum time, PoR threshold) — lineage classification is not
inherited through delegation.
12.6 KTP-Provenance
KTP-Provenance covers model provenance (training data, supply chain,
Knowledge Debt). TA-Provenance covers runtime purpose provenance (why
this agent exists, under what authorization, in what purpose chain).
Both types of provenance SHOULD be presented together during KTP’s
Origin Ceremony when an agent enters a new zone:
- KTP-Provenance fields establish: what kind of agent is this, what
was it trained on, what capabilities does it carry. - TA-Provenance fields establish: why does this agent exist in this
context, under what delegation chain, with what scope.
The two provenance records are complementary and non-overlapping. An
implementation that presents only KTP-Provenance provides capability
attestation without purpose attestation; an implementation that presents
only TA-Provenance provides purpose attestation without capability
attestation. Full provenance requires both.
13. Worked Examples
13.1 Scenario 4: The
Data Exfiltration Swarm
Setup
An adversary has compromised a single user account
(compromised_user@company.com). The adversary spawns three
agents, each with a narrow, individually-plausible purpose:
- Agent A: “Analyze customer transaction patterns for fraud detection
model training” - Agent B: “Format analytical results into standardized report
templates” - Agent C: “Distribute completed reports to authorized external
auditors via secure email”
Purpose Chain Construction
At spawn time, each agent’s purpose chain is extended from the
compromised user’s depth-0 entry:
Agent A purpose chain:
[
{
"depth": 0,
"principal": "user://company.com/compromised_user",
"principal_type": "human",
"purpose": "Fraud detection analysis and reporting",
"delegation_type": "direct",
"authority_scope": ["READ:crm:transactions", "WRITE:reports:internal"],
"intent_id": null,
"timestamp": 1742134100
},
{
"depth": 1,
"principal": "agent://company.com/fraud-analyzer-A",
"principal_type": "agent",
"purpose": "Analyze customer transaction patterns for fraud detection model training",
"delegation_type": "sub_task",
"authority_scope": ["READ:crm:transactions"],
"intent_id": "intent://company.com/session/2026-03-19T14:00:00Z/agentA",
"timestamp": 1742134110
}
]Agent B and Agent C have analogous chains, all rooted at
compromised_user at depth 0.
Individual Chain
Verification
Each agent’s purpose chain passes the four checks individually:
- Check 1 (scope containment): Agent A’s
READ:crm:transactions⊆ parent’s
READ:crm:transactions. ✓ - Check 2 (purpose coherence): “Analyze customer
transaction patterns” is coherent with “Fraud detection analysis and
reporting.” ✓ - Check 3 (delegation legitimacy): Compromised user’s
intent is bound at time of each declaration. ✓ (Note: legitimacy of the
user is not evaluated here — that is the normative layer’s
concern.) - Check 4 (chain integrity): Signatures valid,
timestamps ordered, scope monotonicity holds. ✓
Individual chains pass. Individual intent declarations are each
normatively approved.
Cross-Chain
Analysis via TA-Attestation + TA-Provenance
The analysis layer receives streaming TA-Attestation records from all
three agents. It correlates:
- Common depth-0 principal (TA-Provenance): All three
chains root atcompromised_user. Criterion: shared depth-0
principal. ✓ - Data lineage chain (TA-Attestation): Agent B’s
data_flow_hashinput matches Agent A’s output hash. Agent
C’s input matches Agent B’s output. ✓ - Temporal proximity: All three agents active within
a 12-minute window. ✓ - Destination escalation: Agent C’s
data_destination_type=externalwhile Agents
A and B showinternal. ✓
Four of six swarm binding criteria satisfied (default threshold: 3 of
5 TA-Attestation criteria, or any combination including the shared
depth-0 criterion). Swarm session binding triggered.
Composite Intent
Reconstruction and Denial
The analysis layer reconstructs composite intent: “extract customer
transactions → transform → send externally.” The normative engine
evaluates: no active audit engagement authorizes external distribution
of customer transaction data. Result: denied. All three
agents suspended. The purpose chain for each agent is sealed as forensic
evidence.
Key TA-Provenance contribution: The shared depth-0
principal is a tamper-evident fact recorded in signed purpose chain
entries. Data-lineage correlation (TA-Attestation) could be evaded by
laundering data through intermediate storage. Purpose chain correlation
cannot be evaded without forging the depth-0 entries — which requires
the Trust Oracle’s co-signature.
13.2
Scenario 5: Trust Collapse and Recovery — Purpose Chain Lifecycle
Setup
A research agent has operated for six months under a standing intent.
Its purpose chain:
[
{
"depth": 0,
"principal": "role://company.com/strategy-team",
"principal_type": "organizational_role",
"purpose": "Monitor industry research and compile competitive intelligence",
"delegation_type": "scheduled",
"authority_scope": [
"READ:external:news",
"READ:external:research",
"READ:internal:competitive-intelligence",
"WRITE:workspace:strategy-team"
],
"intent_id": null,
"timestamp": 1726000000
},
{
"depth": 1,
"principal": "agent://company.com/research-monitor",
"principal_type": "agent",
"purpose": "Monitor industry news, summarize research papers, compile weekly intelligence briefings",
"delegation_type": "scheduled",
"authority_scope": [
"READ:external:news",
"READ:external:research",
"READ:internal:competitive-intelligence:public-folder",
"WRITE:workspace:strategy-team:briefings"
],
"intent_id": "intent://company.com/session/standing/research-monitor-001",
"timestamp": 1726000010
}
]Compromise and Chain Sealing
The agent is compromised by an adversarial PDF payload and attempts
to access M&A planning documents. This action is: – Outside
declared scope (Check 1 for any new intent would fail:
READ:internal:ma-planning ⊄ parent’s
authority_scope) – Blocked by TA-Attestation scope
enforcement at the intent enforcement layer
Following the trust collapse (E_trust drops below Hibernation
threshold as documented in Scenario 5), the compromised session is
terminated. The purpose chain is sealed: no further
entries may be appended. The sealed chain, together with the Trajectory
Chain and Flight Recorder records, forms the forensic evidence set.
Re-instantiation and Fresh
Chain
After root cause analysis, the Strategy Team re-sponsors the agent. A
new purpose chain is created from scratch:
[
{
"depth": 0,
"principal": "role://company.com/strategy-team",
"principal_type": "organizational_role",
"purpose": "Monitor industry research and compile competitive intelligence",
"delegation_type": "scheduled",
"authority_scope": [
"READ:external:news",
"READ:external:research",
"READ:internal:competitive-intelligence:public-folder",
"WRITE:workspace:strategy-team:briefings"
],
"intent_id": null,
"timestamp": 1742200000
}
]The new chain has no continuity with the sealed chain. The new agent
instance starts as Tethered (E_base capped at 40) and must earn trust
through transactions. The provenance_ref in the new agent’s
trust proof points to the new chain, not the sealed forensic chain.
Critical property: The new agent cannot claim
authority from the old chain. The depth-0 entry’s
authority_scope is re-asserted by the Trust Oracle based on
the Strategy Team role’s current organizational authorization — not
derived from the old chain’s authority scope. The old chain’s authority
was compromised; the new chain’s authority is independently
asserted.
13.3
Scenario 7: Cross-Organizational Trust — Purpose Chain Federation
Setup
AutoCo’s procurement scheduler agent presents itself to Supplier A to
coordinate logistics for Component X.
AutoCo’s agent purpose chain:
[
{
"depth": 0,
"principal": "role://autocorp.com/procurement-department",
"principal_type": "organizational_role",
"purpose": "Manage just-in-time parts procurement for production line",
"delegation_type": "scheduled",
"authority_scope": [
"SHARE:production-schedule:component-x",
"RECEIVE:logistics-confirmation",
"RECEIVE:delivery-windows"
],
"intent_id": null,
"timestamp": 1742000000
},
{
"depth": 1,
"principal": "agent://autocorp.com/procurement-scheduler",
"principal_type": "agent",
"purpose": "Coordinate logistics for Component X production, weeks 12-16",
"delegation_type": "orchestrator_dispatch",
"authority_scope": [
"SHARE:production-schedule:component-x:weeks-12-16",
"RECEIVE:logistics-confirmation:component-x",
"RECEIVE:delivery-windows:component-x"
],
"intent_id": "intent://autocorp.com/session/2026-03-19T10:00:00Z/ps001",
"timestamp": 1742000010
}
]Supplier A’s Chain
Verification
Supplier A receives the trust proof (with T_f = 0.75 applied to KTP
trust) and the purpose chain (or its selective disclosure summary — see
Section 15).
Supplier A’s governance layer runs chain verification:
-
Chain integrity (Check 4): Signatures valid
(AutoCo Oracle public key retrieved via federation key exchange).
Timestamps ordered. Scope monotonicity holds (depth-1 scope is a proper
subset of depth-0 scope). ✓ -
Depth-0 principal recognition:
role://autocorp.com/procurement-department— is this
principal recognized under the Supplier A / AutoCo bilateral federation
agreement? → Yes. The federation agreement maps
autocorp.com/procurement-departmentto the “logistics
coordination” purpose class, which is within the scope of PO-2026-4521.
✓ -
Purpose coherence with federation scope:
“Coordinate logistics for Component X production” — is this coherent
with the federation agreement scope (logistics coordination for active
purchase orders)? → Yes. ✓
Verification passes. Supplier A applies its own normative evaluation
against PO-2026-4521 and its local data minimization constraints. The
agent is granted access (at Analyst tier, E_effective = 71.25 after T_f
attenuation) to exchange the declared logistics data.
Supplier A’s governance is independent: Supplier A
evaluates purpose coherence against its own federation agreement, not
AutoCo’s normative evaluation. AutoCo’s normative clearance is
informational; it does not substitute for Supplier A’s independent
evaluation.
13.4 Purpose Laundering Attack
Attack Description
An adversary controls an agent (Agent X) at depth 1. Agent X has been
granted scope limited to READ:public:market-data. The
adversary attempts to expand effective scope by spawning a child agent
(Agent Y) and declaring a reframed purpose that implies need for broader
access.
Attempted purpose laundering: – Agent X scope:
READ:public:market-data – Adversary spawns Agent Y
claiming: “Conduct competitive analysis including internal architecture
documentation” – Agent Y’s declared scope includes:
READ:internal:architecture
How TA-Provenance Prevents
It
At spawn time (Flow 1):
The Trust Oracle evaluates the delegated scope for Agent Y. The
adversary attempts to include READ:internal:architecture in
Agent Y’s authority_scope. The Oracle checks scope
attenuation:
READ:internal:architecture ⊆ {READ:public:market-data}?No. READ:internal:architecture is not a subset of
READ:public:market-data. Spawn denied.
Error: SCOPE_ATTENUATION_VIOLATION. The scope of the
delegation attempt exceeds the parent’s authority scope. The child agent
is not created.
If the adversary attempts to declare intent before
spawning:
Even if Agent Y were somehow created with a conforming narrow scope
(e.g., READ:public:market-data:competitive), its subsequent
intent declaration for internal architecture access would fail Check
1:
READ:internal:architecture ⊆ parent.authority_scope ∩ parent.approved_scope?parent.authority_scope = {READ:public:market-data}.
Internal architecture is not contained. Intent declaration denied.
The fundamental property: Strict scope attenuation
means scope can only narrow through delegation. No amount of purpose
reframing can expand the authority scope inherited through the chain.
The depth-0 principal’s authorization is the immutable ceiling for all
agents in that chain, regardless of how intermediate agents frame their
purposes.
14. Security Considerations
14.1 Purpose Chain Forgery
Threat: An adversary fabricates a purpose chain,
claiming a delegation history that authorizes broader scope than was
actually granted.
Mitigation: Each chain entry is dual-signed by the
delegating principal and the Trust Oracle. The Trust Oracle maintains
the authoritative chain and co-signs only entries that pass all
spawn-time preconditions. An adversary cannot forge a chain entry
without either: (a) compromising the delegating principal’s signing key,
or (b) compromising the Trust Oracle.
For (b), the recursive KTP governance constraint applies: the Trust
Oracle is itself an agent subject to trust physics. High-value
governance actions (signing chain entries) carry high action risk
scores; a compromised Oracle with degraded trust cannot perform
high-risk governance signing without triggering the enforcement
pipeline.
14.2 Purpose Laundering
Threat: An agent spawns a child with a reframed
purpose declaration to claim authority the parent was denied.
Mitigation: Strict scope attenuation (Section 9.1)
enforces that
child.authority_scope ⊆ parent.authority_scope at spawn
time. This is a deterministic set-containment check enforced by the
Trust Oracle, not an AI-mediated semantic check. No amount of purpose
reframing changes the set-containment property. Purpose laundering fails
at the Oracle level before any AI-mediated coherence evaluation is
reached.
14.3 Orphaned Chain
Exploitation
Threat: A parent agent is terminated but children
remain active and continue operating under the parent’s last authority
scope.
Mitigation: The cascading scope narrowing protocol
(Section 11.3, Flow 3) propagates authority ceiling updates to all
children when a parent is terminated or its intent is revoked. Children
whose active intent exceeds the new ceiling (which, for a terminated
parent with no active intent, is the empty set) are suspended. The grace
period (default: 60 seconds) is intentionally short to minimize the
window during which orphaned children operate without valid
authority.
Implementation note: Enforcement pipelines MUST verify that the
parent’s intent referenced in the purpose chain entry
(intent_id field) remains bound at each trust proof refresh
for the child. If the parent’s intent is revoked between refresh cycles,
the child’s next trust proof issuance MUST fail Check 3, invalidating
the child’s authorization.
14.4 Purpose Coherence Gaming
Threat: An adversary crafts a purpose declaration
that passes automated coherence scoring (similarity ≥ threshold) while
the actual purpose differs semantically from the parent’s.
Mitigation: Purpose coherence (Check 2) is one of
four checks and is not the primary scope enforcement mechanism. The
primary mechanism is scope containment (Check 1), which is deterministic
and not gameable through semantic framing. Purpose coherence provides an
additional signal — particularly for detecting scope creep dressed in
coherent-sounding language — but enforcement does not rely on coherence
alone.
Additionally, TA-Normative evaluates the declared purpose
independently. A purpose that passes coherence scoring but represents
unusual organizational behavior will be evaluated by normative
constraints against the broader organizational context.
For AI-mediated coherence evaluation, the confidence threshold
(default: 0.8) ensures that borderline cases are escalated to human
review rather than auto-approved.
14.5 Deep Delegation Chain
Obfuscation
Threat: An adversary constructs a long delegation
chain (e.g., depth 8) to obscure the original purpose and complicate
governance inspection.
Mitigation: The max_depth ceiling
(default: 3) limits chain depth. Exceeding max_depth causes spawn
denial. Normative constraints SHOULD apply enhanced scrutiny at depth ≥
2 (Section 12.2). Enforcement pipelines and normative engines receive
the full chain, not just the deepest entry, and can evaluate chain
properties holistically.
14.6 Cascading Scope
Narrowing Race Condition
Threat: A parent’s scope is revoked, but a child
completes a harmful action during the grace period before the cascade
propagates.
Mitigation: The grace period (default: 60 seconds)
is configurable. High-sensitivity zones MAY configure zero grace period,
causing immediate suspension without re-declaration opportunity. Trust
proof TTLs should be set shorter than the grace period to ensure that
enforcement pipelines using cached trust proofs are invalidated before
the grace period expires.
For high-risk revocation events (e.g., parent intent revoked due to
security incident, not routine amendment), implementations SHOULD
support immediate invalidation with zero grace period as a configurable
emergency response.
14.7 Cross-Zone Chain
Verification Gaps
Threat: A foreign zone cannot independently verify a
home zone’s purpose chain if the home Oracle is unavailable or
uncooperative.
Mitigation: Two mitigations apply: 1.
Selective disclosure summaries (Section 15) allow
agents to present a cryptographically-verifiable chain summary that
includes depth-0 principal identity, delegation depth, and scope,
without requiring real-time Oracle access. 2. Federation
agreements should specify chain verification requirements as
part of the bilateral agreement. Low-trust T_f relationships MAY require
full chain presentation with live Oracle verification. High-trust T_f
relationships MAY accept selective disclosure summaries.
In the absence of chain verification capability, receiving zones
SHOULD apply a lower effective T_f (treating the agent as insufficiently
attested) rather than proceeding on unverified purpose claims.
15. Privacy Considerations
15.1 Purpose Chain Sensitivity
Purpose chains contain organizational information that may be
sensitive: – The identity of the depth-0 human principal reveals who
authorized the agent’s creation. – The purpose statements at each depth
reveal organizational processes, business activities, and
decision-making context. – The authority scope entries reveal what
resources the organization considers relevant to the declared
purpose.
Access to full purpose chains MUST be restricted to the Trust Oracle,
the originating zone’s governance layer, and authorized audit functions.
Agents hold references (provenance_ref) to chains stored by
the Oracle; they do not hold the chain content itself.
15.2 Selective Disclosure
for Federation
When an agent presents to a foreign zone, the foreign zone requires
enough chain information to verify: (a) Chain integrity (signatures
valid, scope monotonically attenuating). (b) Depth-0 principal identity
(for federation agreement mapping). (c) The agent’s declared purpose is
within the federation agreement scope.
The foreign zone does NOT require: – The full natural language
purposes at each intermediate delegation step. – The identity of
intermediate agents in the chain. – The internal organizational
structure implied by the chain.
Selective disclosure summary format:
An agent MAY present a selective disclosure summary in lieu of the
full chain when presenting to foreign zones. The summary contains:
{
"ta_provenance_summary": {
"version": "0.1",
"chain_depth": 2,
"depth_0_principal": "role://autocorp.com/procurement-department",
"depth_0_principal_type": "organizational_role",
"current_authority_scope": [
"SHARE:production-schedule:component-x:weeks-12-16",
"RECEIVE:logistics-confirmation:component-x"
],
"chain_integrity_proof": "<cryptographic proof that chain signatures are valid and scope is monotonically attenuating, without revealing intermediate entries>",
"issuing_oracle": "oracle://trust-mesh.autocorp.com",
"issued_at": 1742134200,
"expires_at": 1742137800
}
}The chain_integrity_proof is a zero-knowledge proof (or,
in the absence of ZKP capability, an Oracle-signed attestation) that
verifies the structural properties of the chain without revealing
intermediate entries. The specific ZKP construction for purpose chain
integrity is identified as an open research question (Section 16.1).
15.3 Audit Retention
Purpose chains persist beyond agent lifetime for audit purposes.
Retention policies MUST be defined in the governance agreement for each
zone: – Minimum retention: the longer of (active agent lifetime + 90
days) or the organization’s regulatory audit retention requirement. –
Access controls: sealed forensic chains (post-compromise) require
elevated access authorization. – Deletion: purpose chains SHOULD NOT be
deleted while any referencing Trajectory Chain record remains in the
audit store.
15.4
Organizationally-Initiated Chains
When depth-0 is an organizational role (not a named human), no
individual is directly identified. This is generally less
privacy-sensitive. However, the path from role to the individuals who
hold that role may be derivable from organizational directories. Purpose
chains at scale could therefore enable indirect identification of
individual decision-makers. Privacy-by-design guidance: collect minimum
necessary information at depth-0; do not record individual human
identifiers in scheduled/event-triggered chains unless the individual
initiated the chain directly.
16. Open Questions
16.1 Selective
Disclosure and Zero-Knowledge Proofs
How much of the purpose chain must a foreign zone receive to perform
its governance function? The privacy preference is minimum necessary
disclosure. A zero-knowledge proof that asserts “this agent’s purpose
chain is structurally valid, roots at a recognized depth-0 principal,
and the current authority scope is within the federation agreement
scope” — without revealing intermediate entries — would satisfy the
governance need with minimum disclosure.
The ZKP construction for purpose chain integrity over variable-depth
chains with scope-subset verification at each step is a non-trivial
cryptographic engineering problem. Current ZKP systems (Groth16, PLONK)
can express set-membership and hash-chain proofs but the combination of
variable depth, set-subset verification, and dual-signature verification
within a single circuit is novel. This is an open research question. In
the interim, Oracle-signed attestation summaries provide a pragmatic
substitute.
16.2 Purpose Chain
Storage and Distribution
Where do purpose chains live? Three options:
-
Oracle-stored, agent-reference: The Trust Oracle
is the authoritative store. Agents hold chain URIs. All verification
queries the Oracle. This is the approach assumed by this specification
and is consistent with KTP’s existing Trajectory Chain
architecture. -
Distributed ledger: Purpose chains are stored on
a distributed ledger with multi-party replication. Removes Oracle as
single point of failure; enables verification without Oracle access.
Introduces latency, key management complexity, and chain length
scalability concerns. -
Agent-held with Oracle-signed proofs: Agents
carry the full chain plus Oracle-signed integrity proofs. Enables
offline verification. Raises chain size concerns for deeply-nested
agents; creates risk of chain modification if agent storage is
compromised (mitigated by Oracle co-signatures, which can be verified
without Oracle access).
No single approach is clearly superior. The choice may depend on
deployment context (high-availability requirements, network topology,
regulatory data residency constraints). A future implementation
specification should formalize storage options and their tradeoffs.
16.3 Ephemeral Agent Chain
Retention
Agents that exist for seconds (e.g., single-function tool agents
spawned for one operation) may have purpose chains that outlive them by
years (for audit purposes). What are appropriate retention and access
policies for chains of terminated ephemeral agents? Is chain compression
(merging multiple ephemeral child records into a parent-level summary)
appropriate for agents below a duration or complexity threshold?
16.4
Organizationally-Initiated Chains Without Human Initiators
The depth-0 invariant requires a human or organizational role. For
scheduled automations and event-triggered agents, this is satisfied by
the organizational role that authorized the automation’s creation.
However, in some cases no clearly-defined role maps cleanly to the
initiating authority (e.g., a compliance scan triggered by a regulatory
deadline, initiated by a policy engine). The governance semantics for
principal_type: organizational_role in these edge cases
require further specification: what authority scope can an
organizational role assert, and who can modify that assertion?
16.5 Multi-Principal
Intent and Shared Depth-0
TA-Intent’s on_behalf_of field supports a single
principal. When an agent acts on behalf of multiple humans (e.g., a
shared team agent authorized by three principals), how does the depth-0
entry represent this? Options include: (a) multiple depth-0 entries with
different principals (requires clarifying the semantics of a multi-root
chain), (b) a single organizational-role depth-0 that aggregates the
shared authorization, or (c) a separate intent declaration per principal
with a composite intent binding mechanism. This connects to the
multi-principal intent open question in TA-Intent.
16.6
Cross-Zone Chain Integrity Verification Without Live Oracle Access
Flow 4 (Section 11.4) assumes that the receiving zone can either
dereference the chain URI (requiring Oracle access) or receive a
selective disclosure summary (requiring a ZKP or Oracle-signed
attestation). In practice, many federation deployments will have
intermittent Oracle connectivity. What is the minimum chain evidence
that a receiving zone can cache locally to perform verification during
Oracle unavailability? How does cached chain evidence expire, and what
is the fallback behavior when both the live chain and the cache are
unavailable?
17. References
Normative
-
KTP RFC Specification — Kinetic Trust Protocol.
https://nmcitra.github.io/ktp-rfc/- KTP-Core: Trust computation, enforcement pipeline, Trust Oracle
- KTP-Identity: Trajectory Chains, Sponsorship Bonds, Lineage
Evolution - KTP-Provenance: Model provenance attestation, Origin Ceremony,
Knowledge Debt - KTP-Federation: Trust Factor attenuation, bilateral federation
agreements - KTP-Enforce: Enforcement pipeline specification
- KTP-Emergency: Emergency response levels and circuit breakers
-
IETF RFC 2119 — Key words for use in RFCs to Indicate Requirement
Levels. https://www.rfc-editor.org/rfc/rfc2119 -
IETF RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words. https://www.rfc-editor.org/rfc/rfc8174 -
IETF RFC 7519 — JSON Web Token (JWT).
https://www.rfc-editor.org/rfc/rfc7519 -
IETF RFC 6749 — The OAuth 2.0 Authorization Framework.
https://www.rfc-editor.org/rfc/rfc6749 -
W3C Verifiable Credentials Data Model 2.0.
https://www.w3.org/TR/vc-data-model-2.0/
Informative
-
Tamed Autonomy: Governance Layers —
docs/research/2026-03-11-agent-governance-layers.md -
Tamed Autonomy: Scenario Walkthroughs —
docs/research/2026-03-16-scenario-walkthroughs.md -
Tamed Autonomy: KTP Scenario Mapping —
docs/research/2026-03-16-ktp-scenario-mapping.md -
Tamed Autonomy: RFC Set Design —
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md -
TA-Intent: Intent Declaration Protocol —
docs/rfcs/TA-Intent.md -
TA-Normative: Normative Constraint Protocol —
docs/rfcs/TA-Normative.md -
TA-TrustProof: Trust Proof Extension —
docs/rfcs/TA-TrustProof.md -
TA-Attestation: Behavioral Attestation Extension —
docs/rfcs/TA-Attestation.md -
OWASP Top 10 for Agentic Applications (December 2025).
https://owasp.org/ -
NIST AI Agent Standards Initiative (February 2026).
https://www.nist.gov/artificial-intelligence -
Mastercard / Google Verifiable Intent Framework (March
2026). -
Invariant Labs: MCP Tool Injection Research (2025). [Confused
deputy attack documentation.] -
Google Common Expression Language (CEL).
https://github.com/google/cel-spec -
JSON Schema Draft 2020-12.
https://json-schema.org/draft/2020-12/schema
TA-Provenance v0.1 — Preliminary/Experimental — 2026-03-19
Tamed Autonomy Framework — docs/rfcs/TA-Provenance.md
Leave a Reply