Agent Trust Protocol (ATP) Specification

Status: Draft | Version: 0.1.0 | Date: February 2026 | Author: AIquilibria ATP Team

Abstract

This document specifies the Agent Trust Protocol (ATP), a framework for creating verifiable accountability in multi-agent AI systems. ATP defines how agents generate cryptographic proofs of task execution, commit proof summaries to a neutral exchange, and respond to verification challenges. The result is a tamper-evident audit trail that supports trust assessment, reputation scoring, and compliance verification across heterogeneous agent deployments.

ATP is transport-agnostic and is designed to complement — not replace — existing agent communication and tool-access protocols.

Status of This Memo

This document is a draft specification published for community review. It does not represent the consensus of any standards body. Feedback is welcomed via the project repository. This document may be updated, replaced, or made obsolete by other documents at any time.

1. Introduction

Autonomous AI agents are increasingly deployed in multi-step workflows where one agent invokes another, chains of execution span organizational boundaries, and no single party has visibility into the full execution history. Existing protocols address agent discovery, communication, and tool access, but do not provide a standardized mechanism for establishing that a task was executed, by whom, and with what inputs and outputs.

The Agent Trust Protocol (ATP) fills this gap. It defines a minimal, privacy-preserving accountability layer: agents record their task executions as cryptographically bound proofs, publish a hash summary to a neutral exchange, and expose a challenge interface so that authorized parties can independently verify execution integrity.

ATP serves as the accountability layer for the emerging agent ecosystem — a foundational trust primitive that complements discovery protocols, communication standards, and domain-specific protocols for payments and commerce.

1.1 Design Goals

Goal	Description
Accountability	Every task execution produces a verifiable proof.
Non-Repudiation	Agents cannot deny task executions they have committed.
Privacy	Only cryptographic hashes are published to the Exchange; full content remains with the executing agent.
Interoperability	Transport-agnostic design works with REST, JSON-RPC, gRPC, and other transports.
Framework Agnostic	Works with any agent framework (A2A, LangChain, MCP, etc.).
Scalability	Lightweight proof sketches (~1–2 KB) are designed to support millions of task executions.
Blockchain-Anchored	Proof hashes are cataloged on a distributed ledger, providing tamper-evident timestamps and an independent integrity anchor for Challenge verification. See Section 11.3.
Decentralized Verification	Any agent authorized under the executing agent's challenge policy may independently verify execution integrity. See Section 10 for the authorization model.
Recursive Verifiability	Verification tasks are themselves subject to the challenge-response protocol.

1.2 Positioning in the Agent Ecosystem

Protocol Category	Examples	What It Provides	What ATP Adds
Discovery	AGNTCY Agent Directory, A2A Agent Cards	Find agents, verify capabilities	Agent capabilities in standardized ontology
Communication	A2A	Enable agent-to-agent interaction	Audit trail of task execution, challenge-response protocol, integrity verification, dependency transparency
Tool Access	MCP	Connect agents to tools and APIs	Audit trail of tool usage
Payments	AP2	Authorize transactions, assign liability	Verification of non-payment agent actions
Commerce	UCP	Orchestrate checkout and order lifecycle	Proof of all agent actions

1.3 Non-Repudiation

Once an agent commits a proof sketch to an ATP Exchange, that agent cannot credibly deny having executed the task. Non-repudiation is achieved through cryptographic binding of task inputs and outputs, immutable timestamping on a distributed ledger, and verified agent identity at the time of committing. The precise mechanisms are defined in Sections 5 (Proof Structure) and 11 (ATP Exchange).

Note: An agent executes a document analysis task and commits a proof sketch to an ATP Exchange. If the execution is later disputed, the committed proof sketch — containing the agent's system identifier, task identifier, timestamp, and cryptographic hashes — provides evidence that the execution occurred. ATP establishes the evidentiary record but does not itself constitute legal or regulatory compliance. Operators are responsible for ensuring ATP usage satisfies applicable requirements in their deployment context.

2. Terminology

2.1 RFC 2119 Keywords

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.

2.2 Roles

Term	Definition
Agent	An autonomous software system capable of performing tasks, generating proofs of execution, and communicating with other agents. An agent that satisfies all requirements defined in Section 4 is said to be ATP-compliant.
Toolbox	A software system that executes tasks and generates proofs, but does not invoke other systems. A Toolbox acts as a leaf node in an execution graph. See Section 4.1. A toolbox that satisfies all requirements defined in Section 4 is said to be ATP-compliant.
Construct	A software system that orchestrates workflows by invoking other agents, but does not execute domain tasks itself. A Construct acts as a root node in an execution graph. See Section 4.3. A construct is an ATP-specific entity and satisfies the requirements laid down in Section 4 for compliance.
Challenger	The agent that initiates a Challenge. A Challenger MUST be ATP-compliant and MUST possess a valid System URI at the time of issuing the Challenge.

2.3 Concepts

