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	Atomic Decision Boundaries	decision-boundary-model	Zenodo · arXiv:2604.17511
पेपर 1	Agent Control Protocol (ACP) — यह रेपो	acp-framework-en	Zenodo · arXiv:2603.18829
पेपर 2	From Admission to Invariants (IML)	iml-benchmark	Zenodo · arXiv:2604.17517
पेपर 3/4	Irreducible Governance Structure	governance-structure	Zenodo · arXiv: लंबित
पेपर 5	Reconstructive Authority Model (RAM)	reconstructive-authority-model	Zenodo · arXiv:2604.22898
पेपर 6	Operationalizing Reconstructive Authority	operationalizing-ram	Zenodo · arXiv: लंबित
पेपर 7	Closing the Execution Gap (Empirical)	agent-governance-applied	Zenodo · arXiv: लंबित

श्रृंखला तर्क: पेपर 0 साबित करता है कब प्रवेश की गारंटी दी जा सकती है → पेपर 1 (ACP) प्रोटोकॉल बनाता है → पेपर 2 प्रवर्तन के लिए अदृश्य बहाव का पता लगाता है → पेपर 3/4 साबित करता है कि सही प्रवर्तन ≠ निष्पक्ष आवंटन और चार-परत वास्तुकला की अपरिवर्तनीयता स्थापित करता है → पेपर 5 (RAM) संचालनात्मक समापन प्रदान करता है: आंशिक दृश्यता के तहत कब निष्पादित करना है → पेपर 6 RAM को रनटाइम रिकवरी लूप के रूप में संचालित करता है → पेपर 7 वास्तविक LangGraph एजेंटों पर पूर्ण स्टैक का पहला अनुभवजन्य सत्यापन प्रदान करता है।

ACP क्यों मौजूद है

स्वायत्त एजेंट प्रयोग से उत्पादन की ओर बढ़ रहे हैं। वे पहले से ही APIs, एंटरप्राइज सिस्टम, वित्तीय बुनियादी ढांचे और अन्य एजेंटों के साथ इंटरैक्ट करते हैं।

जब कोई एक संगठनों के पार कार्य करता है, तो कई प्रश्न तुरंत उठते हैं:

एजेंट को कार्य करने के लिए किसने अधिकृत किया?
एजेंट के पास वास्तव में क्या क्षमताएँ हैं?
किस नीति ने कार्रवाई की अनुमति दी?
वास्तव में क्या निष्पादित किया गया?
क्या उस निष्पादन को बाद में सत्यापित किया जा सकता है?
क्या पूर्ण इंटरैक्शन इतिहास का पुनर्निर्माण किया जा सकता है?

आज, अधिकांश सिस्टम इन प्रश्नों का विश्वसनीय रूप से उत्तर नहीं दे सकते।

ACP उन सभी का उत्तर देने के लिए बुनियादी ढाँचा प्रस्तुत करता है।

ACP बनाम संबंधित प्रोटोकॉल

कई पहलें यह संबोधित करती हैं कि स्वायत्त एजेंट सिस्टम के साथ कैसे इंटरैक्ट करते हैं। अधिकांश टूल एक्सेस या संचार पर ध्यान केंद्रित करते हैं। ACP प्राधिकरण, निष्पादन सत्यापन और संस्थागत जवाबदेही पर ध्यान केंद्रित करता है।

ACP एक अलग परत को संबोधित करता है: कार्रवाई को किसने अधिकृत किया, किस नीति के तहत, और परिणाम के लिए कौन जवाबदेह है।

ACP बनाम नीति और प्रमाणीकरण सिस्टम

ACP का मूल्यांकन करने वाले इंजीनियर अक्सर पूछते हैं: "OPA का उपयोग क्यों नहीं करते?" ये सिस्टम पूरक हैं, प्रतिस्पर्धी नहीं।

OPA को ACP-अनुपालक सिस्टम के अंदर नीति मूल्यांकन इंजन के रूप में उपयोग किया जा सकता है। ACP OPA को प्रतिस्थापित नहीं करता — यह एजेंट पहचान परत, प्रतिनिधिमंडल श्रृंखला और निष्पादन प्रमाण जोड़ता है जो OPA प्रदान नहीं करता।

¹ ACP (एजेंट नियंत्रण प्रोटोकॉल) उसी संक्षिप्त नाम को साझा करने वाली अन्य पहलों से असंबंधित है।

प्रवेश नियंत्रण के रूप में ACP

Kubernetes API अनुरोधों को क्लस्टर तक पहुँचने से पहले इंटरसेप्ट करने के लिए एडमिशन कंट्रोलर (Admission Controller) का उपयोग करता है — नीतियों का मूल्यांकन करना, कोटा लागू करना, गैर-अनुपालक संचालन को अस्वीकार करना। 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

