chelof100/acp-framework-enAgent Control Protocol (ACP) — 공식 영어 사양. 자율 AI 에이전트를 위한 암호학적으로 검증 가능한 인증 아키텍처.
에이전트 행동에 대한 승인 제어.
에이전트가 시스템 상태를 변경하기 전에, ACP는 네 가지 질문에 답합니다: 이 에이전트는 누구인가? 무엇을 할 권한이 있는가? 이 행동이 정책을 준수하는가? 결과를 책임질 수 있는 기관으로 추적할 수 있는가?
암호화된 신원 · 범위 제한 능력 토큰 · 검증 가능한 위임 체인 · 실행 증명
https://agentcontrolprotocol.xyz
Agent Control Protocol: 에이전트 행동을 위한 승인 제어 Marcelo Fernandez (TraslaIA), 2026
DOI: 10.5281/zenodo.19672575 · arXiv: 2603.18829
ACP는 일곱 편의 논문으로 구성된 공식 에이전트 거버넌스 시리즈의 기초가 되는 출판물입니다. 각 논문은 거버넌스 스택의 개별 계층을 다룹니다.
| 논문 | 제목 | 저장소 | 상태 |
|---|---|---|---|
| Paper 0 | 원자적 결정 경계 (Atomic Decision Boundaries) | decision-boundary-model | Zenodo · arXiv:2604.17511 |
| Paper 1 | Agent Control Protocol (ACP) — 이 저장소 | acp-framework-en | Zenodo · arXiv:2603.18829 |
| Paper 2 | 승인에서 불변식까지 (IML) | iml-benchmark | Zenodo · arXiv:2604.17517 |
| Paper 3/4 | 환원 불가능한 거버넌스 구조 | governance-structure | Zenodo · arXiv: 게재 중 |
| Paper 5 | 재구성적 권한 모델 (RAM) | reconstructive-authority-model | Zenodo · arXiv:2604.22898 |
| Paper 6 | 재구성적 권한의 운영화 | operationalizing-ram | Zenodo · arXiv: 게재 중 |
| Paper 7 | 실행 격차 해소 (실증) | agent-governance-applied | Zenodo · arXiv: 게재 중 |
시리즈 논리: Paper 0은 언제 승인 가능성이 보장될 수 있는지를 증명합니다 → Paper 1 (ACP)이 프로토콜을 구축합니다 → Paper 2는 집행으로는 보이지 않는 표류를 감지합니다 → Paper 3/4는 올바른 집행이 공정한 할당을 의미하지 않음을 증명하고 4계층 아키텍처의 환원 불가능성을 확립합니다 → Paper 5 (RAM)는 운영적 폐쇄성을 제공합니다: 부분적 관찰 가능성 하에서 언제 실행할지 → Paper 6은 RAM을 런타임 복구 루프로 운영화합니다 → Paper 7은 실제 LangGraph 에이전트에서 전체 스택에 대한 최초의 실증적 검증을 제공합니다.
자율 에이전트는 실험 단계에서 프로덕션 단계로 이동하고 있습니다. 이미 API, 엔터프라이즈 시스템, 금융 인프라 및 다른 에이전트와 상호작용하고 있습니다.
에이전트가 조직 간에 행동할 때, 몇 가지 질문이 즉시 제기됩니다:
오늘날 대부분의 시스템은 이러한 질문에 신뢰성 있게 답할 수 없습니다.
ACP는 이 모든 질문에 답할 수 있는 인프라를 도입합니다.
자율 에이전트가 시스템과 상호작용하는 방식을 다루는 여러 이니셔티브가 있습니다. 대부분은 도구 접근 또는 통신에 초점을 맞춥니다. ACP는 권한, 실행 검증 및 기관 책임성에 초점을 맞춥니다.
ACP는 다른 계층을 다룹니다: 누가 행동을 승인했는지, 어떤 정책 하에서, 그리고 결과에 대해 누가 책임을 지는지.
ACP를 평가하는 엔지니어들은 종종 "OPA를 사용하면 안 되나요?"라고 묻습니다. 이러한 시스템은 상호 보완적이며 경쟁적이지 않습니다.
OPA는 ACP 준수 시스템 내부에서 정책 평가 엔진으로 사용될 수 있습니다. ACP는 OPA를 대체하지 않습니다 — OPA가 제공하지 않는 에이전트 신원 계층, 위임 체인 및 실행 증명을 추가합니다.
¹ ACP (Agent Control Protocol)는 동일한 약어를 공유하는 다른 이니셔티브와 관련이 없습니다.
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는 기관 경계를 넘어 작동합니다. 은행 A의 에이전트가 은행 B의 내부 인프라를 신뢰하지 않고도 은행 B에 의해 승인될 수 있습니다 — 오직 암호학적 증명만이 중요합니다.
---
## 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
| 조건 | 의미 |
|---|---|
ValidIdentity | 에이전트는 검증되고 서명된 신원을 가지고 있습니다 |
ValidCapability | 에이전트는 승인된 능력 토큰을 보유하고 있습니다 |
네 가지 조건이 동시에 충족되지 않으면 어떤 에이전트 동작도 실행되지 않습니다.
프로토콜 레이어는 모든 상호 작용 경계에서 이 불변 조건을 강제하기 위해 존재합니다.
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 │
└───────────────────────────┘
모든 에이전트 행동은 정의된 정책에 의해 승인되어야 합니다. 암시적 권한 없음. 주변 접근 없음.
실행은 승인된 명령과 정확히 일치해야 합니다. 승인된 것이 실행됩니다 — 그 이상은 없습니다.
모든 상호작용은 암호학적으로 검증 가능한 결과물을 생성합니다. 실행은 사후에 증명될 수 있으며, 어떤 단일 주체도 신뢰할 필요가 없습니다.
책임은 항상 식별 가능한 행위자에게 귀속됩니다. 위임 체인은 완전하며 기관 루트까지 추적 가능합니다.
독립적인 시스템들은 중앙 권위 없이 서로 검증할 수 있습니다. 신뢰는 검증 가능한 상호작용 이력을 통해 얻어지며, 가정되지 않습니다.
Identity, 능력, 정책 시행 및 결정적 실행.
동적 위험 평가 및 상호작용 신뢰 관리.
| 구성 요소 | 역할 |
|---|---|
| RISK | 결정적 위험 엔진 — 위험 점수 RS (0–100) |
| REV | 철회 프로토콜 — 엔드포인트 및 CRL |
| ITA | 기관 신뢰 앵커 — 상호작용별 신뢰 증명 |
모든 상호작용은 완전하고 암호학적으로 검증 가능한 기록을 남깁니다.
| 구성 요소 | 역할 |
|---|---|
| EXEC | 실행 토큰 — 일회용, 300초 유효 기간 |
| POLICY-CTX | 정책 컨텍스트 스냅샷 — 실행 시점의 서명된 정책 상태 |
| PROVENANCE | 권한 출처 — 위임 체인의 사후 증명 |
장기적인 책임성 및 기관 감독.
| 구성 요소 | 역할 |
|---|---|
| GOV-EVENTS | 거버넌스 이벤트 스트림 — 기관 추적 |
| REP |
독립적인 기관 간 상호 운용성.
| 구성 요소 | 역할 |
|---|---|
| ACP-D | 탈중앙화 ACP — 교차 기관 연합, BFT 쿼럼 |
사양별 현재 활성 버전. 이 테이블은 "구현할 버전"에 대한 권위 있는 참조입니다.
¹ ACP-SIGN-1.0은 Ed25519 베이스라인으로 계속 활성 상태입니다. ACP-SIGN-2.0은 포스트퀀텀 확장(ML-DSA-65)을 추가합니다. 둘 다 Dilithium이 프로덕션에 배포될 때까지 유효합니다.
대체된 버전은 archive/specs/에 보관되어 있습니다.
구현체는 L1부터 시작하여 점진적으로 ACP를 채택할 수 있습니다.
레벨별 전체 규범 요구 사항:
→ 규범 적합성 정의: spec/governance/ACP-CONF-1.2.md
A=(ID,C,P,D,L,S)acp:cap:*F_anom + 쿨다운PatternKey(agentID, cap, res)로 키 지정, 교차 컨텍스트 상태 혼합 제거0.6·ITS + 0.4·ERSacp-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
[](https://github.com/lunasec-io/lunasec/actions) [](https://goreportcard.com/report/github.com/anchore/grype) [](https://hub.docker.com/u/anchore/grype) [](https://t.me/grype_anchore) [](https://discord.gg/D5CgRwSR)```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
| 프로토콜 | 초점 | 범위 경계 |
|---|
| MCP (Model Context Protocol) | LLM을 위한 도구 접근 | 권한 검증, 정책 집행, 실행 감사 가능성 |
| A2A (Agent-to-Agent) | 에이전트 통신 패턴 | 기관 신뢰, 거버넌스, 책임 사슬 |
| OpenAI Agents SDK | 도구 오케스트레이션 | 교차 조직 권한, 출처, 책임 |
| Agent Client Protocol ¹ | 런타임 클라이언트/에이전트 통합 | 거버넌스, 위임 체인, 검증 가능한 실행 기록 |
| ACP (Agent Control Protocol) | 거버넌스 및 책임 인프라 | — |
| 시스템 | 기능 | ACP가 추가하는 것 |
|---|
| OPA (Open Policy Agent) | 데이터와 규칙으로부터 정책 평가 | 암호화된 에이전트 신원 + 위임 체인 + 실행 증명 |
| AWS IAM / Azure RBAC | 클라우드 리소스에 대한 정적 권한 모델 | 검증 가능한 체인 + 원장을 통한 동적 에이전트 간 위임 |
| OAuth 2.0 + OIDC | 토큰을 통한 사용자 및 서비스 인가 | 비확장성 + 기관 책임을 포함한 다중 홉 에이전트 위임 |
| SPIFFE / SPIRE | 암호화된 워크로드 신원 | ACP는 워크로드 신원 위에 능력 범위 제한 + 거버넌스를 추가합니다 |
| ACP | 에이전트 행동에 대한 승인 제어 | — |
ValidDelegationChain |
| 모든 위임 단계는 기관 루트까지 추적 가능합니다 |
AcceptableRisk | 위험 점수가 기관 정책 임계값 내에 있습니다 |
| 구성 요소 | 역할 |
|---|
| SIGN | 암호화 서명 — 모든 프로토콜 객체의 기초 |
| AGENT | 공식 에이전트 ID 사양 A=(ID,C,P,D,L,S) |
| CT | Capability Token — 구조, 발급 및 검증 |
| CAP-REG | 표준 능력 레지스트리 acp:cap:* |
| HP | 핸드셰이크 프로토콜 — 능력 보유의 암호학적 증명 |
| DCMA | 다중 홉 위임 — 비확대 및 전이적 철회 |
| MESSAGES | 와이어 형식 — 5가지 정규화된 메시지 유형 |
| LEDGER | 감사 원장 — 추가 전용, 해시 체인 |
평판 확장 — 복합 점수 0.6·ITS + 0.4·ERS |
| LIA | 책임 추적성 — 귀속 책임 체인 |
| HIST | 이력 쿼리 API — 감사된 실행 이력 |
| 사양 | 활성 버전 | 레벨 |
|---|
| ACP-SIGN | 2.0 ¹ | L1 |
| ACP-AGENT | 1.0 | L1 |
| ACP-CT | 1.0 | L1 |
| ACP-CAP-REG | 1.0 | L1 |
| ACP-HP | 1.0 | L1 |
| ACP-DCMA | 1.0 | L1 |
| ACP-MESSAGES | 1.0 | L1 |
| ACP-RISK | 3.0 | L2 |
| ACP-REV | 1.0 | L2 |
| ACP-ITA | 1.1 | L2/L4 |
| ACP-API | 1.0 | L3 |
| ACP-EXEC | 1.0 | L3 |
| ACP-LEDGER | 1.3 | L3 |
| ACP-PROVENANCE | 1.0 | L3 |
| ACP-POLICY-CTX | 1.0 | L3 |
| ACP-PSN | 1.0 | L3 |
| ACP-PAY | 1.0 | L4 |
| ACP-REP | 1.2 | L4 |
| ACP-GOV-EVENTS | 1.0 | L4 |
| ACP-LIA | 1.0 | L4 |
| ACP-HIST | 1.0 | L4 |
| ACP-NOTIFY | 1.0 | L4 |
| ACP-DISC | 1.0 | L4 |
| ACP-BULK | 1.0 | L4 |
| ACP-CROSS-ORG | 1.0 | L4 |
| ACP-REP-PORTABILITY | 1.1 | L4 |
| ACP-CONF | 1.2 | — |
| 레벨 | 이름 | 제공 사항 |
|---|
| L1 | 코어 | Identity, 능력 토큰 및 실행 |
| L2 | 보안 | 위험 점수화, 철회 및 신뢰 앵커 |
| L3 | 검증 가능한 실행 | 실행 토큰, 원장 및 출처 |
| L4 | 거버넌스 | 평판, 이력 및 책임 |
| L5 | 연합 | 탈중앙화 ACP 네트워크 |
| 레벨 | 필수 사양 |
|---|
| L1 | SIGN · AGENT · CT · CAP-REG · HP · DCMA · MESSAGES |
| L2 | L1 + RISK · REV · ITA-1.0 |
| L3 | L2 + API · EXEC · LEDGER · PROVENANCE · POLICY-CTX · PSN |
| L4 | L3 + PAY · REP-1.2 · ITA-1.1 · GOV-EVENTS · LIA · HIST · NOTIFY · DISC · BULK · CROSS-ORG · REP-PORTABILITY |
| L5 | L4 + ACP-D · ITA-1.1 BFT 쿼럼 |
| 항목 | 상태 |
|---|
| ACP-CONF-1.2 | ✅ 완료 — 유일한 규범 적합성 소스 |
| ACP-LEDGER-1.3 | ✅ 완료 — 서명이 규범적으로 필수 |
OpenAPI 스펙 (openapi/acp-api-1.0.yaml) | ✅ 완료 — OpenAPI 3.1.0, 모든 ACP-API-1.0 엔드포인트 |
| 적합성 테스트 벡터 (CORE · DCMA · HP · LEDGER · EXEC · PROV · PCTX · REP · RISK-2.0) | ✅ 완료 — 73개 서명 + 65개 서명되지 않은 RISK-2.0 테스트 벡터 |
| 참조 구현 — 23개의 Go 패키지 (L1–L4) | ✅ 완료 — impl/go/pkg/가 모든 적합성 수준을 포함 |
pkg/psn 정책 스냅샷 | ✅ 완료 — 원자적 전환, 단일 ACTIVE 스냅샷 |
Python SDK — ACPAdmissionGuard + @acp_tool (LangChain) | ✅ 완료 — impl/python/ |
ACP-RISK-2.0 — F_anom + Cooldown + pkg/risk | ✅ 완료 — 결정론적, 서브-µs, 65개 벡터 |
ACP-RISK-3.0 — 컨텍스트 스코프 규칙 1 (pkg/risk/engine.go) | ✅ 완료 — v1.22 · CountPattern(ctxKey, 60s)가 CountRequests(agentID)를 대체 · 교차 컨텍스트 상태 혼합 제거 |
결제 에이전트 데모 (examples/payment-agent/) | ✅ 완료 — v1.16 |
| ACP-SIGN-2.0 — 양자 후 하이브리드 (Ed25519 + ML-DSA-65) | ✅ 완료 — 스펙 v1.16; 실제 ML-DSA-65 via cloudflare/circl pkg/sign2/ v1.20 |
ACR-1.0 시퀀스 준수 러너 (compliance/runner/) | ✅ 완료 — v1.17 · 라이브러리 + HTTP 모드 · 5/5 PASS |
시퀀스 테스트 벡터 (compliance/test-vectors/sequence/) | ✅ 완료 — v1.17 · 5개의 상태 저장 시나리오 |
TLA+ 기본 모델 (tla/ACP.tla) | ✅ 완료 — v1.17 · 3개의 불변 조건 · 위반 0 |
TLA+ 확장 모델 (tla/ACP_Extended.tla) | ✅ 완료 — v1.28 · 11개의 불변 조건 + 4개의 시간 속성 · 단일 에이전트: 5,684,342 상태 · 두 에이전트 LB=11: 4,294,930,695 고유 상태 · 위반 0 |
적대적 평가 (compliance/adversarial/) | ✅ 완료 — v1.29 · 14개 실험 · 실제 벤치마크 수치 (N=5회 실행, 평균±표준편차) |
Redis 파이프라이닝 (compliance/adversarial/redis_pipelined.go) | ✅ 완료 — v1.20 · RTT 2회/요청 · ~1.8배 속도 향상 |
ML-DSA-65 벤치마크 (pkg/sign2/sign2_bench_test.go) | ✅ 완료 — v1.20 · Ed25519 서명 ~25 µs / 검증 ~56 µs · ML-DSA-65 서명 ~100–130 µs / 검증 ~81 µs |
NullQuerier + StatelessEngine (pkg/risk/null_querier.go, stateless_engine.go) | ✅ 완료 — v1.21 · 상태 비저장/상태 저장 비교를 위한 제로 상태 LedgerQuerier 기준 |
상태 비저장 vs. 상태 저장 실험 (Exp 6, pkg/risk/stateless_comparison_test.go) | ✅ 완료 — v1.21 · 500 요청 · 상태 비저장 500/500 vs ACP 2/500 (0.4%) · 탐지 지연 시간 11개 행동 |
상태 혼합 취약점 테스트 (Exp 7, pkg/risk/statemixing_test.go) | ✅ 완료 — v1.21 · 교차 컨텍스트 규칙 1 오염 · RS +20 · 11회 data.read 후 ESCALATED→DENIED |
| 상태 혼합 공격 분석 (논문 §State-Mixing Vulnerability) | ✅ 완료 — v1.21 · 형식적 특성화 · Exp 7 수치 · ACP-RISK-3.0 완화 경로 |
상태 혼합 수정 (Exp 8, pkg/risk/statemixing_fix_test.go) | ✅ 완료 — v1.22 · RISK-3.0 · 3개 시나리오 · 깨끗한 RS=50 ESCALATED · 오염된 RS=50 ESCALATED · 동일 컨텍스트 버스트 RS=85 DENIED |
| 논문 v1.23 — 스프린트 수정 | ✅ 완료 — v1.23 · §RISK-3.0 in §기술 메커니즘 · 반사실적 논제 · 767--921 ns 통합 · Exp 3b→Exp 4 재번호 · Exp 3 N=5 · 모든 7개 교차 검증 수정 |
편차 붕괴 (Exp 9, compliance/adversarial/exp_deviation_collapse.go) | ✅ 완료 — v1.23 · 3단계: 기준 BAR=0.70 → 붕괴 BAR=0.00 → 반사실적 BAR=1.00 |
| D단계 드리프트 시뮬레이션 (Exp 9 확장) | ✅ 완료 — v1.25 · 5개 배치 × 20개 케이스 · 0%→80% 살균 · ΔBAR 조기 경보가 배치 2에서 발동 (붕괴보다 3개 배치 먼저) |
| ITA 신뢰 모델 (논문 §Trust Model and Failure Modes) | ✅ 완료 — v1.20 · 부트스트랩 / 손상 창 / 철회 권한 — 반형식적 주장 |
TypeScript SDK (impl/typescript/) | ✅ 완료 — v1.4.0 · 의존성 없음 · 68개 테스트 |
Rust SDK (impl/rust/) | ✅ 완료 — v1.4.0 · ed25519-dalek v2 · 43개 테스트 |
pkg/barmonitor — BAR-Monitor with ΔBAR 경향 탐지 (impl/go/pkg/barmonitor/) | ✅ 완료 — v1.24 · 18개 테스트 · AlertThreshold + AlertTrend (임계값보다 먼저 발동) · 스레드 안전 원형 버퍼 |
EvaluateCounterfactual API (impl/go/pkg/risk/counterfactual.go) | ✅ 완료 — v1.24 · 14개 테스트 · 3개 변이 팩토리 (구조적/행동적/시간적) · BAR(결과) · 실패-폐쇄 |
D단계 드리프트 시뮬레이션 (Exp 9) + computeTrend() 원형 버퍼 수정 | ✅ 완료 — v1.25 · ΔBAR 조기 경보가 임계값보다 먼저 · 시간적 순서 버그 수정 |
TLA+ FailureConditionPreservation + NoDegenerateAdmissibility (11개 불변 조건) | ✅ 완료 — v1.27 · 위반 0 · 4,294,930,695 고유 상태 (두 에이전트 LB=11, 10.5시간) |
POST /acp/v1/counterfactual HTTP 엔드포인트 (impl/go/cmd/acp-server/) | ✅ 완료 — v1.25 · 7개 통합 테스트 · HTTP를 통한 구조적 + 행동적 변이 |
| 형식적 적대자 모델 A=(K,S,B) + 실험 분류 (Exp 1–14) | ✅ 완료 — v1.29 · 블랙박스 / 공식 인지 / 전체 상태 · 모든 실험 매핑 |
| 임계값 민감도 분석 (Exp 11, 5개 구성 ±10pt) | ✅ 완료 — v1.26 · 모든 구성에서 오거부율 0.00 · BAR 단조 0.75→0.60 · T3 지역 최적 |
| 탐지 보장 — 명제 + 이항 P(탐지) | ✅ 완료 — v1.26 · W=40 τ=0.10 · p₁=0.00에서 P=1.00 · p₁=0.05에서 P=0.95 |
| AgentSpec 기능 비교 (5개 차원) | ✅ 완료 — v1.26 · 구성 가능, 경쟁적 아님 · 거버넌스 붕괴 탐지 차별화 요소 |
Exp 12: 다중 도구 IPI 승인 제어 (compliance/adversarial/exp_agent_multitool.go) | ✅ 완료 — v1.27 · 4개 도구 · 3단계 · BAR A=0.30/B=1.00/C=0.30 · 상태 저장 F_anom 24시간 지속 |
실제 LLM IPI 데모 (demos/ollama-agent/agent_demo.py) | ✅ 완료 — v1.27 · DeepSeek-R1:8b · 5턴 · IPI 차단 · 쿨다운 활성화 |
| 오거부율 분석 (§False-Denial Rate Analysis) | ✅ 완료 — v1.27 · 깨끗한 상태 0.00 (Exp 11) · 공격 후 저위험 0.00 (Exp 12 C단계) |
| 배포 성숙도 모델 (Tier 1/2/3) + PolicyConfig 프로파일 (낮음/중간/높음/심각) | ✅ 완료 — v1.27 · 프로파일별 BAR 기준 · RISK-2.0→RISK-3.0 마이그레이션 가이드 |
Exp 13: 제한된 조정 창 (compliance/adversarial/exp_coordination_window.go) | ✅ 완료 — v1.28 · CW=2N 정확한 선형성 · 평가 후 변이 의미론 · 에이전트당 k₀=2 · O(N) 경계 |
| LLM 에이전트 통합 하위 섹션을 §기술 메커니즘으로 이동 | ✅ 완료 — v1.28 · §결정론적 위험 평가 이후 · IPI 프롬프트 필터와 구성 가능 |
Exp 14: OPA vs ACP 기능 비교 (compliance/adversarial/exp_opa_benchmark.go) | ✅ 완료 — v1.29 · 3개 시나리오 · 상태 비저장 엔진은 외부 상태 없이 빈도/쿨다운을 강제할 수 없음 · ACP는 기본적으로 강제 · ~852 ns/op ACP vs ~16,000 ns/op OPA |
| §관련 연구 — 형식적 검증 및 런타임 강제 (확장됨) | ✅ 완료 — v1.29 · OPA 표현성 경계 · Schneider 보안 자동장치 정렬 · Exp 14 교차 참조 |
거버넌스 시리즈 통합: 논문 3–4가 §15에서 인용; fernandez2026comp bib 항목 | ✅ 완료 — v1.30 |
| v1.x | 코어 프로토콜 및 참조 구현 — 활성 |
| v2.0 | 분산 ACP (ACP-D) — 설계 중 |
| 미래 | ZK 검증, 분산 거버넌스 |