ACP — Agent Control Protocol

Zugangskontrolle für Agentenaktionen.

Bevor ein Agent den Systemzustand verändert, beantwortet ACP vier Fragen: Wer ist dieser Agent? Wozu ist er berechtigt? Ist diese Aktion richtlinienkonform? Kann das Ergebnis einer verantwortlichen Institution zugeordnet werden?

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

Offizielle Website

https://agentcontrolprotocol.xyz

Paper

Agent Control Protocol: Admission Control for Agent Actions Marcelo Fernandez (TraslaIA), 2026

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

Forschungsreihe

ACP ist die veröffentlichte Grundlage einer siebenteiligen Paper-Serie zur formalen Agenten-Governance. Jedes Paper befasst sich mit einer eigenen Ebene des Governance-Stacks.

Serienlogik: Paper 0 beweist, wann Zulässigkeit garantiert werden kann → Paper 1 (ACP) baut das Protokoll → Paper 2 erkennt Drift, der für die Durchsetzung unsichtbar ist → Paper 3/4 beweist, dass korrekte Durchsetzung ≠ faire Zuteilung ist, und etabliert die Irreduzibilität der vierschichtigen Architektur → Paper 5 (RAM) bietet operative Schließung: wann unter partieller Beobachtbarkeit ausgeführt werden soll → Paper 6 operationalisiert RAM als eine Laufzeit-Wiederherstellungsschleife → Paper 7 liefert die erste empirische Validierung des gesamten Stacks auf echten LangGraph-Agenten.

Warum es ACP gibt

Autonome Agenten bewegen sich von der Experimentierphase in die Produktion. Sie interagieren bereits mit APIs, Unternehmenssystemen, Finanzinfrastruktur und anderen Agenten.

Wenn einer organisationsübergreifend handelt, ergeben sich sofort mehrere Fragen:

• Wer hat den Agenten autorisiert zu handeln?
• Welche Fähigkeiten hat der Agent tatsächlich?
• Welche Richtlinie erlaubte die Aktion?
• Was genau wurde ausgeführt?
• Kann diese Ausführung später verifiziert werden?
• Kann die vollständige Interaktionshistorie rekonstruiert werden?

Heutzutage können die meisten Systeme diese Fragen nicht zuverlässig beantworten.

ACP führt die Infrastruktur ein, um alle zu beantworten.

ACP im Vergleich zu verwandten Protokollen

Mehrere Initiativen befassen sich damit, wie autonome Agenten mit Systemen interagieren. Die meisten konzentrieren sich auf Werkzeugzugriff oder Kommunikation. ACP konzentriert sich auf Autorität, Ausführungsverifikation und institutionelle Rechenschaftspflicht.

ACP adressiert eine andere Ebene: wer die Aktion autorisiert hat, unter welcher Richtlinie und wer für das Ergebnis verantwortlich ist.

ACP vs. Richtlinien- und Authentifizierungssysteme

Ingenieure, die ACP evaluieren, fragen oft: "Warum nicht OPA verwenden?" Diese Systeme sind komplementär, nicht konkurrierend.

OPA kann als Richtlinienbewertungsmaschine innerhalb eines ACP-konformen Systems verwendet werden. ACP ersetzt OPA nicht — es fügt die Agentenidentitätsschicht, die Delegationskette und den Ausführungsnachweis hinzu, die OPA nicht bietet.

¹ ACP (Agent Control Protocol) ist nicht verwandt mit anderen Initiativen, die dasselbe Akronym teilen.

ACP als Zugangskontrolle