Term	Definition
Task	A discrete unit of work with a defined input (Invocation) and output (Outcome).
Invocation	The input to a Task, including the method of triggering, the requester identity, and the input parameters.
Outcome	The output of a Task, including the response, status, and any actions taken.
Proof	A locally stored record documenting a Task execution. Contains the full Invocation and Outcome content, cryptographic hashes, system identity, timestamp, and dependency declarations. See Section 5.1.
Proof Sketch	A privacy-preserving summary of a Proof. Contains only cryptographic hashes and metadata; the Invocation input and Outcome response are omitted. The Proof Sketch is the artifact committed to the ATP Exchange. See Section 5.2.
Commit	The act of submitting a Proof Sketch to the ATP Exchange, creating a non-repudiable, timestamped record. Equivalent to the sometimes used term "anchor".
Challenge	A request from a Challenger to an agent to return the full Proof corresponding to a specified Task. The Challenge-response protocol is defined in Section 12.2.
ATP Exchange	Neutral third-party infrastructure that maintains the registry of Proof Sketches, the Agent Registry, and the Blockchain Catalog. See Section 11.
System URI	A globally unique identifier assigned to an agent upon registration with an ATP Exchange. Format is defined in Section 11.2.
Task ID	A unique identifier for a specific Task execution within the namespace of a registered agent.
AI-BOM	AI Bill of Materials. A dependency graph of all agents and tools invoked during a Task execution, derived from the dependencies array of a Proof. See Section 8.4.
Non-Repudiation	The property of a committed Proof Sketch that makes it computationally infeasible for the executing agent to credibly deny having performed the corresponding Task.
Trust Level	A classification of Proof verification status across three dimensions: Integrity, Quality, and Compliance. Defined in Section 9.1.
Blockchain Catalog	The set of proof hashes recorded on a distributed ledger by the ATP Exchange. The catalog provides two guarantees: immutable timestamping of proof commitment, and an independent integrity anchor against which proof sketches returned during Challenges can be verified. See Section 11.3.

3. Architecture Overview

3.1 Data Flow

Once an agent has registered with an ATP Exchange and obtained a System URI, the following sequence governs ATP-compliant task execution. Registration is a one-time setup step; Steps 2–7 apply to each Task execution.

Step	Action	Description
1	Registration	Agent registers with ATP Exchange → receives System URI (one-time setup).
2	Task Execution	Agent processes Task (Invocation → Outcome).
3	Proof Creation	Agent creates and persists the full Proof locally (full content plus hashes).
4	Commit	Agent commits Proof Sketch to ATP Exchange (hashes only — creates non-repudiable record).
5	Blockchain Catalog	Exchange catalogs proof hash on distributed ledger.
6	Challenge	Authorized agents MAY issue a Challenge requesting proof verification (direct agent-to-agent).
7	Verification	Full Proof integrity verified against Exchange record (Identity + Integrity + Timestamp checks).

3.2 Trust Model

ATP provides eventually trustless accountability through the following trust boundaries:

Exchange is trusted to store Proof Sketches accurately, maintain the Agent Registry, and authenticate all interactions via API keys.
Blockchain Catalog provides tamper-evidence — once committed on-chain, the Exchange cannot retroactively alter any proof hash without the on-chain record revealing the discrepancy. Verification is Exchange-mediated; the protocol does not mandate a specific verification procedure. See Section 11.3.
Blockchain Catalog is trustless — once a proof hash is committed and cataloged, it provides a tamper-evident timestamp and an additional integrity anchor against which Proofs returned during Challenges can be verified.
Verification is cryptographic via hash recomputation; no trusted third party is required for integrity checks once the full Proof is obtained.
Reputation emerges from aggregated Proof history. Because Proof Sketches are committed before reputation is calculated, selective disclosure of favorable results is prevented.

3.3 Authentication and Authorization

Before deploying any ATP-compliant system, an operator MUST register on the ATP Exchange and generate API keys from the Exchange console. These API keys are then provided to agents at deployment time, enabling them to authenticate with the Exchange and complete agent registration (Step 1 of Section 3.1).

All subsequent interactions between ATP-compliant systems and the Exchange MUST be authenticated using these API keys. API keys MAY be scoped with specific permissions; the precise permission model is defined by the Exchange implementation.

Note: API key generation, rotation, and revocation are managed through the Exchange console. Operators SHOULD rotate API keys periodically and MUST revoke and regenerate keys immediately upon suspected compromise. See Section 13.1 for key compromise response procedures.

4. ATP-Compliant System Types

4.1 Toolbox (Server Role Only)

A Toolbox executes tasks and generates proofs. It does NOT invoke other agents and acts as a leaf node in execution graphs.

Examples: Base LLM API, database query agent, domain-specific AI model API, MCP server.

Note: An AI system that is not natively ATP-compliant may be integrated into an ATP workflow by deploying a compliant wrapper around its API. The wrapper assumes responsibility for proof generation, proof sketch commitment, and challenge response on behalf of the underlying system. From the perspective of the Exchange and other ATP-compliant agents, the wrapper is the ATP-compliant Toolbox.

4.2 Agent (Server and Client Roles)

An Agent executes tasks (server role) AND invokes other agents (client role). Agents are interior nodes in execution graphs. An Agent MUST fulfill all Toolbox requirements and additionally MUST invoke other agents, verify their responses, and declare dependencies. Each response MUST include a task_id for downstream proof verification.

Examples: Agentic AI system that uses tools, composite services, middleware agents.

4.3 Construct (Client Role Only)

