# Tensflare Accountability Protocol (TAP) Technical Specification
**Version 1.0 — Draft**
**June 2026**
**Tensflare Ltd**
---
## Table of Contents
1. [Introduction](#1-introduction)
2. [Glossary](#2-glossary)
3. [Normative References](#3-normative-references)
4. [Standard Terms](#4-standard-terms)
5. [Versioning](#5-versioning)
6. [Mandates](#6-mandates)
7. [Action Records](#7-action-records)
8. [Delegation Chains](#8-delegation-chains)
9. [Unique Identifiers](#9-unique-identifiers)
10. [Binding to Content](#10-binding-to-content)
11. [Trust Model](#11-trust-model)
12. [Validation](#12-validation)
13. [Standard Assertions](#13-standard-assertions)
14. [Serialization](#14-serialization)
15. [Storage and Retrieval](#15-storage-and-retrieval)
16. [User Experience](#16-user-experience)
17. [Security Considerations](#17-security-considerations)
18. [Patent Policy](#18-patent-policy)
**Appendices**
- [Appendix A: Key Algorithms and Identifiers](#appendix-a-key-algorithms-and-identifiers)
- [Appendix B: Standard Action Types](#appendix-b-standard-action-types)
- [Appendix C: Standard Data Classes](#appendix-c-standard-data-classes)
- [Appendix D: Standard Regulatory Frameworks](#appendix-d-standard-regulatory-frameworks)
- [Appendix E: Full CDDL Schemas](#appendix-e-full-cddl-schemas)
- [Appendix F: JSON Schema Definitions](#appendix-f-json-schema-definitions)
- [Appendix G: Considerations for Deprecation](#appendix-g-considerations-for-deprecation)
---
## 1. Introduction
### 1.1 Overview
AI agents are executing consequential actions at scale — filing documents, executing contracts, making compliance decisions, and instructing other agents across organizational and jurisdictional boundaries. When something goes wrong, the question is not which alert fired in a SIEM. The question is: who authorized this action? Within what mandate was it taken? Did it comply with the regulations governing it — in every applicable jurisdiction? When this agent instructed another agent at a different organization, who is accountable for what followed? What evidence exists, in a form a court or regulator can use, to answer all of the above?
The Tensflare Accountability Protocol (TAP) addresses these questions by defining a standardized, cryptographically verifiable data model for agent authorization and action recording. TAP encodes what an agent is authorized to do (a *Mandate*), records what it actually did (an *Action Record*), and tracks how authority flows across agents and organizations (a *Delegation Chain*). Every document is signed, every record links to its predecessor, and every action carries the jurisdictional context in which it was evaluated.
TAP is an open protocol (Apache 2.0) designed to be implementation-agnostic. The reference implementation (`@tensflare/tap`) provides Zod schemas and TypeScript types, but the protocol can be implemented in any language using the CDDL and JSON Schema definitions in the appendices.
### 1.2 Scope
This specification describes the technical aspects of the TAP architecture: a model for encoding, storing, and verifying agent authorization and accountability information using cryptographic signatures and content chaining.
**In scope:**
- The TAP data model: Mandates, Action Records, Delegation Hops, and auxiliary structures
- The cryptographic signing and verification scheme
- The validation process and trust model
- Serialization formats (CBOR and JSON)
- Standard action types, data classes, and regulatory framework vocabularies
**Out of scope:**
- Transport protocols for transmitting TAP documents
- Key management infrastructure (provisioning, rotation, HSM integration)
- Policy decision engines for jurisdiction evaluation
- Identity provisioning and verification of human principals
- Specific UI/UX implementation guidance
### 1.3 Technical Overview
TAP defines four primary document types that together form an **Accountability Chain**:
```mermaid
graph TB
subgraph "Accountability Chain"
M1["Mandate A
Issued by Principal P
Authorizes Agent A"]
AR1["ActionRecord
agent A · action X
chain_position: 0"]
AR2["ActionRecord
agent A · action Y
chain_position: 1"]
DH["DelegationHop
agent A → agent B
scope reduction"]
M2["Mandate B
(child of A)
Authorizes Agent B"]
AR3["ActionRecord
agent B · action Z
chain_position: 0"]
end
M1 --> AR1
AR1 --> AR2
M1 --> DH
DH --> M2
M2 --> AR3
```
**Figure 1. An Accountability Chain showing mandates, action records, and delegation**
- **Mandate**: a signed document in which an Issuing Principal delegates authority to an Agent. Defines scope (permitted and forbidden actions), jurisdictional context, and validity window.
- **Action Record**: a signed document recording that an Agent performed a specific action. Links to the authorizing Mandate and forms a hash chain with preceding Action Records.
- **Delegation Hop**: a signed document recording that an Agent delegated authority to another Agent, creating a child Mandate with reduced scope.
- **Accountability Chain**: the complete set of Mandates, Action Records, and Delegation Hops that together provide a tamper-evident history of who authorized what and what was done.
**Signing and chaining.** Every TAP document is signed with the Ed25519 signature scheme. Action Records form a singly linked list via `prev_record_hash`: each record contains the SHA-256 hash of the preceding record. This makes the chain tamper-evident — modifying any record invalidates all downstream hashes.
**Trust model.** Trust is rooted in the public keys of Issuing Principals. A document is *well-formed* if it passes schema validation, *valid* if its signature verifies, and *trusted* if its signer traces to a recognized Trust Root via the delegation chain.
### 1.4 Design Goals
| Goal | Description |
|------|-------------|
| **Non-Repudiation** | Principals cannot deny issuing a Mandate; Agents cannot deny performing an Action Record |
| **Chain of Custody** | Every action links to its authorization and all prior actions via cryptographic hashes |
| **Jurisdictional Awareness** | Actions carry provenance for the legal frameworks in which they were evaluated |
| **Scope Confinement** | Delegation reduces scope monotonically; no escalation is possible |
| **Extensibility** | Custom assertions can be added without protocol-wide coordination |
| **Interoperability** | Different implementations produce and consume the same wire format |
| **Privacy** | Documents disclose only necessary information; optional fields for sensitive context |
| **Offline Verification** | Any party holding signed TAP documents can verify integrity without network access |
---
## 2. Glossary
### 2.1 Core Actors
**Actor**
A human, organization, or software system participating in the TAP ecosystem. Examples: a human principal, an AI agent runtime, a cloud service.
**Issuing Principal**
The actor that holds ultimate authority and issues a Mandate. Identified by entity, human ID, and role. The Issuing Principal's public key is the trust anchor for the delegation chain. Expressly defined as a human or organizational actor — not software.
**Agent**
A software actor that receives authority via a Mandate and performs actions. Each Agent deployment receives a unique Ed25519 keypair. The Agent is identified by `agent_id` and `agent_name`.
**Delegating Agent**
An Agent that creates a child Mandate, transferring a subset of its own authority to another Agent. The Delegating Agent signs the Delegation Hop.
**Validator**
An actor that consumes TAP documents and performs the validation process described in [Section 12](#12-validation). A Validator may be a Truss API server, an SDK client, or a third-party tool.
### 2.2 Documents
**Mandate**
A signed document conveying authority from an Issuing Principal to an Agent. Defines scope (permitted and forbidden actions), jurisdictional context, and temporal validity. The fundamental authorization object in TAP.
**Action Record**
A signed document recording a single action performed by an Agent under a specific Mandate. Includes input/output content hashes, chain position, and optional jurisdiction evaluation. The fundamental audit object in TAP.
**Delegation Hop**
A signed document recording the transfer of authority from a parent Mandate to a child Mandate, including scope reduction and boundary type.
**Accountability Chain**
The ordered set of Delegation Hops and Action Records that trace a specific action from an Issuing Principal through one or more Agents. The chain is tamper-evident via hash linking.
**Evidence Package**
An institutional export artifact (not part of the core protocol) that bundles the Accountability Chain with a human-readable summary for submission to courts, regulators, or counterparties. Defined in the Truss product but not in TAP itself.
### 2.3 Concepts
**Scope**
The set of permitted and forbidden actions, permitted data classes, and resource bounds that confine an Agent's authority. Defined in a Mandate.
**Scope Reduction**
A narrowing of scope that occurs during delegation. The child Mandate's scope must be a strict subset of the parent's. Scope expansion is not permitted at the protocol level.
**Boundary Crossing**
A delegation that spans organizational, jurisdictional, or vendor boundaries. Recorded in the Delegation Hop via `cross_boundary` and `boundary_type`.
**Jurisdiction Evaluation**
The result of assessing an action against applicable regulatory frameworks. Produces a status (`compliant`, `warning`, `violation`, `unknown`) and an optional set of flags with specific obligation references.
**Content Binding**
A cryptographic hash linking a TAP document to its associated content. Action Records use `input_hash` and `output_hash` to bind to the action's inputs and outputs. (Analogous to C2PA Hard Binding.)
**Trust Root**
A recognized public key of an Issuing Principal that terminates a delegation chain. Trust Roots are configured by Validators out of band.
---
## 3. Normative References
### 3.1 Core Formats
| Reference | Description |
|-----------|-------------|
| RFC 8949 | CBOR — Concise Binary Object Representation |
| RFC 8610 | CDDL — Concise Data Definition Language |
| RFC 8259 | JSON — JavaScript Object Notation |
| RFC 8785 | Canonical JSON (JCS) — for deterministic signing |
### 3.2 Cryptography
| Reference | Description |
|-----------|-------------|
| RFC 6234 | US Secure Hash Algorithms (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) |
| RFC 8032 | Ed25519 and Ed448 — Edwards-Curve Digital Signature Algorithm (EdDSA) |
| RFC 8152 | COSE — CBOR Object Signing and Encryption |
| RFC 7515 | JWS — JSON Web Signature |
| RFC 7693 | BLAKE2 — alternative hashing |
### 3.3 Identifiers and Dates
| Reference | Description |
|-----------|-------------|
| RFC 9562 | Universally Unique IDentifiers (UUIDs) |
| RFC 4122 | UUID URN Namespace |
| RFC 3339 | Date and Time on the Internet: Timestamps |
| ISO 8601 | Date and time format |
### 3.4 Other
| Reference | Description |
|-----------|-------------|
| RFC 2119 / RFC 8174 | Key words for use in RFCs to Indicate Requirement Levels (BCP 14) |
| SemVer 2.0.0 | Semantic Versioning specification |
| BCP 47 | Tags for Identifying Languages |
| Apache 2.0 | License governing the TAP reference implementation |
---
## 4. Standard Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when they appear in any casing.
CDDL and JSON Schema definitions appearing in the appendices are normative. Comments within schemas are non-normative.
---
## 5. Versioning
### 5.1 Protocol Version Declaration
Every Mandate MUST include a `version` field containing a SemVer 2.0.0 version string. The version declares which version of the TAP specification was used to create the document.
A Validator MUST be compatible with at least one version of the specification but MAY be compatible with additional versions. A Validator that encounters a document using a version it does not support MAY reject the document entirely or process the supported subset and indicate partial validation.
### 5.2 Compatibility
The TAP specification evolves via minor and major version bumps:
- **Major version** (e.g., 1.0 → 2.0): breaking changes. Removed fields, changed validation rules, new required fields.
- **Minor version** (e.g., 1.0 → 1.1): compatible additions. New optional fields, new standard action types, new assertion types.
- **Patch version** (e.g., 1.0.0 → 1.0.1): editorial corrections, clarifications, non-normative changes.
A Validator SHOULD ignore unknown fields within a document for forward compatibility. A Validator MUST NOT silently ignore required fields.
### 5.3 Version History
| Version | Date | Summary of Changes |
|---------|------|-------------------|
| 1.0 | 2026-06 | Initial specification. Mandate, ActionRecord, DelegationHop, JurisdictionEvaluation schemas defined. Ed25519 signing. CBOR and JSON serialization. |
---
## 6. Mandates
### 6.1 Overview
A Mandate is the fundamental authorization document in TAP. It records that an Issuing Principal has delegated a defined scope of authority to an Agent for a specified period, within a specified jurisdictional context. The Mandate is signed by the Issuing Principal.
### 6.2 Document Structure
```json
{
"mandate_id": "mnd_01j1xyz...",
"version": "1.0",
"agent_id": "agt_01j2abc...",
"agent_name": "Contract Review Agent — v3",
"issuing_principal": {
"entity": "org_01j3def...",
"human_id": "usr_01j4ghi...",
"role": "General Counsel"
},
"scope": {
"permitted_actions": ["read_contract", "flag_risk", "generate_summary"],
"forbidden_actions": ["sign_contract", "send_external", "access_pii"],
"permitted_data_classes": ["contract_document", "internal_memo"],
"max_delegation_depth": 2,
"resource_bounds": ["matter:M-2026-001"]
},
"jurisdiction_context": {
"deploying_org_jurisdiction": "NG",
"operating_jurisdictions": ["NG", "GB", "EU"],
"regulatory_frameworks": ["EU_AI_ACT", "NDPR"]
},
"validity": {
"issued_at": "2026-06-06T09:00:00Z",
"expires_at": "2026-06-06T17:00:00Z",
"single_use": false
},
"signature": "ed25519:abc123...",
"issuer_public_key": "ed25519:pubkey..."
}
```
**Field descriptions:**
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `mandate_id` | string | yes | Globally unique identifier for this Mandate |
| `version` | string | no (default `"1.0"`) | TAP protocol version used to create this document |
| `agent_id` | string | yes | Identifier of the Agent receiving authority |
| `agent_name` | string | yes | Human-readable name of the Agent |
| `issuing_principal` | object | yes | The Principal issuing this Mandate (see §6.2.1) |
| `scope` | object | yes | The scope of authority delegated (see §6.3) |
| `jurisdiction_context` | object | yes | Jurisdictional context (see §6.4) |
| `validity` | object | yes | Temporal validity (see §6.5) |
| `signature` | string | yes | Ed25519 signature over the canonical document |
| `issuer_public_key` | string | yes | Public key of the Issuing Principal |
#### 6.2.1 Issuing Principal
```json
{
"entity": "org_...",
"human_id": "usr_...",
"role": "General Counsel"
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `entity` | string | yes | Organization or legal entity of the Principal |
| `human_id` | string | yes | Identifier of the human Principal within the entity |
| `role` | string | yes | Role of the Principal (e.g., "General Counsel", "CCO") |
### 6.3 Scope Model
The scope defines what the Agent is authorized to do. Scope is a *deny-overrides* model: if an action matches any entry in `forbidden_actions`, it is unauthorized regardless of `permitted_actions`.
```json
{
"permitted_actions": ["read_contract", "flag_risk"],
"forbidden_actions": ["sign_contract"],
"permitted_data_classes": ["contract_document"],
"max_delegation_depth": 2,
"resource_bounds": ["matter:M-2026-001"]
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `permitted_actions` | array of string | yes | Actions the Agent is allowed to perform (minimum 1) |
| `forbidden_actions` | array of string | no (default `[]`) | Actions the Agent is explicitly forbidden from performing |
| `permitted_data_classes` | array of string | no (default `[]`) | Data classes the Agent may access |
| `max_delegation_depth` | integer | no (default `0`) | Maximum depth of delegation (0 = no delegation) |
| `resource_bounds` | array of string | no (default `[]`) | Resource identifiers that constrain the Agent's scope |
**Rules:**
- `permitted_actions` MUST NOT be empty.
- `forbidden_actions` MAY be empty (no explicit forbiddance beyond what is not permitted).
- `max_delegation_depth` MUST be non-negative. A value of `0` means the Agent MAY NOT delegate.
- Actions are namespaced strings. Standard action types are defined in [Appendix B](#appendix-b-standard-action-types). Custom actions SHOULD use reverse-domain naming.
### 6.4 Jurisdiction Context
The jurisdiction context declares the legal frameworks and geographic jurisdictions under which the Mandate operates.
```json
{
"deploying_org_jurisdiction": "NG",
"operating_jurisdictions": ["NG", "GB"],
"regulatory_frameworks": ["EU_AI_ACT"]
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `deploying_org_jurisdiction` | string | yes | ISO 3166-1 alpha-2 code of the deploying organization's jurisdiction |
| `operating_jurisdictions` | array of string | yes | Jurisdictions in which the Agent will operate (minimum 1) |
| `regulatory_frameworks` | array of string | no (default `[]`) | Regulatory frameworks applicable to this Mandate |
`deploying_org_jurisdiction` and entries in `operating_jurisdictions` MUST be ISO 3166-1 alpha-2 codes. `regulatory_frameworks` entries SHOULD use the namespaced identifiers defined in [Appendix D](#appendix-d-standard-regulatory-frameworks).
### 6.5 Validity
The validity window defines when the Mandate is active.
```json
{
"issued_at": "2026-06-06T09:00:00Z",
"expires_at": "2026-06-06T17:00:00Z",
"single_use": false
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `issued_at` | string (RFC 3339) | yes | When the Mandate becomes active |
| `expires_at` | string (RFC 3339) | yes | When the Mandate expires |
| `single_use` | boolean | no (default `false`) | If `true`, the Mandate is consumed upon the first Action Record |
**Rules:**
- `issued_at` MUST be before `expires_at`.
- If `single_use` is `true`, the Mandate MUST be considered expired after the first Action Record referencing it.
- A Validator SHOULD consider an expired Mandate as invalid and reject new Action Records against it.
### 6.6 Signing
The Mandate MUST be signed by the Issuing Principal's private key. The signature covers the canonical serialization (CBOR or JSON) of the complete Mandate document excluding the `signature` field itself.
The `signature` field value MUST include an algorithm prefix and the raw signature bytes encoded as lowercase hex:
```
:
```
For Ed25519: `ed25519:abcdef...`
The `issuer_public_key` field MUST include the same algorithm prefix:
```
ed25519:
```
---
## 7. Action Records
### 7.1 Overview
An Action Record is the fundamental audit document in TAP. It records that an Agent performed a specific action under a specific Mandate at a specific time. Each Action Record carries content hashes binding it to the action's inputs and outputs, and forms a hash chain with preceding records.
### 7.2 Document Structure
```json
{
"record_id": "act_01j5klm...",
"mandate_id": "mnd_01j1xyz...",
"action_type": "generate_summary",
"timestamp": "2026-06-06T11:23:44Z",
"agent_id": "agt_01j2abc...",
"input_hash": "sha256:abc123...",
"output_hash": "sha256:def456...",
"within_mandate": true,
"jurisdiction_evaluation": {
"evaluated_at": "2026-06-06T11:23:44Z",
"frameworks_applied": ["EU_AI_ACT_ART12"],
"status": "compliant",
"flags": []
},
"chain_position": 0,
"prev_record_hash": null,
"signature": "ed25519:signature..."
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `record_id` | string | yes | Globally unique identifier for this Action Record |
| `mandate_id` | string | yes | The Mandate under which this action was taken |
| `action_type` | string | yes | The type of action performed |
| `timestamp` | string (RFC 3339) | yes | When the action was performed |
| `agent_id` | string | yes | The Agent that performed the action |
| `input_hash` | string | yes | SHA-256 hash of the serialized input data |
| `output_hash` | string | yes | SHA-256 hash of the serialized output data |
| `within_mandate` | boolean | no (default `true`) | Whether the action was deemed within Mandate scope |
| `jurisdiction_evaluation` | object | no | Result of jurisdiction evaluation (see §7.4) |
| `chain_position` | integer | yes | Monotonically increasing position in the chain (0-based) |
| `prev_record_hash` | string or null | no (default `null`) | SHA-256 hash of the preceding Action Record |
| `signature` | string | yes | Ed25519 signature by the Agent |
### 7.3 Chain of Custody
Action Records form a singly linked hash chain. This makes the action log tamper-evident: modifying any record changes its hash, which invalidates all downstream `prev_record_hash` references.
```mermaid
graph LR
AR0["ActionRecord
pos: 0
prev: null
hash: H0"] -->
AR1["ActionRecord
pos: 1
prev: H0
hash: H1"] -->
AR2["ActionRecord
pos: 2
prev: H1
hash: H2"]
```
**Figure 2. Action Record hash chain**
**Rules:**
- The first Action Record in a chain MUST have `chain_position: 0` and `prev_record_hash: null`.
- Each subsequent Action Record MUST have `chain_position` incremented by exactly 1 from the previous record.
- Each subsequent Action Record MUST have `prev_record_hash` equal to the SHA-256 hash of the preceding record's canonical serialization (including its signature field, as signed).
- A new chain begins when a new Mandate is activated or when an Agent changes.
- Action Records from different chains MAY reference the same Mandate.
### 7.4 Content Binding
Action Records bind to their inputs and outputs via cryptographic hashes.
- `input_hash`: SHA-256 hash of the canonical serialization of the action's input data.
- `output_hash`: SHA-256 hash of the canonical serialization of the action's output data.
The hash algorithm is encoded as a prefix: `sha256:`. Other hash algorithms MAY be used, but SHA-256 is REQUIRED for interoperability.
For large payloads, implementers MAY use a Merkle tree root hash instead of a single hash. The tree algorithm MUST be declared in the hash prefix (e.g., `merkle-sha256:`).
### 7.5 Jurisdiction Evaluation
A jurisdiction evaluation MAY be attached to an Action Record to document which regulatory frameworks were considered and what the result was.
```json
{
"evaluated_at": "2026-06-06T11:23:44Z",
"frameworks_applied": ["EU_AI_ACT_ART12", "NDPR_S24"],
"status": "compliant",
"flags": [
{
"framework": "EU_AI_ACT_ART50",
"obligation": "Transparency disclosure to end user required",
"severity": "warning",
"article": "Article 50(1)",
"guidance": "If output was presented to an end user, disclosure was required."
}
]
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `evaluated_at` | string (RFC 3339) | yes | When the evaluation was performed |
| `frameworks_applied` | array of string | no (default `[]`) | Regulatory frameworks that were evaluated |
| `status` | enum | yes | One of `compliant`, `warning`, `violation`, `unknown` |
| `flags` | array of Flag | no (default `[]`) | Specific regulatory flags raised |
**Flag structure:**
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `framework` | string | yes | The regulatory framework identifier |
| `obligation` | string | yes | Description of the regulatory obligation |
| `severity` | enum | yes | One of `warning`, `violation`, `info` |
| `article` | string | no | Specific article or section reference |
| `guidance` | string | no | Guidance on how to address the flag |
### 7.6 Signing
The Agent MUST sign the Action Record. The signature covers the canonical serialization of the complete document excluding the `signature` field.
The signing key MUST correspond to the Agent registered for the referenced Mandate. If the Mandate has been delegated, the Agent's key must be traceable to the Delegation Hop that created the child Mandate.
---
## 8. Delegation Chains
### 8.1 Overview
Delegation chains record how authority flows from an Issuing Principal through one or more Agents. A Delegation Hop documents the creation of a child Mandate from a parent Mandate, including the scope reduction applied. Delegation is monotonic: scope can only be narrowed, never expanded.
### 8.2 Delegation Hop Structure
```json
{
"hop_id": "hop_01j6nop...",
"parent_mandate_id": "mnd_01j1xyz...",
"child_mandate_id": "mnd_02j7qrs...",
"delegating_agent": "agt_01j2abc...",
"receiving_agent": "agt_02j8tuv...",
"receiving_org": "org_02j9wxy...",
"scope_reduction": {
"permitted_actions": ["generate_summary"],
"note": "Scope narrowed from parent. Only summary generation delegated."
},
"cross_boundary": true,
"boundary_type": "organizational",
"timestamp": "2026-06-06T11:30:00Z",
"signature": "ed25519:signature..."
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `hop_id` | string | yes | Globally unique identifier for this hop |
| `parent_mandate_id` | string | yes | The Mandate from which authority is delegated |
| `child_mandate_id` | string | yes | The new Mandate created by this delegation |
| `delegating_agent` | string | yes | The Agent performing the delegation |
| `receiving_agent` | string | yes | The Agent receiving authority |
| `receiving_org` | string | yes | The organization of the receiving Agent |
| `scope_reduction` | object | yes | The scope reduction applied (see §8.3) |
| `cross_boundary` | boolean | yes | Whether this delegation crosses an organizational boundary |
| `boundary_type` | enum | yes | One of `organizational`, `jurisdictional`, `vendor` |
| `timestamp` | string (RFC 3339) | yes | When the delegation occurred |
| `signature` | string | yes | Ed25519 signature by the Delegating Agent |
### 8.3 Scope Reduction
```json
{
"permitted_actions": ["generate_summary"],
"note": "Scope narrowed from parent. Only summary generation delegated."
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `permitted_actions` | array of string | yes | The reduced set of permitted actions (minimum 1) |
| `note` | string | no | Human-readable explanation of the scope reduction |
**Scope reduction rules:**
- The child Mandate's `permitted_actions` MUST be a strict subset of the parent Mandate's `permitted_actions`.
- The child Mandate's `max_delegation_depth` MUST be less than the parent's (unless both are 0).
- The child Mandate's validity window MUST be contained within the parent's.
- The child Mandate's `forbidden_actions` MUST include all of the parent's `forbidden_actions` (the child cannot permit what the parent forbids).
### 8.4 Boundary Types
Three boundary types capture different risk and trust profiles:
| Type | Description | Example |
|------|-------------|---------|
| `organizational` | Within the same organization, different team or department | GC's Agent delegates to a specialist agent in the same law firm |
| `jurisdictional` | Crossing legal borders, different regulatory frameworks | US Agent delegates to an EU Agent subject to GDPR |
| `vendor` | Crossing to a third-party organization | Law firm Agent delegates to a vendor's Agent |
### 8.5 Delegation Chain Validation
```mermaid
graph TB
TR["Trust Root
(Issuing Principal's public key)"] --> M1["Mandate A
signed by Principal"]
M1 --> DH1["Delegation Hop
signed by Agent A"]
DH1 --> M2["Mandate B (child)
signed by Agent A
scope ⊆ Mandate A"]
M2 --> DH2["Delegation Hop
signed by Agent B"]
DH2 --> M3["Mandate C (child)
signed by Agent B
scope ⊆ Mandate B"]
M3 --> AR["ActionRecord
signed by Agent C"]
```
**Figure 3. Full delegation chain from Trust Root to Action Record**
A Validator MUST verify:
1. The parent Mandate exists and is valid (not expired, not revoked).
2. The parent Mandate's `max_delegation_depth` is greater than the current chain depth.
3. The scope reduction is valid (all fields satisfy the reduction rules in §8.3).
4. The Delegation Hop signature is valid and matches the Delegating Agent.
5. The child Mandate exists and is well-formed.
6. The entire chain terminates at a Mandate signed by a recognized Trust Root.
---
## 9. Unique Identifiers
### 9.1 Identifier Format
All TAP documents use globally unique identifiers. The RECOMMENDED identifier format is UUID v7 (RFC 9562), which is time-ordered and collision-resistant. ULID is an acceptable alternative.
### 9.2 Human-Readable Prefixes
Implementations SHOULD prefix identifiers with a type-specific label to aid debugging and logging:
| Document Type | Prefix | Example |
|---------------|--------|---------|
| Mandate | `mnd_` | `mnd_01j1xyz...` |
| Action Record | `act_` | `act_01j5klm...` |
| Delegation Hop | `hop_` | `hop_01j6nop...` |
| Agent | `agt_` | `agt_01j2abc...` |
| Organization | `org_` | `org_01j3def...` |
| User | `usr_` | `usr_01j4ghi...` |
### 9.3 Namespacing
TAP defines the `tap` namespace for all TAP-defined identifiers (action types, data classes, assertion labels). Third-party identifiers MUST use reverse-domain namespacing to avoid collisions.
Examples:
- TAP action type: `tap.action.inference.run`
- Custom action type: `com.example.myAction`
---
## 10. Binding to Content
### 10.1 Overview
Content binding associates TAP documents with the data they describe. TAP defines two binding mechanisms, analogous to C2PA's hard and soft bindings.
### 10.2 Hard Bindings (Hashes)
Hard bindings use cryptographic hashes to uniquely identify content.
**Action Record bindings:**
- `input_hash`: SHA-256 of the canonical serialization of the action's input. For binary inputs, the hash is computed over the raw bytes.
- `output_hash`: SHA-256 of the canonical serialization of the action's output.
**Algorithm prefix convention:**
- `sha256:` — SHA-256
- `sha384:` — SHA-384
- `sha512:` — SHA-512
- `blake2b-256:` — BLAKE2b with 256-bit output
### 10.3 Soft Bindings (Fingerprints)
Soft bindings use non-cryptographic fingerprints for content that is not bit-exact (e.g., floating-point model outputs, perceptually similar images).
```json
{
"alg": "embedding-cosine",
"value": "base64...",
"threshold": 0.95
}
```
Soft bindings MUST declare the algorithm used and MAY declare a similarity threshold. A Validator SHOULD NOT rely on soft bindings for tamper evidence but MAY use them for content identification.
### 10.4 External References
Content that is too large to be practically hashed (or that must remain outside the TAP document) MAY be referenced via URI:
```json
{
"uri": "s3://bucket/action-inputs/act_01j5klm.json",
"hash": "sha256:abc123..."
}
```
An external reference MUST include a hash for integrity verification. Without a hash, the reference is non-verifiable and MUST be treated as informative only.
---
## 11. Trust Model
### 11.1 Overview
Trust in TAP is rooted in the cryptographic identity of Issuing Principals. A Trust Root is a public key that is independently verified to belong to an Issuing Principal. Validators MUST be configured with one or more Trust Roots.
### 11.2 Trust Roots
A Trust Root is an Ed25519 public key (or other supported algorithm) associated with an Issuing Principal. Trust Roots MAY be organized into Trust Lists.
**Trust List structure:**
```json
{
"trust_list_id": "tl_01j...",
"name": "Tensflare Default Trust List",
"version": "1.0",
"roots": [
{
"principal": "org_...",
"public_key": "ed25519:...",
"registered_at": "2026-06-01T00:00:00Z"
}
]
}
```
The Truss platform maintains a public Trust List known as the **TAP Trust List**, which is the default trust anchor for Validators.
### 11.3 Identity of Signers
- **Mandates** are signed by the Issuing Principal's private key. The Principal's public key is declared in `issuer_public_key`.
- **Delegation Hops** are signed by the Delegating Agent's private key.
- **Action Records** are signed by the Agent's private key.
The Agent's public key is not stored in individual records. Instead, it is registered in the Truss Key Registry (or equivalent) at Agent registration time and looked up by `agent_id` during validation.
### 11.4 Validation States
A TAP document passes through four layers of validation:
| State | Condition | Meaning |
|-------|-----------|---------|
| **Well-formed** | The document passes schema validation (valid JSON/CBOR, required fields present, types correct) | The document is syntactically correct |
| **Valid** | Well-formed AND the cryptographic signature verifies against the declared signer | The document has not been tampered with since signing |
| **Trusted** | Valid AND the signer traces to a recognized Trust Root via the delegation chain | The document was issued by an entity whose authority is recognized |
| **Compliant** | Trusted AND jurisdiction evaluation (if present) indicates `compliant` or `warning` status | The action has been evaluated against applicable regulations |
```mermaid
graph TB
A["TAP Document"] --> B["Well-formed?
(Schema validation)"]
B -->|"No"| X["Rejected"]
B -->|"Yes"| C["Valid?
(Signature verification)"]
C -->|"No"| X
C -->|"Yes"| D["Trusted?
(Delegation chain → Trust Root)"]
D -->|"No"| Y["Valid but Untrusted"]
D -->|"Yes"| E["Compliant?
(Jurisdiction evaluation)"]
E -->|"No"| Z["Trusted but Non-Compliant"]
E -->|"Yes"| W["Trusted and Compliant"]
```
**Figure 4. Validation state machine**
### 11.5 Revocation
A Mandate MAY be revoked by the Issuing Principal before its expiry. Revocation is signaled by creating a revocation record:
```json
{
"revocation_id": "rev_01j...",
"mandate_id": "mnd_01j...",
"revoked_at": "2026-06-06T14:00:00Z",
"reason": "scope change",
"revoked_by": "usr_...",
"signature": "ed25519:..."
}
```
**Effects of revocation:**
- The revoked Mandate MUST be considered invalid for new Action Records.
- Existing Action Records signed under the Mandate before revocation remain valid.
- All child Mandates in the delegation chain are transitively revoked.
- Revocation information SHOULD be published to a revocation list accessible to Validators.
---
## 12. Validation
### 12.1 Validation Process
A Validator MUST perform the following steps in order when validating an Accountability Chain:
```mermaid
flowchart TD
S1["1. Schema Validation"] --> S2["2. Signature Verification"]
S2 --> S3["3. Chain Integrity"]
S3 --> S4{"4. Delegation
Chain Present?"}
S4 -->|"Yes"| S5["5. Delegation Chain
Validation"]
S4 -->|"No"| S6["6. Trust Root Check"]
S5 --> S6
S6 --> S7{"7. Jurisdiction
Evaluation Present?"}
S7 -->|"Yes"| S8["8. Jurisdiction
Evaluation Check"]
S7 -->|"No"| S9["9. Content Binding
Verification (optional)"]
S8 --> S9
S9 --> S10["10. Return Validation
Result"]
```
**Figure 5. Validation process**
**Step 1 — Schema validation:** Validate the document against the TAP schema (CDDL for CBOR, JSON Schema for JSON). If the document is not well-formed, reject with status `tap.validation.rejected.malformed`.
**Step 2 — Signature verification:** Verify the cryptographic signature using the signer's public key. If invalid, reject with status `tap.validation.rejected.signature_invalid`.
**Step 3 — Chain integrity:** For Action Records, verify `prev_record_hash` matches the hash of the preceding record (if any). If the chain is broken, reject with status `tap.validation.rejected.chain_broken`.
**Step 4 — Delegation chain:** If the Action Record references a Mandate that has a parent Mandate (via Delegation Hop), recursively validate the delegation chain.
**Step 5 — Trust Root:** Verify that the chain terminates at a Mandate signed by a recognized Trust Root. If not, return status `tap.validation.untrusted`.
**Step 6 — Jurisdiction evaluation:** If present, verify that the jurisdiction evaluation is well-formed. This step does not re-evaluate the jurisdiction — it checks that the evaluation document is valid.
**Step 7 — Content binding:** Optionally verify `input_hash` and `output_hash` against the actual input/output data, if available.
### 12.2 Validation Results
Validation results are returned as a set of status codes:
| Status Code | Type | Description |
|-------------|------|-------------|
| `tap.validation.passed` | success | All checks passed |
| `tap.validation.passed.unverified_binding` | success | Schema, signature, and chain OK; content binding not verified |
| `tap.validation.rejected.malformed` | error | Document does not conform to schema |
| `tap.validation.rejected.signature_invalid` | error | Cryptographic signature does not verify |
| `tap.validation.rejected.chain_broken` | error | Hash chain integrity check failed |
| `tap.validation.rejected.expired` | error | Mandate validity window has expired |
| `tap.validation.rejected.revoked` | error | Mandate has been revoked |
| `tap.validation.rejected.scope_exceeded` | error | Action is outside the Mandate's permitted scope |
| `tap.validation.untrusted` | warning | Document valid but signer does not trace to a Trust Root |
| `tap.validation.info.jurisdiction_flag` | info | Jurisdiction evaluation raised a flag |
| `tap.validation.info.delegation_depth` | info | Deep delegation chain |
### 12.3 Displaying Accountability Information
A Validator SHOULD present the following information to users:
- The **Mandate** that authorized the action, including the Issuing Principal and scope.
- The **Delegation Chain** showing each hop from Trust Root to Agent.
- The **Action Records** in the chain, including timestamps and action types.
- The **Jurisdiction Evaluation** result for each Action Record.
- The **Validation Status** (passed, untrusted, rejected) with specific reason codes.
---
## 13. Standard Assertions
TAP defines a set of standard assertions that MAY be included in Mandates and Action Records. Assertions use the `tap.assertion.*` namespace.
### 13.1 Content Hash Assertion
```json
{
"label": "tap.assertion.contentHash",
"data": {
"alg": "sha256",
"value": "abc123...",
"scope": "input"
}
}
```
Declares the hashing algorithm and value for an associated data payload. `scope` is one of `input`, `output`, or `both`.
### 13.2 Policy Reference Assertion
```json
{
"label": "tap.assertion.policyRef",
"data": {
"uri": "https://org.example.com/policies/ai-usage-v2.pdf",
"hash": "sha256:def456...",
"description": "AI Agent Usage Policy v2"
}
}
```
References an external policy document that governed the action or mandate.
### 13.3 Audit Metadata Assertion
```json
{
"label": "tap.assertion.auditMetadata",
"data": {
"auditor": "usr_...",
"audit_id": "aud_2026-001",
"notes": "Routine compliance audit",
"environment": "production"
}
}
```
Optional metadata for audit tooling. `environment` is one of `production`, `staging`, `development`, `test`.
### 13.4 Timing Assertion
```json
{
"label": "tap.assertion.timing",
"data": {
"started_at": "2026-06-06T11:23:44Z",
"completed_at": "2026-06-06T11:23:47Z",
"duration_ms": 3120
}
}
```
Records the timing characteristics of the action. At least one of `duration_ms` or both `started_at`/`completed_at` MUST be present.
### 13.5 Error Assertion
```json
{
"label": "tap.assertion.error",
"data": {
"success": false,
"error_code": "RATE_LIMIT_EXCEEDED",
"error_message": "API rate limit of 100 req/min exceeded"
}
}
```
Records the error or success state of the action.
### 13.6 Custom Assertions
Any entity MAY define custom assertions using reverse-domain namespacing (e.g., `com.example.assertion.myCustomAssertion`). Custom assertions MUST NOT use the `tap.assertion.*` namespace. A Validator MUST gracefully ignore unknown assertions.
---
## 14. Serialization
### 14.1 CBOR Serialization
TAP documents MAY be serialized as CBOR (RFC 8949). This is the RECOMMENDED wire format for production systems.
CBOR serialization MUST use deterministic encoding:
- Map keys MUST be sorted in bytewise lexicographic order.
- No duplicate map keys.
- Integers MUST be encoded in the smallest possible representation.
- Floats MUST NOT be used; all numeric values are integers.
### 14.2 JSON Serialization
TAP documents MAY be serialized as JSON (RFC 8259). This is RECOMMENDED for development, debugging, and REST APIs.
For deterministic signing, JSON MUST use Canonical JSON (RFC 8785):
- No whitespace between tokens.
- Map keys MUST be sorted lexicographically.
- Integers MUST NOT have leading zeros.
- Strings MUST use `\uXXXX` escaping for non-ASCII characters.
### 14.3 Signing Envelope
For CBOR serialization, documents SHOULD be wrapped in a COSE_Sign1 envelope (RFC 8152) for signatures.
For JSON serialization, documents SHOULD be wrapped in a JWS envelope (RFC 7515) for signatures.
**Envelope-free signing:** When immediate interoperability is not required, documents MAY carry the signature as a top-level `signature` field (as shown in this specification). This is the approach used in the `@tensflare/tap` reference implementation.
### 14.4 Compression
TAP documents MAY be compressed using Brotli or GZip at the transport layer. Compression MUST NOT be applied before signing (the signature must cover the uncompressed document).
---
## 15. Storage and Retrieval
### 15.1 Mandate Store
A Mandate Store is a logical collection of Mandates, Action Records, and Delegation Hops. It may be:
- **Embedded**: stored inline within a larger document (e.g., an API response).
- **External**: stored in a database or repository and retrieved by ID.
### 15.2 Active Mandate
The Active Mandate is the one whose validity window contains the current time and whose `agent_id` matches the action's `agent_id`. If multiple Mandates match, the one with the latest `issued_at` is active.
### 15.3 Manifest Repository
An external repository for long-term storage of TAP documents. Repository features MAY include:
- Search by Mandate ID, Agent ID, action type, jurisdiction, or time range.
- Revocation list serving.
- Trust List publishing.
- Evidence Package generation.
---
## 16. User Experience
### 16.1 Principles
Validators and tools SHOULD follow these UX principles when displaying TAP information:
- **Transparency**: show users who authorized what, when, and under what scope.
- **Minimal disclosure**: show only the information needed for trust decisions by default, with drill-down for details.
- **Auditability**: the full chain of custody SHOULD be navigable (each hop, each action record).
- **Deterministic status**: validation status SHOULD be a single clear result (passed/untrusted/rejected), not a probabilistic score.
### 16.2 Disclosure Levels
| Level | Content |
|-------|---------|
| Basic | Authorization status (trusted/untrusted), Agent name, action type, timestamp |
| Detailed | Scope, jurisdiction context, delegation chain, jurisdiction flags |
| Full | Raw document JSON/CBOR, complete chain with all signatures and hashes |
---
## 17. Security Considerations
### 17.1 Threats
| Threat | Description | Severity |
|--------|-------------|----------|
| **Key compromise** | Attacker obtains a private key and forges Mandates or Action Records | Critical |
| **Replay attack** | Old Action Records replayed in a new context | High |
| **Clock manipulation** | Forging validity windows via incorrect timestamps | High |
| **Scope escalation** | Crafting a child Mandate with broader scope than the parent | Critical |
| **Chain splicing** | Inserting forged records into a hash chain | High |
| **Principal spoofing** | Claiming a false identity as an Issuing Principal | Critical |
### 17.2 Mitigations
- **Key protection:** Agent private keys MUST be stored in secure enclaves or key management systems. The private key MUST NOT be transmitted or stored in plaintext by the Truss API.
- **Timestamp sanity:** Validators SHOULD reject documents with timestamps that deviate from the validator's clock by more than a configurable tolerance (RECOMMENDED: 300 seconds).
- **Scope monotonicity:** Validators MUST enforce scope reduction rules (§8.3) at the protocol level, not just the application level.
- **Chain integrity:** Hash chaining makes chain splicing detectable. Validators MUST verify the complete chain on every validation.
- **Trust Lists:** Validators MUST use independently verified Trust Roots. Trust Lists SHOULD be distributed over authenticated channels.
- **Revocation freshness:** Validators SHOULD check revocation status at validation time and reject documents referencing revoked Mandates.
### 17.3 Harms and Misuse
TAP provides factual information about authorization and actions. As stated in the C2PA guiding principles:
> Specifications SHOULD NOT provide value judgments about whether a given set of provenance data is 'good' or 'bad,' merely whether the assertions included within can be validated as associated with the underlying asset, correctly formed, and free from tampering.
TAP follows the same principle. A Validator may report that an action was *within mandate* or *outside mandate*, but it does not judge whether the action itself was ethically correct.
---
## 18. Patent Policy
The TAP specification and reference implementation (`@tensflare/tap`) are licensed under Apache 2.0. Contributors grant patent rights per the Apache 2.0 grant. Tensflare Ltd commits to maintaining TAP as an open standard and will donate the protocol to neutral governance (Linux Foundation or equivalent) within 24 months of initial publication.
---
## Appendix A: Key Algorithms and Identifiers
### A.1 Signature Algorithms
| Algorithm | Curve | Identifier Prefix | Specification | Status |
|-----------|-------|-------------------|---------------|--------|
| Ed25519 | Ed25519 | `ed25519` | RFC 8032 | REQUIRED |
| ECDSA | P-256 | `ecdsa-p256` | RFC 5758 | RECOMMENDED |
| ECDSA | P-384 | `ecdsa-p384` | RFC 5758 | OPTIONAL |
| Ed448 | Ed448 | `ed448` | RFC 8032 | OPTIONAL |
### A.2 Hash Algorithms
| Algorithm | Identifier Prefix | Output Size | Status |
|-----------|-------------------|-------------|--------|
| SHA-256 | `sha256` | 32 bytes | REQUIRED |
| SHA-384 | `sha384` | 48 bytes | RECOMMENDED |
| SHA-512 | `sha512` | 64 bytes | OPTIONAL |
| BLAKE2b-256 | `blake2b-256` | 32 bytes | OPTIONAL |
| BLAKE2b-512 | `blake2b-512` | 64 bytes | OPTIONAL |
### A.3 Identifier Prefixes
| Document | Prefix | Example |
|----------|--------|---------|
| Mandate | `mnd_` | `mnd_01JAR...` |
| Action Record | `act_` | `act_01JAR...` |
| Delegation Hop | `hop_` | `hop_01JAR...` |
| Revocation | `rev_` | `rev_01JAR...` |
| Agent | `agt_` | `agt_01JAR...` |
| Organization | `org_` | `org_01JAR...` |
| User | `usr_` | `usr_01JAR...` |
| Evidence Package | `evp_` | `evp_01JAR...` |
| Trust List | `tl_` | `tl_01JAR...` |
---
## Appendix B: Standard Action Types
| Action | Namespace | Description |
|--------|-----------|-------------|
| `inference.run` | `tap.action` | Run a single model inference |
| `inference.batch` | `tap.action` | Run a batch of model inferences |
| `data.ingest` | `tap.action` | Ingest data for processing |
| `data.transform` | `tap.action` | Transform or process data |
| `data.export` | `tap.action` | Export data outside the system |
| `data.delete` | `tap.action` | Delete data |
| `agent.delegate` | `tap.action` | Delegate authority to a sub-agent |
| `agent.terminate` | `tap.action` | Terminate an agent session |
| `agent.register` | `tap.action` | Register a new agent |
| `document.read` | `tap.action` | Read or access a document |
| `document.write` | `tap.action` | Create or modify a document |
| `document.sign` | `tap.action` | Sign a document |
| `contract.review` | `tap.action` | Review a contract |
| `contract.execute` | `tap.action` | Execute or countersign a contract |
| `search.execute` | `tap.action` | Execute a search query |
| `search.retrieve` | `tap.action` | Retrieve search results |
| `api.call` | `tap.action` | Call an external API |
| `notification.send` | `tap.action` | Send a notification |
---
## Appendix C: Standard Data Classes
| Class | Namespace | Description |
|-------|-----------|-------------|
| `pii` | `tap.dataclass` | Personally Identifiable Information (GDPR Art 4) |
| `phi` | `tap.dataclass` | Protected Health Information (HIPAA) |
| `financial` | `tap.dataclass` | Financial data (PCI, SOX) |
| `export_controlled` | `tap.dataclass` | Export-controlled data (ITAR, EAR) |
| `legal_privileged` | `tap.dataclass` | Legally privileged communications |
| `contractual` | `tap.dataclass` | Contract terms and obligations |
| `public` | `tap.dataclass` | Public / non-sensitive data |
| `internal` | `tap.dataclass` | Internal business data |
---
## Appendix D: Standard Regulatory Frameworks
| Framework | Namespace | Description |
|-----------|-----------|-------------|
| EU AI Act | `tap.framework.eu_ai_act` | EU Artificial Intelligence Act (Regulation 2024/1689) |
| GDPR | `tap.framework.gdpr` | EU General Data Protection Regulation |
| HIPAA | `tap.framework.hipaa` | US Health Insurance Portability and Accountability Act |
| SOX | `tap.framework.sox` | US Sarbanes-Oxley Act |
| CCPA | `tap.framework.ccpa` | California Consumer Privacy Act |
| NDPR | `tap.framework.ndpr` | Nigeria Data Protection Regulation |
| UK ICO | `tap.framework.uk_ico` | UK Information Commissioner's Office guidance |
| FCA | `tap.framework.fca` | UK Financial Conduct Authority rules |
| SEC | `tap.framework.sec` | US Securities and Exchange Commission rules |
| ISO 42001 | `tap.framework.iso_42001` | AI Management System Standard |
| NIST AI RMF | `tap.framework.nist_ai_rmf` | NIST AI Risk Management Framework |
| Singapore IMDA | `tap.framework.sg_imda` | Singapore Model AI Governance Framework |
| Colorado AI Act | `tap.framework.co_ai_act` | Colorado AI Act (SB 24-205) |
---
## Appendix E: Full CDDL Schemas
### E.1 Mandate
```cddl
mandate = {
mandate_id: tstr,
version: tstr .default "1.0",
agent_id: tstr,
agent_name: tstr,
issuing_principal: {
entity: tstr,
human_id: tstr,
role: tstr
},
scope: {
permitted_actions: [ + tstr ],
? forbidden_actions: [ * tstr ] .default [],
? permitted_data_classes: [ * tstr ] .default [],
? max_delegation_depth: uint .default 0,
? resource_bounds: [ * tstr ] .default []
},
jurisdiction_context: {
deploying_org_jurisdiction: tstr,
operating_jurisdictions: [ + tstr ],
? regulatory_frameworks: [ * tstr ] .default []
},
validity: {
issued_at: tstr, ; RFC 3339
expires_at: tstr, ; RFC 3339
? single_use: bool .default false
},
signature: tstr,
issuer_public_key: tstr
}
```
### E.2 Action Record
```cddl
action-record = {
record_id: tstr,
mandate_id: tstr,
action_type: tstr,
timestamp: tstr, ; RFC 3339
agent_id: tstr,
input_hash: tstr,
output_hash: tstr,
? within_mandate: bool .default true,
? jurisdiction_evaluation: {
evaluated_at: tstr,
? frameworks_applied: [ * tstr ] .default [],
status: "compliant" / "warning" / "violation" / "unknown",
? flags: [ * jurisdiction-flag ] .default []
},
chain_position: uint,
prev_record_hash: tstr / null,
signature: tstr
}
jurisdiction-flag = {
framework: tstr,
obligation: tstr,
severity: "warning" / "violation" / "info",
? article: tstr,
? guidance: tstr
}
```
### E.3 Delegation Hop
```cddl
delegation-hop = {
hop_id: tstr,
parent_mandate_id: tstr,
child_mandate_id: tstr,
delegating_agent: tstr,
receiving_agent: tstr,
receiving_org: tstr,
scope_reduction: {
permitted_actions: [ + tstr ],
? note: tstr
},
cross_boundary: bool,
boundary_type: "organizational" / "jurisdictional" / "vendor",
timestamp: tstr, ; RFC 3339
signature: tstr
}
```
### E.4 Revocation Record
```cddl
revocation-record = {
revocation_id: tstr,
mandate_id: tstr,
revoked_at: tstr, ; RFC 3339
reason: tstr,
revoked_by: tstr,
signature: tstr
}
```
---
## Appendix F: JSON Schema Definitions
### F.1 Mandate
```json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://tap.tensflare.com/schemas/mandate.json",
"title": "Mandate",
"type": "object",
"required": [
"mandate_id", "agent_id", "agent_name",
"issuing_principal", "scope", "jurisdiction_context",
"validity", "signature", "issuer_public_key"
],
"properties": {
"mandate_id": { "type": "string", "minLength": 1 },
"version": { "type": "string", "default": "1.0" },
"agent_id": { "type": "string", "minLength": 1 },
"agent_name": { "type": "string", "minLength": 1 },
"issuing_principal": {
"type": "object",
"required": ["entity", "human_id", "role"],
"properties": {
"entity": { "type": "string", "minLength": 1 },
"human_id": { "type": "string", "minLength": 1 },
"role": { "type": "string", "minLength": 1 }
}
},
"scope": {
"type": "object",
"required": ["permitted_actions"],
"properties": {
"permitted_actions": {
"type": "array", "items": { "type": "string" }, "minItems": 1
},
"forbidden_actions": {
"type": "array", "items": { "type": "string" }
},
"permitted_data_classes": {
"type": "array", "items": { "type": "string" }
},
"max_delegation_depth": {
"type": "integer", "minimum": 0, "default": 0
},
"resource_bounds": {
"type": "array", "items": { "type": "string" }
}
}
},
"jurisdiction_context": {
"type": "object",
"required": ["deploying_org_jurisdiction", "operating_jurisdictions"],
"properties": {
"deploying_org_jurisdiction": { "type": "string", "minLength": 1 },
"operating_jurisdictions": {
"type": "array", "items": { "type": "string" }, "minItems": 1
},
"regulatory_frameworks": {
"type": "array", "items": { "type": "string" }
}
}
},
"validity": {
"type": "object",
"required": ["issued_at", "expires_at"],
"properties": {
"issued_at": { "type": "string", "format": "date-time" },
"expires_at": { "type": "string", "format": "date-time" },
"single_use": { "type": "boolean", "default": false }
}
},
"signature": { "type": "string", "minLength": 1 },
"issuer_public_key": { "type": "string", "minLength": 1 }
}
}
```
### F.2 Action Record
```json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://tap.tensflare.com/schemas/action-record.json",
"title": "ActionRecord",
"type": "object",
"required": [
"record_id", "mandate_id", "action_type", "timestamp",
"agent_id", "input_hash", "output_hash",
"chain_position", "signature"
],
"properties": {
"record_id": { "type": "string", "minLength": 1 },
"mandate_id": { "type": "string", "minLength": 1 },
"action_type": { "type": "string", "minLength": 1 },
"timestamp": { "type": "string", "format": "date-time" },
"agent_id": { "type": "string", "minLength": 1 },
"input_hash": { "type": "string", "minLength": 1 },
"output_hash": { "type": "string", "minLength": 1 },
"within_mandate": { "type": "boolean", "default": true },
"jurisdiction_evaluation": {
"type": "object",
"required": ["evaluated_at", "status"],
"properties": {
"evaluated_at": { "type": "string", "format": "date-time" },
"frameworks_applied": {
"type": "array", "items": { "type": "string" }
},
"status": {
"type": "string",
"enum": ["compliant", "warning", "violation", "unknown"]
},
"flags": {
"type": "array",
"items": {
"type": "object",
"required": ["framework", "obligation", "severity"],
"properties": {
"framework": { "type": "string" },
"obligation": { "type": "string" },
"severity": {
"type": "string",
"enum": ["warning", "violation", "info"]
},
"article": { "type": "string" },
"guidance": { "type": "string" }
}
}
}
}
},
"chain_position": { "type": "integer", "minimum": 0 },
"prev_record_hash": { "type": ["string", "null"] },
"signature": { "type": "string", "minLength": 1 }
}
}
```
### F.3 Delegation Hop
```json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://tap.tensflare.com/schemas/delegation-hop.json",
"title": "DelegationHop",
"type": "object",
"required": [
"hop_id", "parent_mandate_id", "child_mandate_id",
"delegating_agent", "receiving_agent", "receiving_org",
"scope_reduction", "cross_boundary", "boundary_type",
"timestamp", "signature"
],
"properties": {
"hop_id": { "type": "string", "minLength": 1 },
"parent_mandate_id": { "type": "string", "minLength": 1 },
"child_mandate_id": { "type": "string", "minLength": 1 },
"delegating_agent": { "type": "string", "minLength": 1 },
"receiving_agent": { "type": "string", "minLength": 1 },
"receiving_org": { "type": "string", "minLength": 1 },
"scope_reduction": {
"type": "object",
"required": ["permitted_actions"],
"properties": {
"permitted_actions": {
"type": "array", "items": { "type": "string" }, "minItems": 1
},
"note": { "type": "string" }
}
},
"cross_boundary": { "type": "boolean" },
"boundary_type": {
"type": "string",
"enum": ["organizational", "jurisdictional", "vendor"]
},
"timestamp": { "type": "string", "format": "date-time" },
"signature": { "type": "string", "minLength": 1 }
}
}
```
---
## Appendix G: Considerations for Deprecation
### G.1 Status of Constructs
As the TAP protocol evolves, constructs such as action types, data classes, assertion labels, and claim fields may be deprecated. A construct marked as **deprecated** means that a claim generator SHOULD NOT write that construct, but a Validator SHOULD read it.
| Construct | Version Introduced | Deprecated In | Status |
|-----------|-------------------|---------------|--------|
| — | 1.0 | — | Current |
### G.2 Version 1.0 Constructs
All constructs defined in version 1.0 of this specification are **current** and MUST be supported by Validators claiming compatibility with TAP 1.0.
---
*End of specification. Copyright © 2026 Tensflare Ltd. Licensed under Apache 2.0.*