कुबरनेटीस से अंतर: ACP संस्थागत सीमाओं के पार काम करता है। बैंक A का एक एजेंट बैंक B द्वारा स्वीकार किया जा सकता है बिना बैंक B को बैंक A के आंतरिक बुनियादी ढांचे पर भरोसा किए — केवल क्रिप्टोग्राफिक प्रमाण मायने रखता है।

---

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

Condition	Meaning
`ValidIdentity`	एजेंट के पास एक सत्यापित, हस्ताक्षरित पहचान है

कोई एजेंट कार्रवाई तब तक निष्पादित नहीं की जाती जब तक सभी चार शर्तें एक साथ संतुष्ट न हों।

प्रोटोकॉल परतें प्रत्येक अंतःक्रिया सीमा पर इस अपरिवर्तनीयता को लागू करने के लिए मौजूद हैं।

प्रोटोकॉल आर्किटेक्चर

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 · विश्वास स्तर

गतिशील जोखिम मूल्यांकन और इंटरैक्शन विश्वास प्रबंधन।

घटक	भूमिका
RISK	निर्धारित जोखिम इंजन — जोखिम स्कोर RS (0–100)
REV	निरसन प्रोटोकॉल — एंडपॉइंट और CRL
ITA	संस्थागत विश्वास एंकर — प्रति इंटरैक्शन विश्वास प्रमाणन

L3 · सत्यापन योग्य निष्पादन

प्रत्येक इंटरैक्शन एक पूर्ण, क्रिप्टोग्राफिक रूप से सत्यापन योग्य रिकॉर्ड छोड़ता है।

घटक	भूमिका
EXEC	निष्पादन टोकन — एकल-उपयोग, 300 सेकंड वैधता
POLICY-CTX

L4 · शासन

दीर्घकालिक जवाबदेही और संस्थागत निरीक्षण।

घटक	भूमिका
GOV-EVENTS	शासन घटना स्ट्रीम — संस्थागत ट्रैकिंग

L5 · संघ

स्वतंत्र संस्थानों के बीच अंतर-संचालन।

घटक	भूमिका
ACP-D	विकेंद्रीकृत ACP — क्रॉस-संस्थान संघ, BFT कोरम

सक्रिय विनिर्देश संस्करण

प्रति विनिर्देश वर्तमान सक्रिय संस्करण। यह तालिका "किस संस्करण को लागू करें" के लिए आधिकारिक संदर्भ है।

¹ 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