A Construct orchestrates workflows by invoking other agents. It does NOT execute domain tasks itself and acts as the root node in execution graphs.

Examples: User-defined workflow, multi-step pipeline, orchestration engine with conditional logic.

4.4 Requirements Summary

Requirement	Toolbox	Agent	Construct
Generate Proofs	MUST	MUST	MAY *
Commit Proof Sketches	MUST	MUST	MAY *
Store Proofs Locally (TTL)	MUST	MUST	MAY *
Respond to Challenges (JSON-RPC)	MUST	MUST	MAY *
Return `task_id` in Response	MUST	MUST	—
Invoke Other Agents	—	MUST	MUST
Query Exchange for Proof Sketches	—	MUST	MUST
Validate Proof Integrity	—	MUST	MUST
Declare Dependencies	—	MUST	MAY *
Declare Capabilities at Registration	SHOULD	SHOULD	—

* Required if the Construct creates Proofs (e.g., for conditional logic or orchestration decisions).

4.5 Agent Registration

Before executing any Tasks, an ATP-compliant system MUST register with an ATP Exchange. Registration requires a valid API key obtained from the Exchange console (see Section 3.3). Upon successful registration, the Exchange assigns a system_uri and system_id to the registering system. These identifiers are permanent for the lifetime of the registration and MUST be included in all Proofs and Proof Sketches generated by that system. See Section 11.1 for Exchange responsibilities in processing registration.

The registration request MAY include a capabilities array declaring what Tasks the system is able to perform. Each capability entry contains a free-form description and a structured ontology block. The ontology block classifies the capability using a standardized taxonomy, enabling capability-based agent discovery across the Exchange. The full classification schema is defined in Section 6. Systems SHOULD declare capabilities at registration; undeclared capabilities reduce discoverability and may limit trust assessment by downstream agents.

json

POST /register
{
  "name": "Medical Analysis Agent",
  "type": "agent",
  "capabilities": [
    {
      "description": "Patient diagnosis from symptoms and lab results",
      "ontology": {
        "ontology_uri": "https://atp.aiquilibria.com/ontology/v0.1.0",
        "occupation": "29-1141.00",
        "work_activities": ["4.A.4.a.5"],
        "capabilities": ["document-question-answering"]
      }
    }
  ]
}

// Response
{
  "system_uri":               "https://exchange.aiquilibria.com/systems/a1b2b3",
  "system_id":                "a1b2b3",
  "registered_at":            "2026-02-01T00:00:00Z",
  "status":                   "active",
  "capabilities_registered":  1
}

Note: The system_uri returned in the registration response is the globally unique identifier for this system on the Exchange. It appears in the atp_metadata.system_uri field of every Proof and Proof Sketch the system generates, and in the requester_system_uri and responder_system_uri fields of ATP payloads. API keys are managed separately through the Exchange console and are not returned in the registration response.

Tip: Capabilities declared at registration are used by the Exchange to power agent discovery and reputation tracking. Capabilities and other registration fields MAY be updated by re-issuing POST /register with the same system name and API key. The Exchange detects that the system is already registered and applies any changed fields idempotently. This operation is safe to call on every agent startup.

5. Proof Structure

5.1 Full Proof (Local Storage)

The full Proof is the complete record of a Task execution. It is stored locally by the executing agent and MUST NOT be transmitted to the Exchange. It contains all Invocation and Outcome content alongside cryptographic hashes and metadata.

json

{
  "atp_metadata": {
    "spec_version": "0.1.0",
    "spec_uri": "https://atp.aiquilibria.com/spec/v0.1.0",
    "system_uri": "https://exchange.aiquilibria.com/systems/a1b2b3",
    "system_type": "agent",
    "task_id": "123abc",
    "classification": {
      "description": "Free-form task description",
      "ontology": {
        "ontology_version": "0.1.0",
        "ontology_uri": "https://atp.aiquilibria.com/ontology/v0.1.0",
        "occupation": "29-1141.00",
        "work_activities": ["assisting-caring-for-others"],
        "capabilities": ["document-question-answering"]
      }
    }
  },
  "invocation": {
    "method": "query",
    "trigger": {
      "source": "user_api",
      "requester_system_uri": "https://exchange.aiquilibria.com/systems/xyz",
      "authenticated": true
    },
    "input": {
      "query": "ACTUAL QUERY CONTENT",
      "context": {},
      "parameters": {}
    }
  },
  "outcome": {
    "result": {
      "response": "ACTUAL RESPONSE CONTENT",
      "actions": []
    },
    "status": "success",
    "error": null
  },
  "dependencies": [],
  "cryptography": {
    "algorithm": "SHA-256",
    "invocation_hash": "sha256:abc123...",
    "outcome_hash": "sha256:def456...",
    "dependencies_hash": "sha256:ghi789..."
  },
  "timestamp": "2026-02-07T10:30:00.123Z",
  "storage": {
    "created_at": "2026-02-07T10:30:05.900Z",
    "ttl_days": 90,
    "expires_at": "2026-05-08T10:30:05.900Z"
  }
}

5.2 Proof Sketch (Exchange Commitment)

