ACP — Протокол управления агентами

Контроль допуска для действий агентов.

Прежде чем любой агент изменит состояние системы, ACP отвечает на четыре вопроса: Кто этот агент? Что ему разрешено делать? Соответствует ли действие политике? Можно ли отследить результат до ответственного учреждения?

Cryptographic identity · Scoped capability tokens · Verifiable delegation chains · Execution proof

Официальный сайт

https://agentcontrolprotocol.xyz

Статья

Протокол управления агентами: Контроль допуска для действий агентов Marcelo Fernandez (TraslaIA), 2026

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

Серия исследований

ACP является опубликованной основой серии из семи статей по формальному управлению агентами. Каждая статья рассматривает отдельный уровень стека управления.

Логика серии: Статья 0 доказывает, когда допустимость может быть гарантирована → Статья 1 (ACP) строит протокол → Статья 2 обнаруживает дрейф, невидимый для принуждения → Статья 3/4 доказывает, что правильное принуждение ≠ справедливое распределение, и устанавливает несводимость четырехуровневой архитектуры → Статья 5 (RAM) обеспечивает операционное замыкание: когда выполнять при частичной наблюдаемости → Статья 6 внедряет RAM как цикл восстановления во время выполнения → Статья 7 предоставляет первую эмпирическую проверку полного стека на реальных агентах LangGraph.

Зачем нужен ACP

Автономные агенты переходят от экспериментов к производству. Они уже взаимодействуют с API, корпоративными системами, финансовой инфраструктурой и другими агентами.

Когда один агент действует в разных организациях, сразу возникает несколько вопросов:

• Кто уполномочил агента действовать?
• Какими возможностями на самом деле обладает агент?
• Какая политика разрешила действие?
• Что именно было выполнено?
• Можно ли проверить выполнение позже?
• Можно ли восстановить полную историю взаимодействий?

Сегодня большинство систем не могут надежно ответить на эти вопросы.

ACP представляет инфраструктуру для ответа на все из них.

ACP и связанные протоколы

Несколько инициатив решают вопрос взаимодействия автономных агентов с системами. Большинство сосредоточено на доступе к инструментам или коммуникации. ACP сосредоточен на полномочиях, проверке выполнения и институциональной подотчетности.

ACP затрагивает другой уровень: кто уполномочил действие, по какой политике и кто несет ответственность за результат.

ACP и системы политик и аутентификации

Инженеры, оценивающие ACP, часто спрашивают: «почему не использовать OPA?» Эти системы дополняющие, а не конкурирующие.

OPA может использоваться как механизм оценки политик внутри системы, совместимой с ACP. ACP не заменяет OPA — он добавляет уровень идентичности агента, цепочку делегирования и доказательство выполнения, которые OPA не предоставляет.

¹ ACP (Agent Control Protocol) не связан с другими инициативами, использующими ту же аббревиатуру.

ACP как контроль допуска

Kubernetes использует Admission Controller для перехвата API-запросов до того, как они достигнут кластера — оценивая политики, применяя квоты, отклоняя несоответствующие операции. ACP применяет тот же шаблон к действиям агентов.``` agent intent ↓ [1] Identity check → pkg/agent + pkg/hp (ACP-AGENT-1.0, ACP-HP-1.0) ↓ [2] Capability check → pkg/ct + pkg/dcma (ACP-CT-1.0, ACP-DCMA-1.0) ↓ [3] Policy check → pkg/risk + pkg/psn (ACP-RISK-3.0, ACP-PSN-1.0) ↓ [4] ADMIT / DENY / ESCALATE ↓ (if ADMIT) [5] Execution token → pkg/exec (ACP-EXEC-1.0) ↓ [6] Ledger record → pkg/ledger (ACP-LEDGER-1.3) ↓ system state mutation

Отличие от Kubernetes: ACP действует через институциональные границы. Агент из Банка А может быть принят Банком Б без того, чтобы Банк Б доверял внутренней инфраструктуре Банка А — значение имеет только криптографическое доказательство.

---

## Как работает ACP

ACP рассматривает взаимодействия агентов как **управляемые операции**, а не простые запросы.

Каждое взаимодействие проходит шесть структурированных этапов:

1. **Проверка личности** — подтверждение, кем является агент (`ACP-AGENT-1.0`, `ACP-HP-1.0`)
2. **Проверка возможностей** — подтверждение, на что агенту разрешено (`ACP-CT-1.0`, `ACP-DCMA-1.0`)
3. **Авторизация политики** — подтверждение, что действие разрешено текущей политикой (`ACP-RISK-3.0`, `ACP-PSN-1.0`)
4. **Детерминированное выполнение** — выполнение только того, что было авторизовано, ничего более (`ACP-EXEC-1.0`)
5. **Проверяемая запись** — создание криптографического доказательства произошедшего (`ACP-LEDGER-1.3`, `ACP-PROVENANCE-1.0`)
6. **Обновление доверия** — обновление репутации и состояния аттестации на основе взаимодействия (`ACP-REP-1.2`, `ACP-LIA-1.0`)

Это позволяет взаимодействиям стать отслеживаемыми, аудитируемыми и приписываемыми среди организаций.

---

## Конституционный инвариант

Выполнение ACP управляется единственным архитектурным инвариантом.```
Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

