ACP — بروتوكول التحكم في العوامل

التحكم في القبول لإجراءات العوامل.

قبل أن يُغيّر أي عامل حالة النظام، يُجيب ACP على أربعة أسئلة: من هو هذا العامل؟ وما هي الإجراءات المصرّح بها؟ هل هذا الإجراء متوافق مع السياسة؟ هل يمكن تتبع النتيجة إلى مؤسسة خاضعة للمساءلة؟

الهوية التشفيرية · رموز القدرات المحددة النطاق · سلاسل التفويض القابلة للتحقق · دليل التنفيذ

الموقع الرسمي

https://agentcontrolprotocol.xyz

الورقة البحثية

بروتوكول التحكم في العوامل: التحكم في القبول لإجراءات العوامل مارسيلو فرنانديز (TraslaIA)، 2026

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

سلسلة الأبحاث

ACP هو الأساس المنشور لسلسلة من سبع أوراق بحثية حول الحوكمة الرسمية للعوامل. كل ورقة تتناول طبقة متميزة من هيكل الحوكمة.

منطق السلسلة: الورقة 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) قبل وصولها إلى المجموعة — تقييم السياسات، فرض الحصص، رفض العمليات غير المتوافقة. يُطبق 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 في البنية التحتية الداخلية للبنك 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

لا يتم تنفيذ أي إجراء للوكيل إلا إذا تم استيفاء جميع الشروط الأربعة في وقت واحد.

توجد طبقات البروتوكول لفرض هذا الثابت عند كل حد تفاعل.

بنية البروتوكول

يتم تنظيم 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، جميع نقاط النهاية المؤسسية

L4 · الحوكمة

• ACP-GOV-EVENTS-1.0 — تيار أحداث الحوكمة المؤسسية
• ACP-REP-1.2 — امتداد السمعة، درجة مركبة 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — سلسلة مسؤولية منسوبة
• ACP-HIST-1.0 — واجهة برمجة تطبيقات استعلام تاريخ التنفيذ المدقق
• ACP-PAY-1.0 — امتداد الإمكانية المالية القابلة للتحقق
• ACP-NOTIFY-1.0 — الأحداث وwebhooks
• 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

Huawei E3372
سيدعم وضع Hi-Link (كواجهة شبكة) فقط، أي أنه لن يعمل في وضع المودم/التسلسلي.

**ملاحظة**
هذا هو حل بديل لخلل البرنامج الثابت الحالي لـ Hi-Link (وليس الجهاز) الذي لا يقوم دائمًا بتمرير سياق PDP (APN واسم المستخدم/كلمة المرور) إلى اتصال WAN.```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