The Proof Sketch is the artifact committed to the ATP Exchange. It contains only atp_metadata, dependencies, cryptography (the three SHA-256 hashes), and timestamp. The full invocation and outcome objects — including all inputs, outputs, and intermediate content — are not included in the Proof Sketch and remain stored locally by the executing agent. This preserves complete confidentiality of all task content while enabling cryptographic integrity verification via the committed hashes.

Note: The hashes in cryptography (invocation_hash, outcome_hash, dependencies_hash) are computed over the full invocation and outcome objects before those objects are discarded. Challengers obtain the full Proof directly from the target agent (Section 12.2) and verify these hashes locally against the committed Proof Sketch.

5.3 Hash Computation

python

# Invocation hash
invocation_hash = SHA256(canonical_json_serialize(invocation))

# Outcome hash
outcome_hash = SHA256(canonical_json_serialize(outcome))

# Dependencies hash (empty array → hash of "[]")
dependencies_hash = SHA256(canonical_json_serialize(dependencies))

Note: Canonical JSON serialization requires: sort object keys alphabetically at all nesting levels; remove all insignificant whitespace; encode as UTF-8; use consistent number formatting (no trailing zeros, no leading zeros). Implementations MUST produce byte-for-byte identical output for equivalent data structures to ensure hash reproducibility across agents and languages.

5.4 Invocation Methods

Method	Trigger	`result.response`
`query`	External request triggers execution.	MUST be present — synchronous response expected by requester.
`scheduled`	Time-based trigger (e.g., cron).	OPTIONAL — no requester is awaiting a synchronous response.
`event`	External event (e.g., CloudWatch alert).	OPTIONAL — response depends on event handling requirements.

6. Task Classification Ontology

ATP uses a standardized classification system that leverages the U.S. Department of Labor O*NET occupational taxonomy and the HuggingFace task capability taxonomy, extended with ATP-specific categories. Classification is used in two contexts:

System Registration — declared in the capabilities array at registration time (see Section 4.5), enabling capability-based agent discovery across the Exchange.
Proof Metadata — recorded in the atp_metadata.classification field of each Proof (see Section 5.1), providing a permanent, structured record of what type of Task was executed.

6.1 Classification Fields

Field	Source	Format	Example
`occupation`	U.S. DOL O*NET SOC	8-digit SOC code	`"29-1141.00"` (Registered Nurses)
`work_activities`	O*NET Work Activities Taxonomy	Array of activity identifiers	`["4.A.1.b.2.I03.D03"]` (Analyze test results)
`capabilities`	HuggingFace Task Taxonomy + ATP Extensions	Array of capability identifiers	`["document-question-answering"]`
`description`	Free-form	Natural language text	Any task-specific details

6.2 Capability Registry

The following capability identifiers are defined in the ATP ontology. This registry is exhaustive for version 0.1.0; additional identifiers MUST NOT be used unless registered as ATP extensions via the ontology update process. The ontology_uri field in both registration and Proof metadata identifies the ontology version in use.

Code: code-completion, code-debugging, code-explanation, code-generation, code-translation, reinforcement-learning, test-generation

Multimodal: document-question-answering, image-text-to-text, table-question-answering, video-text-to-text, visual-question-answering

NLP: audio-classification, automatic-speech-recognition, conversational, feature-extraction, fill-mask, question-answering, sentence-similarity, summarization, tabular-classification, tabular-regression, text2text-generation, text-classification, text-generation, text-to-speech, time-series-forecasting, token-classification, translation, zero-shot-classification

Systems (ATP Extensions): configuration-management, incident-response, infrastructure-automation, log-analysis, performance-optimization, robotics, security-scanning

Vision: depth-estimation, image-classification, image-segmentation, image-to-image, image-to-text, object-detection, text-to-image, unconditional-image-generation, video-classification, video-generation, zero-shot-image-classification

7. Communication Protocols

7.1 Transport Requirements

Communication Type	Required Transport	Rationale
Agent ↔ Exchange	REST API over HTTPS with JSON	Standardization; universal tooling support.
Agent ↔ Agent (Challenge)	JSON-RPC 2.0	Lightweight RPC; bidirectional; broad framework compatibility.
Agent ↔ Agent (Task Invocation)	Agent-defined	Flexibility and framework independence. ATP imposes no constraint on the invocation transport.

7.2 ATP Payload — Request Format

When an ATP-compliant Construct or Agent invokes another agent, it MAY include an atp_payload object in the request to pass ATP context to the receiving agent. The payload serves two purposes: declaring prior task executions that the receiving agent SHOULD treat as dependencies and include in its own Proof, and specifying verification policies the requester expects the receiving agent to apply. The receiving agent's own policies take precedence where they are stricter.

json

{
  "atp_payload": {
    "requester_system_uri": "https://exchange.aiquilibria.com/systems/abc123",
    "context": {
      "dependencies": [
        {
          "system_uri": "https://exchange.aiquilibria.com/systems/lab_analyzer",
          "task_id": "task_456",
          "reason": "Lab results required as input context for this task"
        }
      ]
    },
    "requirements": {
      "verify_dependencies": {
        "evaluation_type": "quality",
        "evaluation_policy": "internal-qa-v1"
      }
    }
  },
  "query": "Original request content here"
}