Никакое действие агента не выполняется, если все четыре условия не выполнены одновременно.

Уровни протокола существуют для обеспечения соблюдения этого инварианта на каждой границе взаимодействия.

Архитектура протокола

ACP организован в пяти уровнях протокола. Каждый уровень строится на предыдущем и добавляет отдельную возможность управления.``` ACP PROTOCOL ARCHITECTURE

         ┌──────────────────────────────────────┐
         │                ACTORS                │
         │       Humans · Systems · Agents      │
         └──────────────────────────────────────┘
                            │
                            ▼

==================================================================== L1 — CORE EXECUTION

┌──────────────────────────────────────────────────────────────────┐ │ IDENTITY & CAPABILITIES │ │ SIGN · AGENT · CT · CAP-REG │ │ │ │ Agent identity, credential verification and capability registry │ └──────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────┐ │ POLICY & AUTHORITY │ │ HP · DCMA │ │ │ │ Policy evaluation and authorization decision │ └──────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────┐ │ EXECUTION │ │ MESSAGES │ │ │ │ Deterministic command execution and interaction handling │ └──────────────────────────────────────────────────────────────────┘

==================================================================== L2 — TRUST LAYER

┌──────────────────────────────────────────────────────────────────┐ │ RISK MANAGEMENT │ │ RISK · REV │ │ │ │ Risk scoring and revocation control │ └──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐ │ INTERACTION TRUST │ │ ITA │ │ │ │ Trust attestations for interactions │ └──────────────────────────────────────────────────────────────────┘

==================================================================== L3 — VERIFIABLE EXECUTION

┌──────────────────────────────────────────────────────────────────┐ │ EXECUTION RECORD │ │ EXEC · POLICY-CTX │ │ │ │ Proof of execution and policy context snapshot │ └──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐ │ PROVENANCE │ │ PROVENANCE GRAPH │ │ │ │ Interaction lineage and cross-system event tracking │ └──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐ │ LEDGER │ │ │ │ Tamper-resistant storage for verifiable execution history │ └──────────────────────────────────────────────────────────────────┘

==================================================================== L4 — GOVERNANCE

┌──────────────────────────────────────────────────────────────────┐ │ GOVERNANCE EVENTS │ │ GOV-EVENTS │ │ │ │ Institutional governance tracking │ └──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐ │ REPUTATION & LIABILITY │ │ REP · LIA │ │ │ │ Reputation accumulation and liability attribution │ └──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐ │ HISTORICAL RECORD │ │ HIST │ │ │ │ Verifiable long-term interaction history │ └──────────────────────────────────────────────────────────────────┘

==================================================================== L5 — FEDERATION

┌──────────────────────────────────────────────────────────────────┐ │ DECENTRALIZED ACP │ │ ACP-D │ │ │ │ Cross-institution federation and verification │ └──────────────────────────────────────────────────────────────────┘

→ **Новичок в ACP? Начните здесь:** [docs/admission-flow.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/docs/admission-flow.md) — полное пошаговое руководство по проверке допуска

→ Формальная модель предметной области и граф зависимостей: [ARCHITECTURE.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/ARCHITECTURE.md)

---

## Межинституциональное взаимодействие

ACP разработан для взаимодействия между независимыми системами.
Каждый шаг создает проверяемый артефакт, который становится частью постоянной записи взаимодействия.```
      INSTITUTION A                               INSTITUTION B
┌─────────────────────────────┐           ┌─────────────────────────────┐
│                             │           │                             │
│           AGENT A           │           │           AGENT B           │
│                             │           │                             │
└──────────────┬──────────────┘           └──────────────┬──────────────┘
               │                                         │
               │  1  interaction request                 │
               └────────────────────────────────────────►│
                                                         ▼
                                          ┌───────────────────────────┐
                                          │       AUTHORITY (HP)      │
                                          │  policy evaluation        │
                                          │  capability validation    │
                                          │  risk / revocation check  │
                                          └─────────────┬─────────────┘
                                                        │  2  decision
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        EXECUTION          │
                                          │  deterministic action     │
                                          │  command execution        │
                                          └─────────────┬─────────────┘
                                                        │  3  execution record
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        PROVENANCE         │
                                          │  interaction lineage      │
                                          │  cross-org attribution    │
                                          └─────────────┬─────────────┘
                                                        │  4  verifiable record
                                                        ▼
                                          ┌───────────────────────────┐
                                          │          LEDGER           │
                                          │  execution hash           │
                                          │  policy context snapshot  │
                                          └─────────────┬─────────────┘
                                                        │  5  trust update
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        REPUTATION         │
                                          │  ITA attestation          │
                                          │  reputation update        │
                                          └───────────────────────────┘

