Tensflare Accountability Protocol (TAP) Technical Specification

Version 1.0 — Draft
June 2026
Tensflare Ltd

Table of Contents

1. Introduction
2. Glossary
3. Normative References
4. Standard Terms
5. Versioning
6. Mandates
7. Action Records
8. Delegation Chains
9. Unique Identifiers
10. Binding to Content
11. Trust Model
12. Validation
13. Standard Assertions
14. Serialization
15. Storage and Retrieval
16. User Experience
17. Security Considerations
18. Patent Policy

Appendices

• Appendix A: Key Algorithms and Identifiers
• Appendix B: Standard Action Types
• Appendix C: Standard Data Classes
• Appendix D: Standard Regulatory Frameworks
• Appendix E: Full CDDL Schemas
• Appendix F: JSON Schema Definitions
• 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:

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

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

3.2 Cryptography

3.3 Identifiers and Dates

3.4 Other

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

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

{
  "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:

6.2.1 Issuing Principal

{
  "entity": "org_...",
  "human_id": "usr_...",
  "role": "General Counsel"
}

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.

{
  "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"]
}

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

{
  "deploying_org_jurisdiction": "NG",
  "operating_jurisdictions": ["NG", "GB"],
  "regulatory_frameworks": ["EU_AI_ACT"]
}

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.

6.5 Validity

The validity window defines when the Mandate is active.

{
  "issued_at": "2026-06-06T09:00:00Z",
  "expires_at": "2026-06-06T17:00:00Z",
  "single_use": false
}

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:

<algorithm>:<hex-encoded signature>

For Ed25519: ed25519:abcdef...

The issuer_public_key field MUST include the same algorithm prefix:

ed25519:<hex-encoded public key>

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

{
  "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..."
}

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.

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:<hex>. 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:<root-hex>).

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.

{
  "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."
    }
  ]
}

Flag structure:

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

{
  "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..."
}

8.3 Scope Reduction

{
  "permitted_actions": ["generate_summary"],
  "note": "Scope narrowed from parent. Only summary generation delegated."
}

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:

8.5 Delegation Chain Validation

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:

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:<hex> — SHA-256
• sha384:<hex> — SHA-384
• sha512:<hex> — SHA-512
• blake2b-256:<hex> — 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).

{
  "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:

{
  "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:

{
  "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:

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:

{
  "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:

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:

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

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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

17. Security Considerations

17.1 Threats

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

A.2 Hash Algorithms

A.3 Identifier Prefixes

Appendix B: Standard Action Types

Appendix C: Standard Data Classes

Appendix D: Standard Regulatory Frameworks

Appendix E: Full CDDL Schemas

E.1 Mandate

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

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

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

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

{
  "$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

{
  "$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

{
  "$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.

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.