Note: Dependencies declared in atp_payload.context.dependencies are passed by the requester as input context. The receiving agent SHOULD verify and declare these in its own dependencies array alongside any dependencies it invokes directly. This enables the requester's orchestration context to be captured in the receiving agent's Proof and committed to the Exchange as part of its AI-BOM.

Note: evaluation_policy is meaningful only for Quality and Compliance evaluation types. For integrity evaluations, evaluation_policy is ignored — integrity verification is defined solely by the hash recomputation procedure in Section 9.2 and admits no policy variation.

7.3 ATP Payload — Response Format

When an ATP-compliant agent responds to a request, it SHOULD include an atp_payload object in the response to communicate the integrity status of the completed Task to the requester.

json

{
  "atp_payload": {
    "responder_system_uri": "https://exchange.aiquilibria.com/systems/medical_ai",
    "responder_task_id":    "task_789",
    "assessments": [
      {
        "evaluation_type":   "integrity",
        "evaluation_result": "verified"
      },
      {
        "evaluation_type":   "quality",
        "evaluation_policy": "internal-qa-v1",
        "evaluation_result": "passed"
      }
    ]
  },
  "result": {
    "response": "Original response content here",
    "status":   "success",
    "actions":  [],
    "error":    null
  }
}

Warning: Agents MAY self-report Integrity level in responses, which is independently verifiable against the Exchange. Agents MUST NOT self-report Quality or Compliance — such fields MUST be ignored by recipients if present. Quality and Compliance assessments are issued exclusively by third-party agents acting in an assessor capacity (see Section 9.3).

8. Core Patterns

8.1 Basic Task Execution

The minimal ATP interaction involves a single system executing a Task, creating a Proof, and committing the Proof Sketch to the Exchange. This pattern applies to all Toolboxes and Agents regardless of workflow complexity.

Phase	Action	Outcome
Invocation	System receives Task request.	Invocation recorded in Proof.
Execution	System processes Task.	Outcome recorded in Proof.
Proof Creation	System computes hashes and assembles full Proof.	Full Proof persisted locally.
Commit	System commits Proof Sketch to Exchange.	Non-repudiable record created.
Response	System returns result with `task_id` to requester.	Requester can verify execution via Exchange.

8.2 Task Delegation and Inline Verification

When an Agent or Construct delegates a Task to a downstream system, it MUST verify the integrity of that system's execution before incorporating the result into its own Task. This verification is a prerequisite to proof creation, not an optional post-hoc step. The delegating system MUST record the integrity assessment of each dependency in the evaluations array of the corresponding dependency entry in its own Proof.

Step	Action	Description
1	Delegate Task	Agent invokes downstream system and awaits response.
2	Collect Task ID	Agent extracts `task_id` from the downstream system's response. Absence of a `task_id` indicates a non-ATP-compliant dependency; see Section 8.4.
3	Query Exchange	Agent retrieves the committed Proof Sketch for the dependency from the Exchange.
4	Verify Integrity	Agent recomputes hashes from the Proof Sketch and verifies against the Exchange record. See Section 9.2.
5	Continue Execution	Agent proceeds with its own Task execution, incorporating the verified result.
6	Declare Dependency	Agent records the dependency — including `system_uri`, `task_id`, and all evaluations performed — in the `dependencies` array of its own Proof.
7	Commit	Agent commits its own Proof Sketch to the Exchange, including the dependencies array.

json

// Example dependency entry recorded after inline verification
{
  "dependencies": [
    {
      "system_uri": "https://exchange.aiquilibria.com/systems/lab_analyzer",
      "task_id": "task_456",
      "evaluations": [
        {
          "evaluation_type": "integrity",
          "evaluation_result": "verified",
          "evaluated_at": "2026-02-07T10:30:01.234Z"
        }
      ]
    }
  ]
}

Note: Inline verification requires at minimum an integrity evaluation for each dependency. Agents MAY additionally record quality or compliance evaluations against dependencies where their implementation supports this. Recording richer evaluations at delegation time strengthens the declaring agent's own trust posture and contributes to the downstream agent's reputation history.

8.3 Challenge and Verification

Any authorized agent MAY issue a Challenge to verify the integrity of a committed Proof Sketch for a previously executed Task. Unlike inline delegation verification (Section 8.2), a Challenge is initiated independently of task execution — it does not require the Challenger to be in an active delegation relationship with the target agent. The full Proof is transmitted directly between agents; the Exchange serves only as the source of the committed Proof Sketch against which integrity is verified.

Step	Action	Description
1	Query Exchange	Challenger retrieves the committed Proof Sketch for the target `task_id` from the Exchange.
2	Issue Challenge	Challenger sends Challenge request directly to the target agent (JSON-RPC 2.0). See Section 12.2.
3	Evaluate Authorization	Target agent evaluates the Challenger against its challenge policy (see Section 10).
4	Return Full Proof	If authorized, target agent returns full Proof directly to Challenger.
5	Verify Integrity	Challenger recomputes all hashes and compares against the committed Proof Sketch. See Section 9.2.
6	Assess and Record	Challenger records all evaluation results as a dependency entry in its own Proof before committing.

Warning: Integrity verification alone is insufficient for trust assessment. A passing integrity check confirms only that the Proof was not tampered with after commitment — it does not attest to the quality or compliance of the work performed. Challengers SHOULD record Quality and Compliance evaluations alongside the integrity result, or clearly scope their assessment to integrity only.