Принципы проектирования

Явные полномочия

Каждое действие агента должно быть авторизовано определенной политикой. Никаких неявных разрешений. Никакого фонового доступа.

Детерминированное выполнение

Выполнение должно точно соответствовать авторизованной команде. Выполняется только то, что было авторизовано, — ничего более.

Проверяемая история

Каждое взаимодействие создает криптографически проверяемые артефакты. Выполнение может быть доказано постфактум, без доверия к какой-либо одной стороне.

Институциональная подотчетность

Ответственность всегда может быть возложена на идентифицируемое лицо. Цепочки делегирования полны и прослеживаются до институционального корня.

Федеративное доверие

Независимые системы могут проверять друг друга без центрального органа. Доверие достигается через проверяемую историю взаимодействий, а не предполагается.

Компоненты протокола

L1 · Базовое выполнение

Идентификация, возможности, обеспечение соблюдения политик и детерминированное выполнение.

L2 · Уровень доверия

Динамическая оценка рисков и управление доверием взаимодействий.

L3 · Проверяемое выполнение

Каждое взаимодействие оставляет полную криптографически проверяемую запись.

L4 · Управление

Долгосрочная подотчетность и институциональный надзор.

L5 · Федерация

Взаимодействие между независимыми институтами.

Активные версии спецификаций

Текущая активная версия для каждой спецификации. Эта таблица является авторитетным справочником «какую версию реализовать».

¹ ACP-SIGN-1.0 остается активной как базовая линия Ed25519. ACP-SIGN-2.0 добавляет постквантовое расширение (ML-DSA-65). Обе действуют до внедрения Dilithium в производство.

Устаревшие версии архивированы в archive/specs/.

Уровни соответствия

Реализации могут внедрять ACP поэтапно, начиная с L1.

Полные нормативные требования по уровням:

→ Нормативное определение соответствия: spec/governance/ACP-CONF-1.2.md

Спецификации

L1 · Базовое выполнение

• ACP-SIGN-1.0 — криптографическое подписывание, базовая линия Ed25519
• ACP-SIGN-2.0 — постквантовое гибридное подписывание (Ed25519 + ML-DSA-65)
• ACP-AGENT-1.0 — формальная идентичность агента A=(ID,C,P,D,L,S)
• ACP-CT-1.0 — структура токена возможностей, выпуск и проверка
• ACP-CAP-REG-1.0 — канонический реестр возможностей acp:cap:*
• ACP-HP-1.0 — протокол рукопожатия, криптографическое доказательство обладания возможностью
• ACP-DCMA-1.0 — многошаговое делегирование, без эскалации и транзитивный отзыв
• ACP-MESSAGES-1.0 — формат передачи, 5 нормализованных типов сообщений

L2 · Уровень доверия

• ACP-RISK-2.0 — детерминированный механизм риска, Оценка риска RS (0–100), F_anom + период охлаждения
• ACP-RISK-3.0 — контекстно-ориентированное применение аномалий; Правило 1 ключуется по PatternKey(agentID, cap, res), устраняет смешивание состояний между контекстами
• ACP-REV-1.0 — протокол отзыва, конечная точка и CRL
• ACP-ITA-1.0 — институциональный якорь доверия, централизованная модель
• ACP-ITA-1.1 — управление якорем доверия, распределенная модель BFT

L3 · Проверяемое выполнение

• ACP-EXEC-1.0 — Токены выполнения, одноразовые, срок действия 300 с
• ACP-POLICY-CTX-1.0 — подписанное состояние политики во время выполнения
• ACP-PROVENANCE-1.0 — ретроспективное доказательство цепочки делегирования во время выполнения
• ACP-LEDGER-1.3 — аудиторский реестр, только добавление, хэш-цепочка, обязательная институциональная подпись
• ACP-PSN-1.0 — узел процесса-сессии, отслеживание сеансов выполнения
• ACP-API-1.0 — HTTP API, все институциональные конечные точки

L4 · Управление