Kubernetes verwendet einen Admission Controller, um API-Anfragen abzufangen, bevor sie den Cluster erreichen — Richtlinien auswerten, Kontingente durchsetzen, nicht konforme Operationen ablehnen. ACP wendet dasselbe Muster auf Agentenaktionen an.``` 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

Der Unterschied zu Kubernetes: ACP arbeitet über institutionelle Grenzen hinweg. Ein Agent von Bank A kann von Bank B zugelassen werden, ohne dass Bank B der internen Infrastruktur von Bank A vertrauen muss — nur der kryptografische Nachweis zählt.

---

## Wie ACP funktioniert

ACP behandelt Agenteninteraktionen als **gesteuerte Vorgänge**, nicht als einfache Anfragen.

Jede Interaktion durchläuft sechs strukturierte Phasen:

1. **Identitätsprüfung** — bestätigen, wer der Agent ist (`ACP-AGENT-1.0`, `ACP-HP-1.0`)
2. **Fähigkeitsvalidierung** — bestätigen, wozu der Agent berechtigt ist (`ACP-CT-1.0`, `ACP-DCMA-1.0`)
3. **Richtlinienautorisierung** — bestätigen, dass die Aktion gemäß der aktuellen Richtlinie zulässig ist (`ACP-RISK-3.0`, `ACP-PSN-1.0`)
4. **Deterministische Ausführung** — genau das ausführen, was autorisiert wurde, nicht mehr (`ACP-EXEC-1.0`)
5. **Überprüfbare Aufzeichnung** — kryptografischen Nachweis des Geschehenen erzeugen (`ACP-LEDGER-1.3`, `ACP-PROVENANCE-1.0`)
6. **Vertrauensaktualisierung** — Reputations- und Bestätigungsstatus basierend auf der Interaktion aktualisieren (`ACP-REP-1.2`, `ACP-LIA-1.0`)

Dies ermöglicht es, Interaktionen organisationsübergreifend nachvollziehbar, prüfbar und zuordenbar zu machen.

---

## Konstitutionelle Invariante

Die ACP-Ausführung wird von einer einzigen architektonischen Invariante bestimmt.```
Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

| Bedingung | Bedeutung | |---|---|---| | ValidIdentity | Der Agent verfügt über eine verifizierte, signierte Identität | | ValidCapability | Der Agent besitzt einen autorisierten Capability-Token | | ValidDelegationChain | Jeder Delegationsschritt ist bis zu einer institutionellen Wurzel zurückverfolgbar | | AcceptableRisk | Der Risikowert liegt innerhalb der institutionellen Richtlinien |

Keine Agentenaktion wird ausgeführt, es sei denn, alle vier Bedingungen sind gleichzeitig erfüllt.

Die Protokollschichten existieren, um diese Invariante an jeder Interaktionsgrenze durchzusetzen.

Protokollarchitektur

ACP ist in fünf Protokollschichten organisiert. Jede Schicht baut auf der vorherigen auf und fügt eine eigene Governance-Fähigkeit hinzu.``` 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 │ └──────────────────────────────────────────────────────────────────┘

→ **Neu bei ACP? Hier starten:** [docs/admission-flow.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/docs/admission-flow.md) — die vollständige Schritt-für-Schritt-Anleitung zur Zulassungsprüfung

→ Formales Domänenmodell und Abhängigkeitsgraph: [ARCHITECTURE.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/ARCHITECTURE.md)

---

## Institutionsübergreifende Interaktion

ACP ist für Interaktionen zwischen unabhängigen Systemen konzipiert.
Jeder Schritt erzeugt ein überprüfbares Artefakt, das Teil des dauerhaften Interaktionsprotokolls wird.```
      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        │
                                          └───────────────────────────┘

Entwurfsprinzipien

Explizite Autorität

Jede Handlung eines Agenten muss durch eine definierte Richtlinie autorisiert sein. Keine impliziten Berechtigungen. Kein impliziter Umgebungszugriff.

Deterministische Ausführung

Die Ausführung muss exakt mit dem autorisierten Befehl übereinstimmen. Was autorisiert wurde, wird ausgeführt – nichts weiter.

Überprüfbare Historie

Jede Interaktion erzeugt kryptografisch überprüfbare Artefakte. Die Ausführung kann im Nachhinein nachgewiesen werden, ohne dass einer einzelnen Partei vertraut werden muss.

Institutionelle Verantwortlichkeit

Verantwortung ist stets einem identifizierbaren Akteur zuzuordnen. Delegationsketten sind vollständig und auf eine institutionelle Wurzel zurückführbar.

Föderiertes Vertrauen

Unabhängige Systeme können sich gegenseitig ohne eine zentrale Autorität überprüfen. Vertrauen wird durch überprüfbare Interaktionshistorie verdient, nicht vorausgesetzt.

Protokollkomponenten

L1 · Kernausführung

Identität, Fähigkeiten, Richtliniendurchsetzung und deterministische Ausführung.

L2 · Vertrauensschicht

Dynamische Risikobewertung und Interaktionsvertrauensmanagement.

L3 · Überprüfbare Ausführung

Jede Interaktion hinterlässt eine vollständige, kryptografisch überprüfbare Aufzeichnung.

L4 · Governance

Langfristige Verantwortlichkeit und institutionelle Aufsicht.

L5 · Föderation

Interoperabilität über unabhängige Institutionen hinweg.