All evaluations performed during or following a Challenge MUST be recorded in the evaluations array of the corresponding dependency entry in the Challenger's own Proof. This makes the assessment itself non-repudiable and part of the committed record. Multiple evaluation types MAY be recorded against the same dependency.

json

// Example dependency entry with evaluations in a Proof Sketch
{
  "dependencies": [
    {
      "system_uri": "https://exchange.aiquilibria.com/systems/lab_analyzer",
      "task_id": "task_456",
      "evaluations": [
        {
          "evaluation_type": "integrity",
          "evaluation_result": "verified",
          "evaluated_at": "2026-02-07T11:00:00.123Z"
        },
        {
          "evaluation_type": "quality",
          "evaluation_policy": "internal-qa-v1",
          "evaluation_result": "passed",
          "evaluated_at": "2026-02-07T11:00:01.456Z"
        }
      ]
    }
  ]
}

Note: A Challenger MAY additionally challenge the dependencies declared in a verified Proof, using the system_uri and task_id of each dependency to locate and challenge it independently. Because each dependency is itself a committed Proof Sketch, verification can recurse to any depth and provides full AI-BOM auditability. The protocol does not mandate recursive verification beyond the immediate dependencies of the challenged Proof.

8.4 Dependency Disclosure

When an Agent or Construct invokes other ATP-compliant systems to complete a Task, it MUST declare those invocations in the dependencies array of its Proof. Each dependency entry identifies the downstream system and the specific Task execution that was invoked, along with any evaluations performed against it. The complete dependency graph committed to the Exchange enables full AI-BOM reconstruction for any Task in the system.

Invocations of non-ATP-compliant systems cannot be represented in the dependencies array and are therefore invisible to the Exchange, Challengers, and reputation systems. The declaring agent assumes full liability for any outputs sourced from outside the ATP ecosystem. Wrapping non-ATP-compliant systems as ATP-compliant Toolboxes (see Section 4.1) is the recommended path to full AI-BOM coverage.

Scenario	Liability Scope	Trust Impact
All dependencies declared and ATP-compliant	Downstream failures are attributed to the downstream agent. The declaring agent's liability is limited to its own execution.	Full AI-BOM verifiable. Strongest trust posture; each dependency can be independently challenged.
Dependencies omitted or sourced from outside ATP	The declaring agent assumes unlimited liability. All failures in the execution chain are attributed to it.	AI-BOM cannot be reconstructed. Reputation and compliance assessments will reflect the absence of transparency.

json

// Example: fully declared ATP-compliant dependency
{
  "dependencies": [
    {
      "system_uri": "https://exchange.aiquilibria.com/systems/lab_analyzer",
      "task_id": "task_456",
      "evaluations": [
        {
          "evaluation_type": "integrity",
          "evaluation_result": "verified",
          "evaluated_at": "2026-02-07T10:30:01.234Z"
        }
      ]
    }
  ]
}

Warning: Agents that omit dependency declarations or invoke systems outside the ATP ecosystem accrue weaker reputation scores over time. In regulated deployment contexts, undisclosed dependencies may constitute a compliance violation independent of ATP assessment. Operators SHOULD treat dependency disclosure and ATP coverage of all invoked systems as a first-class architectural concern.

9. Verification & Assessment

9.1 Multi-Dimensional Trust Model

Dimension	Negative	Neutral	Positive	Who Assesses
Integrity	compromised	unverified	verified	Any authorized Challenger or delegating Agent, via Proof Sketches from the Exchange and Proofs from the challenged Agent.
Quality	failed	unevaluated	passed	Any ATP-compliant agent acting in an assessor capacity.
Compliance	non-compliant	unassessed	compliant	Any ATP-compliant agent acting in an assessor capacity.

All trust assessments MUST be recorded in the evaluations array of the corresponding dependency entry in the assessing agent's own Proof.

9.2 Integrity Verification Steps

A Verifier obtains the full Proof from the target agent via the Challenge interface (Section 12.2), then performs the following checks:

python

# Step 1: Recompute invocation hash from full proof
computed_invocation_hash = sha256(canonical_json_serialize(full_proof.invocation))

# Step 2: Compare with committed proof sketch
assert computed_invocation_hash == proof_sketch.cryptography.invocation_hash

# Step 3: Recompute outcome hash
computed_outcome_hash = sha256(canonical_json_serialize(full_proof.outcome))

# Step 4: Compare with committed proof sketch
assert computed_outcome_hash == proof_sketch.cryptography.outcome_hash

# Step 5: Recompute dependencies hash (empty array → hash of "[]")
computed_dependencies_hash = sha256(canonical_json_serialize(full_proof.dependencies))

# Step 6: Compare with committed proof sketch
assert computed_dependencies_hash == proof_sketch.cryptography.dependencies_hash

# All assertions pass  → Integrity = "Verified"
# Any assertion fails  → Integrity = "Compromised"

Note: Steps 1–6 verify proof integrity against the Exchange record. Additional verification against the Blockchain Catalog is Exchange-mediated and outside the scope of this protocol. Exchange implementations MAY expose additional APIs to support this verification. See Section 11.3.

10. Authorization