![](https://raw.githubusercontent.com/BryanNStryKer/OpenRedirectScanner/main/screenshots/img.png)```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)	शासन और जवाबदेही बुनियादी ढाँचा	—

OPA (Open Policy Agent)	डेटा और नियमों से नीतियों का मूल्यांकन करता है	क्रिप्टोग्राफिक एजेंट पहचान + प्रतिनिधिमंडल श्रृंखला + निष्पादन प्रमाण
AWS IAM / Azure RBAC	क्लाउड संसाधनों के लिए स्थैतिक अनुमति मॉडल	सत्यापन योग्य श्रृंखला + लेजर के साथ गतिशील एजेंट-से-एजेंट प्रतिनिधिमंडल
OAuth 2.0 + OIDC	टोकन के माध्यम से उपयोगकर्ता और सेवा प्राधिकरण	गैर-वृद्धि + संस्थागत देयता के साथ मल्टी-हॉप एजेंट प्रतिनिधिमंडल
SPIFFE / SPIRE	क्रिप्टोग्राफिक वर्कलोड पहचान	ACP वर्कलोड पहचान पर बनकर क्षमता स्कोपिंग + शासन जोड़ता है
ACP	एजेंट कार्यों के लिए प्रवेश नियंत्रण	—

SIGN	क्रिप्टोग्राफिक हस्ताक्षर — सभी प्रोटोकॉल वस्तुओं का आधार
AGENT	औपचारिक एजेंट पहचान विनिर्देश `A=(ID,C,P,D,L,S)`
CT	क्षमता टोकन — संरचना, जारी करना और सत्यापन
CAP-REG	विहित क्षमता रजिस्ट्री `acp:cap:*`
HP	हैंडशेक प्रोटोकॉल — क्षमता धारण का क्रिप्टोग्राफिक प्रमाण
DCMA	मल्टी-हॉप प्रत्यायोजन — गैर-वृद्धि और संक्रामक निरसन
MESSAGES	वायर प्रारूप — 5 सामान्यीकृत संदेश प्रकार

ACP-CONF-1.2	✅ पूर्ण — एकमात्र मानक अनुरूपता स्रोत
ACP-LEDGER-1.3	✅ पूर्ण — sig मानक रूप से अनिवार्य
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 `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 रन, mean±std)
Redis पाइपलाइनिंग (`compliance/adversarial/redis_pipelined.go`)	✅ पूर्ण — v1.20 · 2 RTTs/अनुरोध · ~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 आधार रेखा
स्टेटलेस बनाम स्टेटफुल प्रयोग (Exp 6, `pkg/risk/stateless_comparison_test.go`)	✅ पूर्ण — v1.21 · 500 अनुरोध · स्टेटलेस 500/500 बनाम ACP 2/500 (0.4%) · पता लगाने की विलंबता 11 क्रियाएँ
स्थिति-मिश्रण भेद्यता परीक्षण (Exp 7, `pkg/risk/statemixing_test.go`)	✅ पूर्ण — v1.21 · क्रॉस-संदर्भ नियम 1 संदूषण · RS +20 · ESCALATED→DENIED 11 data.read के बाद
स्थिति-मिश्रण हमला विश्लेषण (पेपर §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 §Technical Mechanisms में · contrafactual thesis · 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-मॉनिटर Δ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.5h)
`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 configs ±10 pts)	✅ पूर्ण — v1.26 · झूठी-अस्वीकार दर सभी कॉन्फ़िग में 0.00 · BAR मोनोटोन 0.75→0.60 · T3 स्थानीय इष्टतम
पता लगाने की गारंटी — प्रस्ताव + द्विपद P(detect)	✅ पूर्ण — v1.26 · W=40 τ=0.10 · P=1.00 p₁=0.00 पर · P=0.95 p₁=0.05 पर
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 24h स्थिरता
Real-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 profiles (Low/Medium/High/Critical)	✅ पूर्ण — v1.27 · प्रति प्रोफ़ाइल BAR आधार रेखा · RISK-2.0→RISK-3.0 माइग्रेशन गाइड
Exp 13: बाउंडेड समन्वय विंडो (`compliance/adversarial/exp_coordination_window.go`)	✅ पूर्ण — v1.28 · CW=2N सटीक रैखिकता · evaluate-then-mutate semantics · k₀=2 प्रति एजेंट · O(N) सीमा
LLM एजेंट एकीकरण उपधारा §Technical Mechanisms में स्थानांतरित	✅ पूर्ण — v1.28 · §Deterministic Risk Evaluation के बाद · IPI प्रॉम्प्ट फ़िल्टर के साथ संयोजनीय
Exp 14: OPA बनाम ACP क्षमता तुलना (`compliance/adversarial/exp_opa_benchmark.go`)	✅ पूर्ण — v1.29 · 3 परिदृश्य · स्टेटलेस इंजन बाहरी अवस्था के बिना आवृत्ति/कूलडाउन लागू नहीं कर सकते · ACP मूल रूप से लागू करता है · ~852 ns/op ACP बनाम ~16,000 ns/op OPA
§Related Work — औपचारिक सत्यापन और रनटाइम प्रवर्तन (विस्तारित)	✅ पूर्ण — v1.29 · OPA अभिव्यक्ति सीमा · Schneider सुरक्षा ऑटोमेटन संरेखण · Exp 14 क्रॉस-रेफरेंस
शासन श्रृंखला एकीकरण: पेपर 3–4 §15 में उद्धृत; `fernandez2026comp` bib प्रविष्टि	✅ पूर्ण — v1.30
v1.x	मुख्य प्रोटोकॉल और संदर्भ कार्यान्वयन — सक्रिय
v2.0	विकेंद्रीकृत ACP (ACP-D) — डिज़ाइन में
भविष्य	ZK सत्यापन, विकेंद्रीकृत शासन

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	कोर	पहचान, क्षमता टोकन और निष्पादन
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-framework-en

सबसे लोकप्रिय

ACP — एजेंट नियंत्रण प्रोटोकॉल

आधिकारिक वेबसाइट

पेपर

अनुसंधान श्रृंखला

ACP क्यों मौजूद है

ACP बनाम संबंधित प्रोटोकॉल

ACP बनाम नीति और प्रमाणीकरण सिस्टम

प्रवेश नियंत्रण के रूप में ACP

प्रोटोकॉल आर्किटेक्चर

डिज़ाइन सिद्धांत

स्पष्ट प्राधिकार

निर्धारित निष्पादन

सत्यापन योग्य इतिहास

संस्थागत जवाबदेही

संघीय विश्वास

प्रोटोकॉल घटक

L1 · कोर निष्पादन

L2 · विश्वास स्तर

L3 · सत्यापन योग्य निष्पादन

L4 · शासन

L5 · संघ

सक्रिय विनिर्देश संस्करण

अनुरूपता स्तर

विनिर्देश

L1 · कोर निष्पादन

L2 · विश्वास स्तर

L3 · सत्यापन योग्य निष्पादन

L4 · शासन

L5 · संघ

शासन

रिपॉजिटरी संरचना```

रोडमैप

लाइसेंस