Aktive Spezifikationsversionen

Aktuelle aktive Version pro Spezifikation. Diese Tabelle ist die maßgebliche Referenz für „welche Version implementiert werden soll".

¹ ACP-SIGN-1.0 bleibt als Ed25519-Basislinie aktiv. ACP-SIGN-2.0 fügt die Post-Quanten-Erweiterung (ML-DSA-65) hinzu. Beide sind in Kraft, bis Dilithium in der Produktion eingesetzt wird.

Veraltete Versionen sind in archive/specs/ archiviert.

Konformitätsstufen

Implementierungen können ACP schrittweise übernehmen, beginnend mit L1.

Vollständige normative Anforderungen pro Stufe:

→ Normative Konformitätsdefinition: spec/governance/ACP-CONF-1.2.md

Spezifikationen

L1 · Kernausführung

• ACP-SIGN-1.0 — kryptografische Signierung, Ed25519-Basislinie
• ACP-SIGN-2.0 — Post-Quanten-Hybrid-Signierung (Ed25519 + ML-DSA-65)
• ACP-AGENT-1.0 — formale Agentenidentität A=(ID,C,P,D,L,S)
• ACP-CT-1.0 — Capability-Token-Struktur, Ausstellung und Verifizierung
• ACP-CAP-REG-1.0 — kanonische Capability-Registry acp:cap:*
• ACP-HP-1.0 — Handshake-Protokoll, kryptografischer Nachweis des Besitzes einer Fähigkeit
• ACP-DCMA-1.0 — Multi-Hop-Delegation, Nicht-Eskalation und transitive Widerrufung
• ACP-MESSAGES-1.0 — Drahtformat, 5 normalisierte Nachrichtentypen

L2 · Vertrauensschicht

• ACP-RISK-2.0 — deterministische Risikoengine, Risikowert RS (0–100), F_anom + Abkühlung
• ACP-RISK-3.0 — kontextbezogene Anomaliedurchsetzung; Regel 1 wird durch PatternKey(agentID, cap, res) geschlüsselt, beseitigt kontextübergreifende Zustandsvermischung
• ACP-REV-1.0 — Widerrufsprotokoll, Endpunkt und CRL
• ACP-ITA-1.0 — Institutioneller Vertrauensanker, zentralisiertes Modell
• ACP-ITA-1.1 — Vertrauensanker-Governance, verteiltes BFT-Modell

L3 · Überprüfbare Ausführung

• ACP-EXEC-1.0 — Ausführungstoken, einmalig, 300s Gültigkeit
• ACP-POLICY-CTX-1.0 — signierter Richtlinienstatus zum Zeitpunkt der Ausführung
• ACP-PROVENANCE-1.0 — retrospektiver Nachweis der Delegationskette bei Ausführung
• ACP-LEDGER-1.3 — Prüfungs-Ledger, nur anfügbar, hash-verkettet, obligatorische institutionelle Signatur
• ACP-PSN-1.0 — Prozess-Sitzungsknoten, Nachverfolgung von Ausführungssitzungen
• ACP-API-1.0 — HTTP-API, alle institutionellen Endpunkte

L4 · Governance

• ACP-GOV-EVENTS-1.0 — institutioneller Governance-Ereignisstrom
• ACP-REP-1.2 — Reputationserweiterung, zusammengesetzter Wert 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — zugeordnete Haftungskette
• ACP-HIST-1.0 — geprüfte Ausführungshistorie-Abfrage-API
• ACP-PAY-1.0 — überprüfbare finanzielle Capability-Erweiterung
• ACP-NOTIFY-1.0 — Ereignisse und Webhooks
• ACP-DISC-1.0 — Agentenregistrierung und -auflösung
• ACP-BULK-1.0 — Batch-Capability-Ausführung
• ACP-CROSS-ORG-1.0 — institutionsübergreifende Agenteninteraktionen

L5 · Föderation

• ACP-D-1.0 — dezentralisiertes ACP, institutionsübergreifende Föderation, BFT-Quorum

Governance

• ACP-CONF-1.2 — normative Konformitätsdefinition (aktuell)
• ACP-CHANGELOG — Versionshistorie

Repository-Struktur```

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

---

## Schnellstart```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

Gesundheitscheck:```bash curl http://localhost:8080/acp/v1/health

file_paths, URLs, package names, technical identifiers, CVE IDs, environment variable names.```json
{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Roadmap

Lizenz

Apache 2.0