Challenge authorization is implicit in the ATP workflow. Challengers learn of valid system_uri and task_id pairs through legitimate participation in ATP workflows — via Construct delegation, ATP response payloads, or Exchange queries. No additional authorization mechanism is required at the protocol level.

Agents MUST authenticate all incoming Challenge requests against the Exchange to confirm the Challenger holds a valid API key. Beyond this, agents SHOULD implement rate limiting on their Challenge interface to prevent brute force probing of task identifiers. Specific rate limiting requirements are implementation-defined; see Section 13 for security considerations.

Note: The implicit authorization model relies on task_id values being opaque and non-guessable. ATP-compliant systems MUST generate task_id values using a cryptographically secure random generator prior to task execution. task_id values MUST be UUIDs (RFC 4122 version 4). Agents MUST NOT use sequential or otherwise predictable identifiers for task_id.

11. ATP Exchange

11.1 Responsibilities

Operator Console — Web interface for operator registration and API key management. See Section 11.2.
Agent Registry — Register ATP-compliant systems, issue System URIs, and maintain capability declarations via API.
Proof Sketch Storage — Accept, authenticate, and store committed Proof Sketches.
Blockchain Catalog — Batch and anchor proof hashes to a distributed ledger for tamper-evident timestamping. See Section 11.3.
API Endpoints — Expose query, commitment, and registry APIs authenticated via API keys. See Section 12.
Identity Verification — Validate API keys and confirm system identity on all authenticated interactions.
Challenge Key Validation — Validate API keys presented during Challenge requests on behalf of target agents. See Section 10.
Reputation Services (OPTIONAL) — Aggregate Proof and evaluation history into reputation scores queryable via API.

11.2 Operator Console

The Exchange console is the administrative interface through which operators manage their participation in the ATP ecosystem. All console operations require operator authentication. The following capabilities MUST be provided by the Exchange console:

Capability	Description
Operator Registration	Create and manage an operator account on the Exchange. Required before any API keys or agents can be provisioned.
API Key Management	Generate, rotate, and revoke API keys used by ATP-compliant systems to authenticate with the Exchange.
Proof Sketch Explorer	Query committed Proof Sketches and evaluation history for systems under the operator's account.
Reputation Dashboard (OPTIONAL)	View aggregated reputation scores and assessment history for registered systems.

11.3 Blockchain Cataloging

The Exchange MUST catalog committed proof hashes on a distributed ledger. The choice of distributed ledger and the implementation of the cataloging mechanism are Exchange-dependent; ATP does not mandate a specific chain or batching strategy.

Note: Only opaque commitment hashes are submitted on-chain. No task content, metadata, agent identity, or classification information is included in the blockchain record. All proof data remains with the Exchange or the executing agent.

Warning: The dependency on a distributed ledger introduces infrastructure coupling, confirmation latency, and transaction cost considerations. Exchange operators SHOULD document their chain selection rationale, confirmation time SLAs, and fallback behaviour during chain unavailability.

12. API Specifications

12.1 Exchange REST API Endpoints

All Exchange API endpoints require authentication via API key. Keys are provisioned from the Exchange console as described in Section 3.3.

Endpoint	Method	Purpose
`/register`	POST	Register an ATP-compliant system and obtain a System URI.
`/commit`	POST	Commit a Proof Sketch to the Exchange.
`/systems/{id}/tasks/{task_id}`	GET	Query the anchored Proof Sketch for a specific Task.
`/systems/{id}`	GET	Retrieve metadata and capability declarations for a registered system.

12.2 JSON-RPC 2.0 Challenge Interface (REQUIRED)

All Toolboxes and Agents MUST expose a JSON-RPC 2.0 endpoint implementing the atp.challenge method. Constructs MAY implement this endpoint if they generate Proofs. The Challenger MUST present a valid API key alongside the Challenge request. The target agent MUST validate the key against the Exchange before responding.

json

// Challenge Request
{
  "jsonrpc": "2.0",
  "method":  "atp.challenge",
  "params": {
    "task_id":               "task_123",
    "challenger_system_uri": "https://exchange.aiquilibria.com/systems/challenger"
  },
  "id": 1
}

// Challenge Response — Authorized
{
  "jsonrpc": "2.0",
  "result": {
    "authorized": true,
    "full_proof": { }
  },
  "id": 1
}

// Challenge Response — Denied
{
  "jsonrpc": "2.0",
  "result": {
    "authorized": false,
    "reason":     "invalid_key",
    "details":    "API key is invalid or has been revoked"
  },
  "id": 1
}

Warning: API keys transmitted in Challenge requests MUST be treated as sensitive credentials. Challenge endpoints MUST be served over TLS. Agents SHOULD implement rate limiting on this endpoint to prevent brute force probing of task identifiers; see Section 13.2.

13. Security Considerations

13.1 API Key Compromise

Compromised API keys permit an attacker to anchor fraudulent Proof Sketches under the agent's identity, impersonate the agent in Challenge responses, or query protected Exchange resources. Mitigation: immediately revoke the compromised key via the Exchange console, regenerate credentials, and conduct a forensic review of all Proof Sketches committed during the compromise window.

Warning: Rotate API keys at least every 90 days. Store keys encrypted at rest using a hardware security module (HSM) or equivalent secure credential vault. Monitor for anomalous anchoring patterns: rate spikes, geographic anomalies, and off-hours activity.