• ACP-GOV-EVENTS-1.0 — поток событий институционального управления
• ACP-REP-1.2 — расширение репутации, составной показатель 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — цепочка приписываемой ответственности
• ACP-HIST-1.0 — API запросов проверенной истории выполнения
• ACP-PAY-1.0 — расширение проверяемых финансовых возможностей
• ACP-NOTIFY-1.0 — события и вебхуки
• ACP-DISC-1.0 — реестр агентов и разрешение
• ACP-BULK-1.0 — пакетное выполнение возможностей
• ACP-CROSS-ORG-1.0 — межведомственные взаимодействия агентов

L5 · Федерация

• ACP-D-1.0 — децентрализованный ACP, межведомственная федерация, кворум BFT

Управление

• ACP-CONF-1.2 — нормативное определение соответствия (текущее)
• ACP-CHANGELOG — история версий

Структура репозитория```

acp-framework/ ├── spec/ │ ├── core/ ← L1: identity, capability, delegation │ ├── security/ ← L2: trust, risk, revocation │ ├── operations/ ← L3–L4: execution, ledger, governance │ ├── governance/ ← conformance, events, process │ └── decentralized/ ← L5: ACP-D ├── openapi/ │ └── acp-api-1.0.yaml ← OpenAPI 3.1.0 spec for all ACP-API-1.0 endpoints ├── compliance/ │ ├── ACP-TS-1.1.md ← test vector format specification │ ├── test-vectors/ ← single-shot conformance vectors (CORE · DCMA · HP · LEDGER · EXEC · RISK-2.0) │ │ └── sequence/ ← stateful sequence vectors (ACR-1.0, 5 scenarios) │ ├── adversarial/ ← adversarial evaluation (Exp 1–12: cooldown evasion, multi-agent, backend stress, token replay, deviation collapse, threshold sensitivity, multi-tool IPI) │ └── runner/ ← ACR-1.0 compliance runner (library mode + HTTP mode) ├── tla/ │ ├── ACP.tla ← base formal model — Safety · LedgerAppendOnly · RiskDeterminism (v1.17) │ ├── ACP.cfg ← TLC configuration for ACP.tla │ ├── ACP_Extended.tla ← extended model — F_anom · cooldown · liveness · 11 invariants + 4 temporal (v1.25) │ ├── ACP_Extended.cfg ← single-agent config — 5,684,342 states · 3,147,864 distinct · depth 15 · 0 violations │ └── ACP_Extended_2agents.cfg ← two-agent config — 4,294,930,695 distinct states · LEDGER_BOUND=11 · 11 invariants · 0 violations ├── archive/ │ └── specs/ ← superseded specification versions (historical reference) ├── impl/ │ └── go/ ← reference implementation ├── ARCHITECTURE.md ← formal domain model, dependency graph ├── CHANGELOG.md └── README.md

---

## Быстрый старт```bash
# Option 1: Go reference server
cd impl/go
docker compose up

# Option 6: ACR-1.0 sequence compliance runner — validate ACP-RISK-3.0 stateful behavior
cd compliance/runner
go run . --mode library --dir ../test-vectors/sequence --strict
# PASS 5/5 — SEQ-BENIGN-001 SEQ-BOUNDARY-001 SEQ-PRIVJUMP-001 SEQ-FANOM-RULE3-001 SEQ-COOLDOWN-001

# Option 5: Multi-org demo — Org-A issues signed policy+reputation, Org-B validates independently
cd examples/multi-org-demo
docker compose up
# Org-A: http://localhost:8081  |  Org-B: http://localhost:8082

# Option 2: Python SDK — core admission control pattern (no server required)
cd impl/python
pip install -e .
python examples/admission_control_demo.py

# Option 3: Python SDK — LangChain integration (@acp_tool decorator)
cd impl/python
pip install -e .
python examples/langchain_agent_demo.py

# Option 4: LangChain + real LLM agent
pip install langchain langchain-openai
export OPENAI_API_KEY=sk-...
python examples/langchain_agent_demo.py --with-llm

# Option 7: Real-LLM IPI demo (Ollama + DeepSeek-R1:8b) — ACP blocks IPI-induced fund_transfer
# Requires: ollama serve && ollama pull deepseek-r1:8b
cd demos/ollama-agent
python agent_demo.py
# ACP denies every IPI-induced fund_transfer (RS=80); cooldown activates after 3 denials

Проверка здоровья:```bash curl http://localhost:8080/acp/v1/health

"minestrike": {
      "custom": false,
      "credits": ["nephelai", "Synaptic"],
      "path": "/Pentest/MineStrike-master/packages/packages.json",
      "description": "Инструмент для подготовки шаблона сервера Minecraft для развертывания с помощью Terraform и Ansible",
      "url": "https://github.com/nephelai/MineStrike"
    },```json
{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Дорожная карта

Лицензия

Apache 2.0