Draft (v0.4) Standards Track Обновлено: Март 2026

Agent-to-Agent (A2A)
Accountability Protocol

Автор: TrustAgentAI Core Team

1. Аннотация (Abstract)

С ростом автономной экономики (Agentic Economy) возникает необходимость в детерминированном механизме подтверждения действий между независимыми ИИ-системами. Существующие протоколы (например, MCP) обеспечивают связность (Connectivity), но не предоставляют криптографической доказуемости (Non-repudiation).

Протокол A2A Accountability определяет стандартизированный метод двустороннего криптографического рукопожатия, жесткого связывания намерений (Intent Binding) с контекстом инструментов и потокового (streaming) ведения неизменяемого DAG-реестра.

2. Терминология

Agent A (Initiator)

ИИ-система, инициирующая запрос на выполнение высокоценного действия.

Agent B (Executor / Tool)

ИИ-система или MCP-инструмент, принимающий запрос.

Trust Proxy

Middleware-компонент, реализующий протокол и выступающий доверенным подписантом (Signer) от имени агента.

VC (Verifiable Credential)

Криптографически подписанный мандат (Policy), определяющий риск-бюджет агента.

3. Жизненный цикл транзакции (The Handshake)

Протокол состоит из трех обязательных фаз и одной опциональной (Ack) для двустороннего Non-repudiation:

Proposal (Intent Envelope)

Proxy A перехватывает вызов, канонизирует аргументы, добавляет привязку к MCP-схеме и сроку действия (TTL), подписывает пакет (Proxy-only или Dual-Sign) и отправляет его Proxy B.

Acceptance Receipt

Proxy B оценивает политики. Если проверка пройдена, он формирует policy_eval_hash, подписывает согласие на выполнение и возвращает квитанцию.

Execution Envelope & Ack

После выполнения задачи, Proxy B хеширует результат (output_hash), фиксирует статус и подписывает финальный конверт. Опционально: Proxy A возвращает Receipt Acknowledgement для завершения цикла доказательств.

4. Форматы данных (Data Envelopes)

Hash Target Rule (Критично) Хеши артефактов (например, intent_hash) вычисляются строго как SHA-256( JCS(Envelope WITHOUT "signatures" field) ), где JCS — JSON Canonicalization Scheme (RFC 8785). Это позволяет добавлять мультиподписи, не ломая базовый хэш конверта.

4.1. Intent Envelope

В массив signatures добавлены обязательные поля kid (для идентификации ключа) и signed_digest.

intent_envelope.json

{ "envelope_type": "IntentEnvelope",
  "spec_version": "0.4",
  "trace_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2026-03-10T10:15:30.123Z",
  "expires_at": "2026-03-10T10:16:00.000Z",
  "initiator": { "did": "did:workload:payment-agent-01",
    "vc_ref": "urn:credential:treasury-auth-099" },
  "target": { "did": "did:workload:stripe-mcp-server",
    "mcp_deployment_id": "stripe-prod-cluster-1", // Устраняет эфемеридность сессии "tool_name": "execute_wire_transfer",
    "tool_schema_hash": "e3b0...285", // Защита от подмены API-контракта "mcp_session_id": "sess_98765abc" },
  "payload": { "args_hash": "a5b9...9f1",
    "nonce": "8f42d9a1" },
  "signatures": [ { "role": "proxy",
      "kid": "did:workload:proxy-A#key-1", // Обязательно для верификатора "agent_attestation_ref": "urn:attestation:sgx:a1b2...",
      "alg": "EdDSA",
      "signed_digest": "c4d3...e21", // Хэш, от которого берется подпись "value": "eyJhbGciOiJFZERTQSJ9..." } ] }

4.2. Acceptance Receipt

{ "envelope_type": "AcceptanceReceipt",
  "spec_version": "0.4",
  "trace_id": "urn:uuid:550e...",
  "timestamp": "2026-03-10T10:15:30.300Z",
  "expires_at": "2026-03-10T10:16:00.000Z",
  "intent_hash": "c4d3...e21",
  "policy_eval_hash": "b7f8...1a2", 
  "decision": "ACCEPTED",
  "signatures": [ {...} ] }

4.3. Execution Envelope

{ "envelope_type": "ExecutionEnvelope",
  "spec_version": "0.4",
  "trace_id": "urn:uuid:550e...",
  "timestamp": "2026-03-10T10:15:31.050Z",
  "intent_hash": "c4d3...e21", // Binding "acceptance_hash": "8f42...1a2",
  "status": "COMPLETED",
  "result": { "output_hash": "9f86...d46" },
  "signatures": [ {...} ] }

5. Правила валидации (Must Enforce)

Управление временем и Clock Skew:

Time Model: expires_at MUST be strictly greater than timestamp. Окно жизни пакета (TTL) вычисляется как expires_at - timestamp.
Clock Skew Rule: Verifier MUST reject if current_time > expires_at + skew_tolerance. RECOMMENDED skew_tolerance = 5 seconds.

Anti-Replay (Belt and Suspenders):

Proxy A (Sender) MUST ensure nonce uniqueness per (initiator.did, nonce) before signing and emitting the Intent.
Proxy B (Receiver) MUST enforce nonce uniqueness per (initiator.did, nonce) until the absolute expiration time expires_at + skew_tolerance is reached.

Dual-Signature Policy:

Для High-Value действий (управление деньгами, IAM) протокол SHOULD требовать Dual-Signature (countersigning): отдельную подпись самого Агента + валидирующую подпись Прокси в массиве signatures[]. Для Low-Trust сред Proxy-only подпись допустима только при наличии agent_attestation_ref.

6. Streaming Ledger (DAG Architecture)

Для поддержки ветвления логики и мультиагентных делегирований, протокол использует Directed Acyclic Graph (DAG).

Merkle Leaf Definition: Базовые узлы (Leaves) для построения дерева Меркла — это значения entry_hash, которые вычисляются строго как:
SHA-256( JCS(LedgerEntry WITHOUT "entry_hash") )

{ "entry_id": 104593,
  "trace_id": "urn:uuid:550e...",
  "event_type": "EXECUTION_RECORD",
  "prev_entry_hashes": [ "f8a...1b9", // Intent entry "2c4...e81" // Acceptance entry ],
  "artifact": { /* ExecutionEnvelope */ },
  "entry_hash": "7a2...8c4" }

7. Конфиденциальность (Privacy Guidance)

Execution Ledger публично фиксирует факт транзакции, но не должен раскрывать коммерческую тайну (например, PII или API-ключи, передаваемые в MCP-инструмент).

Протокол запрещает хранить открытые JSON-аргументы внутри конвертов намерения и исполнения. Разрешено хранить только args_hash и output_hash. В случае спора, стороны обязаны предоставить оригинальный JSON (Off-chain), который арбитр прогонит через SHA-256 для сверки с хешем в реестре.

8. Разрешение споров (Dispute Pack)

Стандартный Dispute Pack предоставляет независимые криптографические доказательства (cryptographic evidence of origin), достаточные для арбитража.

Связанный DAG из JSON-артефактов (Intent, Acceptance, Execution, Ack).
inclusion_proof: Доказательство пути Меркла (Merkle Path) от записи до корня.
anchor_ref: Выписка из L2-блокчейна (transaction hash).

При условии согласованного управления ключами (Key Custody), этот пакет поддерживает претензии о неотрекаемости (Non-repudiation claims). Если Merkle Proof сходится с блокчейном, ни одна из сторон не могла изменить логи задним числом.