13.2 Anti-Spam and Denial-of-Service

Attack Vector	Mitigation
Proof Sketch commit spam	Rate limiting per API key enforced by the Exchange. Authentication is required for all anchor operations.
Challenge brute force	Agents SHOULD implement rate limiting on their JSON-RPC Challenge endpoint. Repeated Challenge requests for non-existent `task_id` values from the same `challenger_system_uri` SHOULD result in temporary suspension of Challenge access from that system. Task identifiers MUST be cryptographically random and non-guessable; see Section 10.
Challenge endpoint denial-of-service	Challenge endpoints MUST be served over TLS. Agents SHOULD implement connection rate limiting and request timeouts on their JSON-RPC endpoint independently of per-challenger limits.
Timestamp manipulation	Blockchain cataloging provides an immutable upper bound on Proof timestamp. The committed chunk timestamp on-chain MUST post-date the `proof.timestamp` field; Exchange implementations MUST enforce this at commit time.

14. Implementation Requirements

14.1 Compliance Levels

Keyword	Meaning
MUST	Mandatory for ATP compliance. An implementation that does not satisfy a MUST requirement is not ATP-compliant.
SHOULD	Strongly recommended. Non-compliance is permitted but SHOULD be documented with a rationale; it may reduce interoperability or trust.
MAY	Permitted but not required. Implementations are free to omit or include these features.

Agent Trust Protocol (ATP) Specification ​

Abstract ​

Status of This Memo ​

1. Introduction ​

1.1 Design Goals ​

1.2 Positioning in the Agent Ecosystem ​

1.3 Non-Repudiation ​

2. Terminology ​

2.1 RFC 2119 Keywords ​

2.2 Roles ​

2.3 Concepts ​

3. Architecture Overview ​

3.1 Data Flow ​

3.2 Trust Model ​

3.3 Authentication and Authorization ​

4. ATP-Compliant System Types ​

4.1 Toolbox (Server Role Only) ​

4.2 Agent (Server and Client Roles) ​

4.3 Construct (Client Role Only) ​

4.4 Requirements Summary ​

4.5 Agent Registration ​

5. Proof Structure ​

5.1 Full Proof (Local Storage) ​

5.2 Proof Sketch (Exchange Commitment) ​

5.3 Hash Computation ​

5.4 Invocation Methods ​

6. Task Classification Ontology ​

6.1 Classification Fields ​

6.2 Capability Registry ​

7. Communication Protocols ​

7.1 Transport Requirements ​

7.2 ATP Payload — Request Format ​

7.3 ATP Payload — Response Format ​

8. Core Patterns ​

8.1 Basic Task Execution ​

8.2 Task Delegation and Inline Verification ​

8.3 Challenge and Verification ​

8.4 Dependency Disclosure ​

9. Verification & Assessment ​

9.1 Multi-Dimensional Trust Model ​

9.2 Integrity Verification Steps ​

10. Authorization ​

11. ATP Exchange ​

11.1 Responsibilities ​

11.2 Operator Console ​

11.3 Blockchain Cataloging ​

12. API Specifications ​

12.1 Exchange REST API Endpoints ​

12.2 JSON-RPC 2.0 Challenge Interface (REQUIRED) ​

13. Security Considerations ​

13.1 API Key Compromise ​

13.2 Anti-Spam and Denial-of-Service ​

14. Implementation Requirements ​

14.1 Compliance Levels ​

Agent Trust Protocol (ATP) Specification

Abstract

Status of This Memo

1. Introduction

1.1 Design Goals

1.2 Positioning in the Agent Ecosystem

1.3 Non-Repudiation

2. Terminology

2.1 RFC 2119 Keywords

2.2 Roles

2.3 Concepts

3. Architecture Overview

3.1 Data Flow

3.2 Trust Model

3.3 Authentication and Authorization

4. ATP-Compliant System Types

4.1 Toolbox (Server Role Only)

4.2 Agent (Server and Client Roles)

4.3 Construct (Client Role Only)

4.4 Requirements Summary

4.5 Agent Registration

5. Proof Structure

5.1 Full Proof (Local Storage)

5.2 Proof Sketch (Exchange Commitment)

5.3 Hash Computation

5.4 Invocation Methods

6. Task Classification Ontology

6.1 Classification Fields

6.2 Capability Registry

7. Communication Protocols

7.1 Transport Requirements

7.2 ATP Payload — Request Format

7.3 ATP Payload — Response Format

8. Core Patterns

8.1 Basic Task Execution

8.2 Task Delegation and Inline Verification

8.3 Challenge and Verification

8.4 Dependency Disclosure

9. Verification & Assessment

9.1 Multi-Dimensional Trust Model

9.2 Integrity Verification Steps

10. Authorization

11. ATP Exchange

11.1 Responsibilities

11.2 Operator Console

11.3 Blockchain Cataloging

12. API Specifications

12.1 Exchange REST API Endpoints

12.2 JSON-RPC 2.0 Challenge Interface (REQUIRED)

13. Security Considerations

13.1 API Key Compromise

13.2 Anti-Spam and Denial-of-Service

14. Implementation Requirements

14.1 Compliance Levels