معيار OWASP Agent Control Standard (ACS): التحكم في وكلاء الذكاء الاصطناعي وقت التشغيل

من مولّد للإجابات إلى فاعل

تنتج تطبيقات LLM التقليدية نصًا يقرؤه إنسان قبل أن يحدث شيء. أما وكلاء الذكاء الاصطناعي فيخططون بشكل مستقل، ويستدعون الأدوات، ويكتبون في ذاكرة طويلة المدى، ويبدؤون وكلاء فرعيين. وكل خطوة من هذه قد تغيّر البيانات أو تنقلها إلى الخارج. لذلك يصبح سؤال التحكم: «هل يجوز لهذا الإجراء بعينه وبهذه الوسائط بعينها أن يحدث الآن في هذه الجلسة؟» ولا يمكن الإجابة عنه إلا أثناء التشغيل — بين قرار النموذج والتنفيذ من قِبل إطار العمل.

مطالبات النظام ليست ضوابط

تعتمد كثير من عمليات النشر على تعليمات في مطالبة النظام مثل «لا تحذف بيانات الإنتاج». وهذه العبارات طلبات موجهة إلى نظام احتمالي، لا قواعد مُنفَّذة. وتبدأ صفحة مشروع ACS تعليلها بذلك: مطالبات النظام ليست ضوابط، والنماذج الأفضل لا تغطي الحالات الحدّية والمدخلات العدائية، وحواجز الحماية الاحتكارية تخلق تبعية للمورّد.

تؤكد الشركات المصنِّعة والأبحاث ذلك. فقد كتبت OpenAI في 22 ديسمبر 2025 أن حقن الأوامر (Prompt Injection) «unlikely to ever be fully 'solved'». وفي دراسة «The Attacker Moves Second» (arXiv، 10 أكتوبر 2025) تغلبت الهجمات التكيفية على اثني عشر أسلوبًا دفاعيًا حديثًا، غالبًا بمعدلات نجاح تتجاوز 90 بالمئة — رغم أن معظمها كان قد أبلغ في الأصل عن قيم قريبة من الصفر. تقلل متانة النموذج المخاطر لكنها لا تزيلها. فالمطلوب جهة فحص مستقلة خارج النموذج.

Lethal trifecta و Agents Rule of Two

وصف Simon Willison في 16 يونيو 2025 «الثالوث القاتل» (lethal trifecta): الوكيل الذي يملك وصولًا إلى بيانات خاصة، ويتعرض لمحتوى غير جدير بالثقة، ويستطيع التواصل مع الخارج، يمكن دفعه عبر حقن الأوامر (Prompt Injection) إلى تسريب البيانات. ووسّعت Meta ذلك في 31 أكتوبر 2025 إلى «Agents Rule of Two»: ضمن الجلسة الواحدة ينبغي ألا يجمع الوكيل أكثر من خاصيتين من ثلاث: معالجة مدخلات غير جديرة بالثقة؛ الوصول إلى أنظمة حساسة أو بيانات خاصة؛ تغيير الحالة أو التواصل الخارجي. وإذا احتاج إلى الثلاث جميعًا، فلا بد على الأقل من إشراف، مثلًا عبر موافقة بشرية. وتؤكد Meta أن القاعدة تكمّل مبدأ الحد الأدنى من الصلاحيات (Least Privilege) ولا تحل محله.

تقدير VamiSec: يصف النموذجان كلاهما خصائص جلسة لا خصائص نموذج. ولا يمكن إنفاذهما إلا إذا رأت جهةٌ ما كل إجراء ومسار الجلسة حتى تلك اللحظة. وهذه نقطة التحكم التي يوحّدها OWASP Agent Control Standard (ACS). ولاكتشاف المدخلات غير الجديرة بالثقة يلزم الملف التعريفي الاختياري acs-provenance؛ فـ ACS-Core وحده لا يقدّم بيانات عن المصدر.

حوادث موثقة — وما كان تحكم وقت التشغيل سيحدّ منه

لماذا يجب أن يكون التحكم في وقت التشغيل

يبقى اختيار النموذج وتقوية المطالبات ومحاكاة الهجمات (Red Teaming) قبل الإطلاق أمورًا ضرورية، لكنها لا تكشف ما يفعله الوكيل في جلسة بعينها. ويكمّلها تحكم وقت التشغيل: فهو يعمل قبل الإجراء، ويقيّم سياق الجلسة بأكملها، ويترك أثر تدقيق قابلًا لإعادة البناء. وتوصي OWASP Top 10 for Agentic Applications 2026 بالنسبة إلى ASI02 (Tool Misuse and Exploitation) بطبقة وسيطة سابقة لإنفاذ السياسات، أي «Intent Gate» تفحص النية والوسائط قبل التنفيذ. لا يُذكر ACS هناك، لكنه يقدّم (وفق تقدير VamiSec) عقد Wire مفتوحًا لنقطة التحكم هذه تحديدًا. وتبقى السياسات من مسؤوليتكم.

وبدقة أكبر: Agent Control Standard (ACS) مواصفة صادرة عن OWASP GenAI Security Project، تحدد نقاط التحكم (Hooks) التي يعرض عندها وكيل الذكاء الاصطناعي خطواته على جهة سياسات خارجية، وكيف ترد هذه الجهة بقرار (Disposition). والصيغة هي JSON-RPC 2.0 مع حقل خاص acs_version، تُنقل عبر HTTP(S) أو stdio. والوضع الحالي هو المواصفة v0.1.0، المنشورة كإصدار 0.1.2 (Tag بتاريخ 21 سبتمبر 2026). يحدد ACS العقد بين الوكيل والـ Guardian، لا السياسات: فما هو مسموح به تقرره مؤسستكم كما في السابق.

الأطراف

يقوم البناء على مبدأ تصميمي واحد: لا يجوز لنموذج اللغة أن يعرف شيئًا عن الـ Hooks. فإطار العمل هو من يطلقها، وتُحدَّد بيانات المصدر (Provenance) خارج مسار مخرجات النموذج. ووفق قراءتنا، يُراد بذلك ألا يتمكن نموذج متلاعَب به من رؤية نقطة التحكم أو التأثير فيها.

ثلاث ركائز: Instrument و Trace و Inspect

ACS-Core وسبعة ملفات تعريفية

المطابقة مبنية بشكل وحدوي. فـ ACS-Core هو القاعدة الإلزامية، وتقوم عليه ستة ملفات تعريفية اختيارية يصرّح بها النشر في الـ Handshake. ولا توجد مستويات مرقّمة — بل أسماء ملفات تعريفية فقط يمكن الجمع بينها باستقلالية. والاعتمادية الوحيدة: acs-inspect-dynamic يوسّع acs-inspect.

تصوغ المواصفة ما يضمنه ACS-Core بموضوعية: القناة موثَّقة، والـ Observed Agent يلتزم بالقرارات. أما ما ليس مضمونًا فهو صرامة السياسات — فالـ Guardian المتساهل مطابق، لكنه متساهل فحسب. ولا يوفّر دليل التلاعب في سلسلة التدقيق حتى في مواجهة Guardian مخترَق إلا acs-crypto و acs-audit، لأن قاعدة HMAC إجراء متماثل. وتتراوح التركيبات النموذجية في المواصفة بين تكامل IDE أدنى مع acs-core فقط ونشر عالي الضمان مع جميع الملفات التعريفية السبعة.

نموذج الطبقات في صفحة المشروع: طبقات معمارية لا مستويات

1. 1
   المستوى 1 · طبقة المنصة (Platform layer)

   توفر أطر عمل الوكلاء Hooks وسيطة موحدة — وهنا تنشأ نقطة التحكم.

2. 2
   المستوى 2 · طبقة الإنفاذ (Enforcement layer)

   مكوّن مفتوح المصدر يقرأ سياسات تصريحية ويعيد القرارات عبر هذه الـ Hooks.

3. 3
   المستوى 3 · طبقة المؤسسة (Enterprise layer)

   تُربط المصنِّفات الخاصة والمنطق المتخصص بالمجال خلف الواجهة نفسها.

تصف هذه الصورة من يسهم بأي جزء، لا مدى مطابقة النشر. فلبيانات المطابقة لا يُعتد إلا بالملفات التعريفية. ومع ذلك فهي مفيدة لتخطيط البنية لديكم: إذ تفصل سؤال أي منصة توفر الـ Hooks عن سؤال من يشغّل السياسات ويصونها.

من المراقبة إلى التحكم

بدأ العمل في 11 مايو 2025 باسم «Agent Observability Standard» (AOS) في بيئة GitHub الخاصة بـ Zenity، وانتقل في يونيو 2025 إلى منظمة OWASP، حيث أُدرج AOS بوصفه «OWASP other project». وحملت طبقة البروتوكول في مايو ويونيو 2025 مؤقتًا اسم «ASOP» (Agent Security & Observability Protocol)، قبل أن تعود إلى اسم AOS. وبعد مرحلة لم تشهد سوى Commits متفرقة منذ منتصف 2025، جاءت في 10 أبريل 2026 إعادة التسمية إلى Agent Control Standard. ويشير الاسم الجديد إلى الخطوة المضمونية: من مجرد المراقبة إلى الإنفاذ. بعد ذلك عمل ACS لفترة وجيزة كمشروع مستقل خارج OWASP، ثم عاد في سبتمبر 2026 — هذه المرة إلى OWASP GenAI Security Project.

الحالة: Incubator و public preview

ACS مشروع ضمن OWASP GenAI Security Project ومُلحق فيه بـ Agentic Security Initiative. ويصرّح في بيانات OWASP-Nest الوصفية الخاصة به بالمستوى 2، وفي مخطط Nest بمرحلة «Incubator»؛ وبذلك لا يثبت أن هيئة من OWASP قد صنّفته. ويصف قائد المشروع الوضع علنًا بأنه «public preview» وينصح المنفّذين صراحةً بالحذر. ACS ليس معيارًا من ISO أو IETF أو W3C وليس معيارًا مُنسَّقًا. ويتجلى الطور المبكر شكليًا أيضًا: لا توجد GitHub-Releases، بل Tags فقط؛ وقد تغيّر نص المواصفة والمخططات بين v0.1.1 و v0.1.2 دون رفع رقم إصدار المواصفة v0.1.0.

من يدير المشروع؟

وفق GOVERNANCE.md، أنشأ Michael Bargury و Ory Segal مشروع ACS؛ ويبقى كلاهما قائدين للمشروع. أما قائد المشروع (Project Lead) فهو Rock Lambros. وللشفافية: Bargury هو CTO وأحد مؤسسي Zenity، ويُدرَج Lambros لدى Zenity بصفة «Director of AI Standards and Governance»، وتعود معظم Commits المبكرة لـ AOS إلى بيئة Zenity. ويقود مسارات العمل — Coding Agents و Development (SDK) و Identity و Outreach و Spec — أشخاص من عدة منظمات. وتصف صفحة المشروع ACS بأنه محايد تجاه الشركات المصنِّعة ويُدار بشكل جماعي؛ وهذا وصف ذاتي. وتصنيفنا: مشروع OWASP يحمل طابعًا قويًا من Zenity في التأسيس والقيادة.

تمر القرارات عبر بوابة قبول. فلا تدخل قائمة الأعمال إلا الـ Issues التي تحمل الوسم status:accepted؛ وتحتاج التغييرات في السلوك أو النص المعياري أو التعليمات البرمجية إلى Issue مقبول، وتبدأ تغييرات المواصفة كـ GitHub Discussion، وتتطلب الـ Commits توقيع DCO-Sign-off. ويجري التطوير على الفرع integration. ولا يُعاد نشر الموقع وعناوين URI للمخططات إلا عندما يرقّي قائد المشروع التغييرات إلى main. وحتى 3 أكتوبر 2026 لم تتم ترقية main منذ 10 سبتمبر 2026 — أي أن التغييرات على integration لم تُنشر بعد.

الترخيص: ما يجوز لكم اعتماده

خارطة الطريق: ما هو موثّق

يستهدف الإصدار التالي للمواصفة v0.2.0 شهر مارس 2027؛ ولم يُحدَّد موعد لـ v1.0. ومن المدرج لـ v0.2 من بين أمور أخرى: Streaming و Interruption، و ASK التكراري و Quorum، وعزل المستأجرين المتعددين (Multi-Tenant)، وربط Cedar، واتحاد AgBOM عبر نظراء A2A، وتغليف A2A. والهدف الجاري منذ الانطلاق في 10 سبتمبر 2026: خلال 90 يومًا تنفيذ مرجعي قابل للتشغيل للـ Guardian، مُقاس من حيث التشغيل البيني مع Agent Governance Toolkit من Microsoft، وفي أيدي مقيّمين خارجيين. ولا يزال غير محسوم ما إذا كان ذلك سينجح بحلول أوائل ديسمبر 2026. كما لا يزال PR #21 مفتوحًا، والذي يسعى إلى إعادة رسم النطاق الإلزامي لـ ACS-Core. ومسودات الإصدارات المختلفة في المدونات ليست خارطة طريق رسمية.

تحمل الـ Hooks على الـ Wire البادئة steps/، مثل steps/toolCallRequest. وإلى جانبها توجد طرق ليست Hooks أصلية من نوع steps/*: agbom/snapshot و agbom/changed للجرد، وفحص الحيوية system/ping، والـ Handshake handshake/hello، والنطاق protocols/MCP/* لرسائل MCP المغلّفة. وتعدّ صفحة الـ Hooks في المواصفة 19 Hook إضافة إلى طريقتي AgBOM وإلى Ping بوصفها 22 طريقة؛ وتشمل حزمة المخططات إجمالًا 44 مخطط JSON. ولا تزال بعض نصوص المشروع (README، docs/acs.md) تذكر 16 Lifecycle-Hook — وهذا هو العدد دون Hooks الـ Skills الثلاثة.

الحد الأدنى لـ Core: ستة Hooks

يشترط ACS-Core ستة Hooks على الأقل: sessionStart، و userMessage أو agentTrigger، و toolCallRequest، و toolCallResult، و agentResponse، و sessionEnd. وينبغي لإطار العمل تنفيذ الباقي جميعًا متى أمكنه رصد الحدث المعني؛ ويُتفاوض عليها في الـ Handshake. ويعني ذلك لتقييم منتجاتكم: عبارة «يدعم ACS» لا تكشف بعدُ ما إذا كانت عمليات الكتابة في الذاكرة أو الوكلاء الفرعيون أو الـ Skills تصل إلى الـ Guardian أصلًا.

فخ methods_evaluated

يبلغ الـ Observed Agent في الـ Handshake عن الطرق التي ينفّذها (methods_implemented). ويرد الـ Guardian بقائمة الطرق التي يقيّمها فعليًا (methods_evaluated). وإذا أرسل الوكيل Hook غير وارد فيها، وجب عليه معاملته بوصفه ALLOW-by-default — فتُسجَّل الخطوة في أحسن الأحوال لكنها لا تُفحص. فعلى سبيل المثال، لا يقيّم التنفيذ المرجعي الوحيد سوى steps/toolCallRequest و steps/toolCallResult، أي اثنين من 19 Hook.

toolCallRequest: نقطة الإنفاذ المحورية

steps/toolCallRequest هو الـ Hook الوحيد الذي تنص المواصفة صراحةً على جميع الـ Dispositions الخمس له؛ وهنا أيضًا تعمل نماذج التحكم. والمحوري قاعدة MUST: يجب على أطر العمل إطلاق toolCallRequest لكل إجراء يغادر سياق الاستدلال لدى الوكيل — حتى لو لم يعامله إطار العمل داخليًا كأداة. ويشمل ذلك عمليات القراءة والكتابة في نظام الملفات، وطلبات الشبكة، وبدء العمليات، وأوامر الـ Shell. وما يتجاوز هذا الـ Hook لا تراه أي سياسة.

الإلزامي في الحمولة هو tool.name و arguments، ويمكن لكل قيمة وسيط أن تحمل Provenance خاصًا بها. ويُضاف اختياريًا capability مجردة مثل filesystem.delete أو network.egress، و raw_command، و intent. وبذلك يمكن للسياسات تقييم ما يُحدثه الإجراء بدلًا من البرنامج الذي ينفّذه.

Hooks ذات أثر حمائي خاص

• memoryStore هو المصبّ القياسي للتأثير عبر الجلسات، ووفق المواصفة نقطة الانطلاق لمواجهة تسميم الذاكرة (Memory Poisoning) (راجعوا ASI06: Memory & Context Poisoning).
• يؤمّن preCompact و postCompact عملية التكثيف: يجب أن يحمل الملخص origin agent_generated وأن يرث مصدر جميع الإدخالات المكثفة، حتى لا يُغسل المحتوى غير الجدير بالثقة.
• يتيح subagentStart للـ Guardian رفض بدء وكيل فرعي؛ ويحصل كل وكيل فرعي على session_id خاص وسلسلة تدقيق خاصة.
• يربط skillRegister و skillLoad الـ Skills بـ Digest: فلا يجوز تحميل إلا ما اعتُمد مسبقًا بـ skill_id مطابق و Digest مطابق؛ وينبغي رفض عمليات التحميل غير القابلة للنسبة.

على الـ Wire تُكتب الـ Dispositions بأحرف صغيرة في الحقل decision؛ أما نص المواصفة فيكتبها بأحرف كبيرة (ALLOW، DENY …). وكل رد في v0.1 من النوع final — فالحالات المرحلية (progress) والمقاطعات (interruption) مخطط لها في v0.2 فقط. والإلزامي في كل رد هو type و acs_version و request_id و decision؛ ويعكس request_id معرّف الطلب.

MODIFY: شكلان يستبعد أحدهما الآخر

يعرف الكائن modifications شكلين. فإما أن يحل modified_content محل الحمولة بأكملها — وعندها لا يُسمح بأي تعديلات أخرى. وإما أن يرسل الـ Guardian تعديلات منظَّمة: redactions (مسار JSON-Pointer مع نص بديل، والافتراضي «[REDACTED]») و/أو parameter_overrides (اسم الوسيط مع قيمة جديدة). ويجوز ورودهما معًا، لكن يجب أن تكون أهدافهما منفصلة: لا يجوز لأي مسار حجب أن يصيب الحقل نفسه الذي يصيبه Override، ولا حقلًا أعلى أو أدنى منه. وتعلل المواصفة ذلك بأن ترتيب تطبيق ثابتًا كان سيحل التعارضات بصمت، وبحسب الترتيب قد يكشف قيمًا محجوبة من جديد أو يستبدل قيمًا منقّاة. وإذا خالف الـ Guardian هذه القواعد، وجب على الـ Observed Agent معاملة الرد كأنه deny.

مثال: يريد وكيل الاستعلام عن جدول عملاء بالكامل. فيرد الـ Guardian بـ modify ومُدخل في parameter_overrides يقيّد الاستعلام بـ 500 صف — كما في سيناريو المحاكي «استعلام قاعدة بيانات غير مقيّد». وتُكتب قيم الـ Override في الكائن كقيمة خام، لا داخل غلاف value.

ASK: موافقة بقواعد واضحة

• يشترط ask_details وجود approver مع type (human أو agent أو service) و id، و question، و timeout_seconds (1 على الأقل).
• عند انقضاء المهلة يسري timeout_disposition؛ والقيمة الافتراضية هي deny.
• يجب على الـ Guardian التحقق من هوية المعتمِد مقابل السياسة — فمصادقة المعتمِد إلزامية.
• قفزة واحدة فقط: لا يجوز للمعتمِدين أنفسهم إرجاع ask. وقد أُرجئ الـ Quorum والموافقات التكرارية إلى v0.2.
• إذا لم يستطع العميل معالجة ASK، فلا يجوز للـ Guardian إرسال ask. بل يلجأ إلى defer مع timeout_decision deny أو إلى deny مع رمز السبب approver_unavailable — ويُستبعد أي allow صامت.
• عبر intent_extension يمكن للموافقة توسيع الـ Capabilities المسموح بها لـ this_request أو للـ session بأكملها. ووفق المواصفة، هذه هي الطريقة المطابقة الوحيدة لتعديل النية المحددة لاحقًا.

مهم من الناحية التنظيمية: ASK ليس تلقائيًا إشرافًا بشريًا. فقد يكون المعتمِد وكيلًا أو خدمة، ويمكن ضبط timeout_disposition على allow. ويُطبَّق الإشراف البشري وفق المادة 14 من EU AI Act على الأنظمة عالية المخاطر اعتبارًا من 2 ديسمبر 2027 (الملحق III) أو 2 أغسطس 2028 (الملحق I)؛ ووكلاء الذكاء الاصطناعي ليسوا بطبيعتهم عالية المخاطر. ومن يستخدم ASK كمكوّن لذلك يحتاج وفق تقدير VamiSec إلى سياسة مع approver.type human و timeout_disposition deny، وإلى عملية موافقة تتجنب إرهاق اتخاذ القرار. وعندها يدعم ASK توثيق الإثبات، لكنه لا يفي بالمادة 14 وحده: فلا يعرف v0.1 زر إيقاف، بل deny خطوة بخطوة فقط.

DEFER: تأجيل القرار، لكن ضمن حدود

يشترط defer_details وجود reason (insufficient_context أو conflicting_policies أو low_confidence أو pending_dependency)، و resolution_method (additional_context أو human_approval أو timeout)، و resolution_timeout_ms. وعند انقضاء المهلة لا يعرف timeout_decision إلا deny أو ask — دون allow — وقيمته الافتراضية deny. ويشترط النص الوصفي هذا الحقل، بينما لا يدرجه المخطط كإلزامي؛ لذا اضبطوه دائمًا صراحةً. ويجب تقييد التأجيلات المتتالية لكل جلسة. وانتبهوا إلى الوحدات: يحسب ASK بالثواني (timeout_seconds)، و DEFER بالمللي ثانية (resolution_timeout_ms).

تبدأ كل جلسة بـ handshake/hello. وتوضع رسالة ClientHello في payload لغلاف طلب عادي، وتعود رسالة ServerHello كـ result — دون decision. ويجب أن يتطابق الإصدار المتفاوض عليه في الإصدار الرئيسي مع إصدار العميل؛ ويجب تجاهل الحقول غير المعروفة.

وضعية الفشل: fail-open هو الإعداد الافتراضي

يجب على الـ Observed Agent انتظار القرار لكل خطوة مُبلَغ عنها — حتى المهلة المتفاوض عليها — ثم تطبيقه. وإطار العمل الذي يرسل الـ Hooks لكنه يتجاهل الحكم غير مطابق. وإذا لم يصل قرار صالح للاستخدام، تتحدث المواصفة عن decision failure: إما أن يصمت الـ Guardian، أو ينقطع النقل (اتصال مرفوض، خطأ TLS، رد معيب)، أو يقدّم الـ Guardian خطأً بدلًا من قرار. وفي الحالات الثلاث يسري on_decision_failure، والقيمة الافتراضية هي proceed: أي يستمر الإجراء دون فحص. أما fail-closed (deny) فيجب أن يهيئه النشر صراحةً.

تسمّي المواصفة الثمن بصراحة: من يستطيع تعطيل القناة يحوّل التحكم إلى مجرد تسجيل. وفي المقابل يسري التزام صارم — يجب تسجيل كل خطوة تستمر دون قرار كحدث تدقيق. وإذا وصل قرار مع ذلك ضمن المهلة، وجب على الوكيل الالتزام به بصرف النظر عن الوضعية.

وضعية بدء التشغيل (Startup-Posture): حين يفشل الـ Handshake نفسه

إذا تعذر الوصول إلى الـ Guardian عند بدء الجلسة أو رد دون ServerHello، تسري وضعية بدء تشغيل مهيأة خارج البروتوكول: proceed (تبدأ الجلسة دون حماية) أو refuse. وهنا أيضًا proceed هو الافتراضي، حتى لا يحظر تعطل الـ Guardian الجلسات الجديدة. ويجب تسجيل الجلسة التي بدأت دون حماية في سجل التدقيق الخاص بالنشر. أما الرفض الصريح من الـ Guardian، مثل SESSION_REFUSED، فيُعد قرارًا لا تعطلًا.

المهل: لا قيمة افتراضية في المواصفة

لا تحدد المواصفة مهلة قياسية رقمية. فـ timeout_config.default_ms إلزامي في ServerHello، لكن قيمته من شأن النشر؛ ويتيح per_method_ms قيمًا مختلفة لكل طريقة. ويذكّر مخطط الـ Handshake بأن كل مللي ثانية من المهلة تعني في أسوأ الأحوال زمن انتظار للخطوة، ويوصي بضبط المهل لكل طريقة وفق تحمّل زمن الاستجابة بدلًا من قيمة إجمالية سخية. ويستخدم التنفيذ المرجعي 5000 ms — وهي قيمة تنفيذية لا اشتراط. ونموذج مهل قائم على الحساسية مخطط له في v0.2. ولتوضيح المصطلح: ACS_ON_DECISION_FAILURE متغير بيئة في الـ Guardian المرجعي يضبط قيمة on_decision_failure — وليس حقلًا في المواصفة.

الـ Ping لا يثبت الإنفاذ

system/ping مجرد فحص حيوية (Liveness Probe): يجب على الـ Guardian الرد دائمًا بـ allow، ولا يحتاج الـ Ping إلى توقيع ولا يُكتب في سلسلة التدقيق. وبالتالي يمكن للـ Guardian الرد على الـ Pings وفي الوقت نفسه رفض كل Hook موقّع. لذلك توصي المواصفة بمراقبة حالات Decision Failure على مسار الـ Hook مباشرةً.

طبقتان بترتيب ثابت

تقيّم الطبقة الحتمية كل Hook أولًا. فهي إما تقرر بنفسها أو تفوّض إلى طبقة الوكيل — وفقًا للمواصفة عبر إعداد سلسلة (Chain) بالأوضاع «*» أو on_ask أو المعتمد على الأنماط. غير أن v0.1 لا يعرّف تنسيقًا لهذا الإعداد. تتلقى طبقة الوكيل المدخلات نفسها إضافةً إلى النتيجة المرحلية للطبقة الحتمية، لكنها لا تتلقى كود السياسات أبدًا. ويجب أن تمر إجابتها في طريق العودة مجددًا عبر الطبقة الحتمية.

1. 1
   وصول Hook

   تُرسَل Request-Envelope وSessionContext وIntent، وProvenance إن وُجد، إلى محرك السياسات.

2. 2
   التقييم الحتمي

   يُصدر Policy-as-Code — في v0.1 مع OPA/Rego كمرجع أولي — allow أو deny أو modify أو ask أو defer، أو يفوّض.

3. 3
   طبقة LLM اختيارية

   تقيّم الحالات التي لا يمكن البتّ فيها حتميًا؛ وتعامل الحقول غير الموثوقة كبيانات ولا ترى كود السياسات.

4. 4
   إعادة الفحص والإجابة

   تمر النتيجة مجددًا عبر الطبقة الحتمية؛ ويبيّن metadata.evaluator القيمة deterministic أو agent أو composite.

5. 5
   التسجيل

   يُسجَّل كل قرار مع التعليل ومعرّف النموذج، ودرجة الثقة إن توفرت.

محرك السياسات: واجهة لا منتج

يعرّف ACS الواجهة إلى المحرك الحتمي، لا المحرك نفسه. تتكون المدخلات من Request-Envelope وSessionContext وIntent وProvenance، والمخرجات من Envelope للقرار، مع تفويض اختياري إلى طبقة الوكيل (delegate_to). ويضع ACS إضافةً إلى ذلك أعرافًا، منها: لا استدعاءات HTTP خارجية في السياسات المعيارية. وهذا يدعم الحتمية وزمن الاستجابة.

التزامات طبقة LLM

• البيانات غير الموثوقة بيانات وليست تعليمات؛ ويجب تغليف الحقول المعنية أو وضعها بين علامات اقتباس في الـ Prompt.
• لا وصول إلى كود السياسات الخاص بالطبقة الحتمية.
• تسجيل كل قرار مع التعليل ومعرّف النموذج ودرجة الثقة (إن توفرت)؛ وعند evaluator بقيمة agent أو composite يجب ذكر model_id.
• تتبع المهل الزمنية قيمة timeout_config المتفاوض عليها في Handshake.
• الطبقة بأكملها اختيارية في v0.1.0: عمليات النشر الحتمية بالكامل متوافقة تمامًا.

نماذج تحكم دون امتداد Wire خاص

تذكر المواصفة أربعة نماذج كأهداف لـ v0.1. يعبّر Guardian عنها عبر الحقول نفسها — reason_codes وpolicy_references وpolicy_data وcited_provenance_ids. وإذا جمع نشرٌ ما عدة نماذج، جاز لقرار واحد أن يستشهد بها جميعًا.

تحتاج قواعد FIDES وCaMeL والقواعد على غرار AARM إلى بيانات المصدر، ولذلك تفترض وجود الملف التعريفي acs-provenance؛ أما IBAC الصرف فلا. لا يطبّق ACS أيًّا من هذه الأساليب بنفسه، بل يوفر الحقول التي يطبّقها Guardian من خلالها ويعلّلها. أي أن ACS لا يمنع Prompt Injection — بل ينشئ نقطة التحكم التي تتدخل عندها السياسات ضد عواقبه.

التشغيل: زمن الاستجابة والتوافر (تقييم VamiSec)

• زمن الاستجابة: يقع كل فحص في المسار الحرج للوكيل. أبقوا الطبقة الحتمية محلية ودون استدعاءات خارجية، وخصّصوا طبقة LLM لحالات قليلة غير واضحة، وقيسوا evaluation_duration_ms لكل أسلوب.
• التوافر: مع fail-closed يصبح Guardian حرجًا للتشغيل. شغّلوه قريبًا من الوكيل وبشكل احتياطي متكرر. ويوثّق التطبيق المرجعي هذا الخطر بنفسه: فهو يكتب السجلات بشكل متزامن في مسار القرار، بحيث يعطّل قرصٌ بطيء كل قرار جارٍ.
• دورة حياة السياسات: أدّوا إدارة إصدارات السياسات وأعيدوا policy_version في كل قرار؛ إذ تنص المواصفة على ذلك لإعادة بناء حالات السياسات التاريخية.
• حدود النطاق: لا يحل Guardian محل Sandbox ولا IAM ولا إدارة الأسرار ولا جدار حماية Egress. وتبقى الإجراءات التي تتجاوز toolCallRequest غير مرئية له.

يشغّل التطبيق المرجعي الوحيد Agent Governance Toolkit من Microsoft دون تعديل خلف ACS-Wire. وهو صراحةً إثبات مفهوم (Proof of Concept): اثنان من 19 Hook مفعّلان، ولا توقيع HMAC، والإعداد الافتراضي fail-open. يوضح النمط لعميلين (Claude Code وOpenCode)، لكنه غير مخصص للتشغيل الإنتاجي.

تمر بين Observed Agent وGuardian Agent قرارات تسمح بإجراءات أو تحجبها. ومن يستطيع التلاعب بهذه القناة يحوّل deny إلى allow أو يعيد إدخال موافقة قديمة. لذلك يعامل OWASP Agent Control Standard (ACS) أمن القناة جزءًا من خط الأساس الإلزامي ACS-Core، لا ملفًا تعريفيًا اختياريًا.

توقيع خط الأساس: HMAC-SHA256 بمفتاح الجلسة

يشترط ACS-Core على كل Request وكل Response توقيعًا على الـ Envelope المعياري. وخط الأساس الذي يفي بهذا الالتزام هو HMAC-SHA256. يُشتق المفتاح لكل جلسة عبر HKDF — من مادة المفاتيح الخاصة بالنشر (سر مشترك مسبقًا أو ربط بالقناة مثل TLS-Exporter) مع session_id. ولا يعرّف v0.1 تبادلًا للمفاتيح ضمن البروتوكول. يُوقَّع على التحويل المعياري RFC-8785 (JCS) للـ Envelope دون الحقل signature؛ ويعيد المستقبِل حساب هذا الشكل ويرفض أي توقيع غير مطابق. ولا يكفي TLS وحده صراحةً، لأنه لا يربط رسالة مفردة لأغراض التدقيق. والمستثنى الوحيد من التزام التوقيع هو أسلوب الحيوية system/ping.

تفصيلان مهمان للبنية. في JSON-Schema يكون signature اختياريًا، لكنه إلزامي معياريًا في ACS-Core — أي أن التحقق من المخطط وحده لا يكشف التوقيعات المفقودة. كما أن المواصفة لا تحدد Salt ولا Info-String ولا دالة التجزئة ولا طول المفتاح لـ HKDF؛ لذا قد تشتق تطبيقان مفاتيح مختلفة. وفي تقديرنا، تنتمي هذه المعلمات إلى اتفاقية الواجهة بين تشغيل المنصة وتشغيل Guardian.

الحماية من إعادة الإرسال

يحمل كل Request قيمة request_id (UUID) وtimestamp واختياريًا nonce. ويجب على Guardian رفض الطلبات التي يقع طابعها الزمني خارج النافذة المتفاوض عليها skew_window_ms (القيمة الافتراضية الموصى بها 300 000 ms، أي خمس دقائق)، ورفض قيم request_id المكررة داخل الجلسة؛ وينبغي له رفض قيم Nonce المكررة. وينتج عن ذلك متطلب تشغيلي يُغفَل بسهولة: ساعات متزامنة على الجانبين.

سلسلة التدقيق: سلسلة تجزئة برأس منشور

يدير Guardian لكل جلسة SessionContext، وهو سلسلة من ContextEntries قابلة للإلحاق فقط (append-only). يحصل كل إدخال على entry_hash: قيمة SHA-256 على الإدخال المحوَّل معياريًا بـ JCS دون حقول التجزئة، مربوطة بتجزئة الإدخال السابق؛ ويكون previous_hash للإدخال الأول null. ولا يُسمح بتحويلات معيارية أخرى في v0.1. والحاسم هو النشر: لكل خطوة تحمل محتوى (content-bearing) يجب على Guardian أن يرفق قيمة chain_hash الحالية في استجابته، مغطاة بتوقيع الاستجابة. وتذكر المواصفة السبب صراحةً: لو أبقى Guardian رأس السلسلة سريًا، لأمكنه مثلًا حذف deny وإعادة حساب السلسلة من تلك النقطة وتقديم سجل منقّح لاحقًا. ومن يسجّل حركة البيانات يكتشف السلسلة المعاد كتابتها لاحقًا.

ما تثبته السلسلة — وما لا تثبته

• الحقول الإلزامية في ContextEntry هي فقط entry_id وstep_id وstep_type وentry_hash. أما request_hash على محتوى الطلب فهو في ACS-Core موصى به فقط (SHOULD) ولا يصبح إلزاميًا إلا في الملف التعريفي acs-audit. ومن دونه تثبت السلسلة أن خطوة ما حدثت، لكن لا تثبت ما الذي طُلب.
• لا يعرف مخطط ContextEntry حقلًا للتصرف (Disposition) أو التعليل أو الموافِق (Approver). يسجل ACS القرارات معياريًا كأحداث Trace (الملف التعريفي acs-trace، الفصل 9)؛ ولا يكتب إدخالًا خاصًا مع هوية الموافِق سوى توسيع النية (الفصل 11).
• HMAC متماثل: يحتفظ Guardian بالمفتاح وقد يعيد توقيع رأس سلسلة معاد كتابته. فالقناة محمية من التلاعب في الشبكة، لا من Guardian مخترَق.
• لا تنشأ عدم القابلية للإنكار تجاه الأطراف الثالثة إلا مع acs-crypto: على الأقل ML-DSA-65 (MUST)، وSLH-DSA-128s (SHOULD)، والأساليب الهجينة اختيارية.
• لا توجد مطابقة بين عدة Guardians في v0.1 (Issue #18، مؤجلة).

المساهمة المعيارية لـ Trace هي المفردات: أسماء Span ومفاتيح السمات وفئات الأحداث وربط حالات التصرف (Dispositions) بدرجات الخطورة. يتم النقل عبر OTLP (gRPC أو HTTP) إلى الأنظمة الخلفية القائمة؛ أما نطاق أسماء Wire trace/* فهو في v0.1.0 محجوز فقط. والهدف المعلن هو أن تندمج أحداث ACS في خطوط SIEM دون محللات خاصة. ويحمل امتدادا OTel وOCSF في المستودع حالة «Working draft». Trace هو الملف التعريفي الاختياري acs-trace. ومن يدّعيه يجب عليه لكل خطوة مدعومة أن يُخرج أحد التنسيقين على الأقل مع السمات الإلزامية، وأن يسجل كل قرار مع التصرف والمقيِّم — والتعليل إن وُجد — وأن ينقل حقائق Provenance من Hook إلى الحدث.

OpenTelemetry: Span لكل Hook، والقرارات كـ Span-Event

التسلسل الهرمي لـ Span حتمي: Root-Span باسم acs.session لكل جلسة، وتحته acs.turn لكل دورة وStep-Span لكل Hook. القرارات ليست Spans مستقلة، بل Span-Event باسم acs.decision على Step-Span؛ وبذلك يتشارك الحكم والإجراء المتحكَّم فيه سياق الأصل نفسه. السمات الإلزامية للحدث هي acs.decision وacs.evaluator (deterministic أو agent أو composite). ولاستدعاءات الأدوات يستخدم ACS اسمي Span gen_ai.tool.call وgen_ai.tool.result. تنبيه: في أعراف OpenTelemetry-GenAI (بحالة «Development» حتى أكتوبر 2026) يكون gen_ai.tool.call مجرد بادئة سمات، واسم Span الموصى به هناك هو execute_tool {gen_ai.tool.name}. لذلك لا تتوافق لوحات المعلومات والاستعلامات المبنية على هذه الأعراف مع Tool-Spans الخاصة بـ ACS دون تعديل.

حالات استخدام SIEM للوكلاء

حدود ينبغي أن تخططوا لها

• أفضل جهد (Best effort): لا يجوز لـ Trace أن يعطّل التنفيذ أبدًا. وإذا تعطلت الوجهة، يصل القرار رغم ذلك إلى Observed Agent — أي أن القياس عن بُعد قد يكون ناقصًا.
• إفادة ذاتية: تنشأ أحداث Trace في البيئة المراقَبة ولا تصبح دليلًا إلا بتصديق طرف خارجي.
• ثغرة Skills: يغطي الربط 16 من أصل 19 Hook أصليًا إضافةً إلى أسلوبي agbom. أما skillRegister وskillLoad وskillUnload فليس لها ربط OTel ولا OCSF.
• انحراف التوثيق: موضع تخزين Provenance في OCSF متناقض (enrichments في الربط المعياري، وunmapped.acs.provenance في الدليل). كما أن صفحة الأمثلة باستعلامات Splunk وElastic لا تزال تستخدم الاسم القديم ASOP وOCSF 1.0.
• حماية البيانات: قد تحتوي Spans على Prompts ووسائط الأدوات. توصي المواصفة بالتنقيح (Redaction) منذ لحظة الإصدار؛ وفي تقديرنا يجب أن يكون ذلك إلزاميًا في مفهوم التسجيل.

AgBOM وفق المواصفة مخزون ديناميكي قابل للاستعلام للمكونات التي يستخدمها Observed Agent. والتعليل دقيق: كل سياسة تعتمد على ماهية الوكيل — أي نموذج وأي أدوات — تصبح غير قابلة للتحقق دون مخزون. وإذا اعتمدت سياسة Guardian على المخزون، كحظر نموذج أو أداة، وجب على النشر تطبيق الملف التعريفي acs-inspect. وAgBOM المعيارية رسم بياني للمكونات، مخزَّن كقائمة مسطحة بمراجع عبر المعرّف، بحيث يمكن مقارنة الحالات عبر Diff.

ثمانية أنواع من المكونات

snapshot وchanged: أسلوبا Wire

يرسل Observed Agent ‏agbom/snapshot مرة واحدة لكل جلسة بعد sessionStart وقبل أول Hook يحمل محتوى؛ وتحتوي الرسالة على AgBOM الكاملة. ويبلّغ agbom/changed عن التغييرات — المكونات المضافة أو المحذوفة أو المعدلة كـ Diff أو كلقطة كاملة — ويمكن أن يحمل سببًا، مثل component_upgraded أو discovery أو user_action. ويدخل كلا الحدثين في سلسلة التدقيق. ويجوز لـ Guardian عبر deny رفض جلسة تحتوي على مكون محظور أو منع تبديل ساخن (Hot-Swap).

مهم لاختيار الملف التعريفي: من يدّعي acs-inspect فقط يقدم لقطة واحدة بالضبط لكل جلسة ولا يتتبع التغييرات. ولا تصبح تغييرات وقت التشغيل مرئية إلا مع acs-inspect-dynamic. ويشير مسبِّبا اللقطة renegotiation وpolicy_request إلى آليات لن تُحدَّد إلا مع v0.2 — ففي v0.1 لا يُعتمد عمليًا إلا على session_start. كما ينبغي أن يحمل كل مكون registration_provenance (إلزامي ضمن acs-provenance). وبذلك يمكن التمييز بين مكون مصدره الإعداد ومكون أضيف أثناء التشغيل.

التسلسلات: CycloneDX وSPDX وSWID

يُرسل على Wire دائمًا الشكل المعياري؛ ويُنتج Guardian التسلسلات عند الطلب للأدوات اللاحقة. ويجب على نشر acs-inspect أن يوفر واحدًا منها على الأقل: CycloneDX 1.6 أو SPDX 3.0 أو SWID ‏(ISO/IEC ⁦19770-2⁩). تحمل جميع عمليات الربط الثلاث حالة «Working draft»؛ والتمثيلات على CycloneDX وSPDX غير صالحة جزئيًا وفق المخطط. يستخدم ربط CycloneDX أسماء أنواع مثل ai-model أو service كنوع مكون لا يعرفها CycloneDX 1.6 بهذا الشكل؛ ويستخدم ربط SPDX فئات وعلاقات غير موجودة في SPDX 3.0.1. لذلك خططوا لعمليات التصدير مع تحقق خاص بكم. أما CycloneDX نفسه فمتاح منذ أكتوبر 2025 بالإصدار 1.7.

التمييز: AgBOM وAI-SBOM وCRA-SBOM

Provenance الحقول: حقائق بدلًا من تسميات الثقة

يجيب Provenance عن مصدر عنصر البيانات وكيف وصل إلى موضعه. يحمل كائن Provenance قيمة provenance_id، وorigin بإحدى سبع قيم — user_input، system، tool_output، retrieved، agent_generated، a2a_inbound، external — واختياريًا source_id (مثل اسم الأداة أو URL أو المسار) وderived_from كقائمة بالأسلاف. وترتبط هذه البيانات بالحقول الحاملة للبيانات، بل في toolCallRequest بكل وسيط على حدة. وبذلك يمكن لسياسة أن تستهدف تدفق بيانات محددًا بدلًا من الاستدعاء بأكمله.

• يحددها الإطار: يمنح كود حتمي خارج مسار مخرجات LLM قيم origin وsource_id وderived_from. وتوجيه LLM لإنتاج Provenance غير متوافق.
• النسب المتعدية (Transitive Lineage): ترث البيانات المشتقة مصدر مدخلاتها، حتى عبر التلخيص والضغط. وبذلك يبقى ملخص مخرجات أدوات خارجية قابلًا للتعرف عليه بصفته تلك.
• لا حقل ثقة: قيمة trust في v0.1 محجوزة فقط، دون مخطط. يستنتج Guardian الثقة من origin وsource_id مقارنةً بسياسته؛ ولا تصبح المواد غير الموثوقة موثوقة أبدًا بمعالجة LLM (قاعدة الرتابة).
• كل شيء أو لا شيء: مع provenance_producer: deterministic يجب أن يحمل كل حقل حامل للبيانات Provenance؛ والتعبئة الجزئية غير متوافقة. وإذا أبلغ العميل provenance_producer: none رغم أن السياسة تتطلب Provenance، يرفض Guardian الجلسة منذ Handshake بـ PROVENANCE_REQUIRED.

لا ينتمي Provenance إلى ACS-Core، بل إلى الملف التعريفي acs-provenance. وهو شرط مسبق لنماذج التنفيذ مثل FIDES وCaMeL وAARM، لكنه ليس شرطًا للتفويض الصرف القائم على النية (IBAC). لا يمنع ACS ‏Prompt Injection. بل ينشئ نقطة التحكم التي يمكن عندها لسياسة أن تحد من العواقب — مثلًا بحجب بريد إلكتروني يأتي مستلمه ومحتواه من نتيجة استرجاع غير موثوقة. وليست تسميات الحساسية أو IFC جزءًا من المعيار؛ بل تقع ضمن مسؤولية Guardian أو النشر.

Session Intent: الغرض المثبَّت

Intent في ACS ليس تنسيق Wire، بل مفهوم حوكمة: فهو يربط الإجراءات بغرض مفوَّض، وذلك قبل أن تتمكن البيانات غير الموثوقة من التأثير. يُحدَّد Intent.parsed، أي مجموعة القدرات المفوضة للجلسة، عند sessionStart أو عند أول agentTrigger. وبعدها لا يجوز لـ LLM ولا لمخرجات الأدوات ولا للبيانات القادمة من قنوات غير موثوقة تغييره؛ وإذا حُدد Intent عند sessionStart، وجب رفض أي agentTrigger لاحق بنية مختلفة.

الطريق المتوافق الوحيد للتوسيع هو intent_extension يعيدها موافِق عبر مسار ask — مع بيانات إلزامية عن القدرات والنطاق. مع scope بقيمة this_request يسري التوسيع على الطلب الجاري فقط. ومع scope بقيمة session يضيف Guardian القدرات، ويكتب ContextEntry من نوع intent_extension مع هوية الموافِق، ويدير Provenance التوسيع منفصلًا عن Provenance النية الأصلية. وضمن scope_mode بقيمة strict لا يجوز له قبول أي توسيع تحظره السياسة في الوضع الصارم. وفي تقديرنا، هذه بالنسبة لمسؤولي أمن المعلومات (CISO) الرافعة ضد التوسع التدريجي للصلاحيات: فكل توسيع يحتاج إلى موافقة موثَّقة الهوية.

الهوية: معياريًا محدودة، والكثير قيد العمل

يصادق توقيع ACS-Core القناة بين Observed Agent وGuardian بشكل متماثل. وهو ليس مصادقة للجهة الأصيلة (Principal) ولا عدم قابلية للإنكار — ولا ينبغي لكم الخلط بينهما في البنية وأدلة الإثبات.

تغليف MCP: محدد، مع سؤال مفتوح حول الإلزام

نطاق الأسماء protocols/MCP/* هو الطريق المعياري لنقل رسائل MCP إلى Guardian، مثل protocols/MCP/tools/call. تبقى رسالة MCP دون تغيير؛ ويضع ACS فوقها Envelope وعقد القرار وقواعد سلسلة التدقيق. يتم المسار على مرحلتين: يعرض الوكيل الطلب المغلَّف على Guardian، وينفّذ قراره، ويمرر الرسالة وفق وصف المسار بعد allow إلى خادم MCP، ويُخضع إجابته أيضًا للفحص قبل معالجتها.

يجوز للنشر دمج استدعاءات أدوات MCP ‏(tools/call) في الـ Hooks العامة steps/toolCallRequest وsteps/toolCallResult إذا كانت السياسات على مستوى الأداة كافية. وينبغي استخدام التغليف عندما تحتاج السياسة إلى فروق خاصة بـ MCP: التفاوض على القدرات عند initialize، وقوالب Prompt من جانب الخادم (prompts/get)، والوصول إلى الموارد (resources/read)، والإشعارات (notifications/*). وبمعزل عن ذلك: يجب على أطر العمل إطلاق toolCallRequest لكل إجراء يغادر سياق الاستدلال — بما في ذلك عمليات الملفات أو الشبكة أو Shell المدمجة.

MCP ⁦2026-07-28⁩: نص المواصفة متأخر عن الركب

منذ 28.07.2026 أصبحت مراجعة MCP ‏⁦2026-07-28⁩ هي الحالية (حتى أكتوبر 2026). وهي تجعل نواة البروتوكول عديمة الحالة (Stateless)، وتلغي Handshake الخاص بـ initialize، وتعلن من بين أمور أخرى أن Sampling وRoots متقادمة. نطاق الأسماء protocols/MCP/* في ACS محايد تجاه الإصدارات؛ ولا تظهر المراجعة ⁦2025-06-18⁩ في المواصفة إلا كمثال. غير أن النص لا يزال يفترض الدلالات الأقدم ويذكر صراحةً التفاوض عند initialize كنقطة ينبغي التحكم فيها. وتترك المواصفة مفتوحًا ما إذا كان ذلك يؤثر عمليًا على أدوات التغليف؛ ولا يتوفر لدينا تحليل موثوق. وفي تقديرنا، ينبغي للبنى المعتمدة بكثافة على MCP أن تخطط لاعتماد Tool-Hooks العامة نقطةَ تحكم أساسية.

A2A: محجوز لـ v0.2

نطاق الأسماء protocols/A2A/* في v0.1 محجوز فقط؛ ودلالات التغليف المعيارية مقررة لـ v0.2 (الموعد المستهدف لـ v0.2.0: مارس 2027). وصفحات A2A في المستودع تعود إلى حقبة AOS عام 2025 وليست متوافقة مع المخطط. ولا تظهر علاقات A2A اليوم إلا بشكل غير مباشر: عبر agentTrigger مع trigger_type بقيمة a2a_inbound وعبر مكونات a2a_peer في AgBOM. أما الوكلاء الفرعيون داخل العملية فيغطيهم ACS عبر subagentStart وsubagentStop؛ إذ يحصل كل وكيل فرعي على جلسة خاصة بسلسلة تدقيق خاصة، يشير إليها الأصل عبر final_chain_hash دون دمج السلاسل.

دورة حياة Skill: ‏register وload وunload

يغطي Digest الأداة القابلة للتحميل بالكامل، بما في ذلك أوزان النماذج أو المحوّلات (Adapters) المضمَّنة؛ ولا يُحفظ في AgBOM سوى المرجع وDigest، لا المحتوى. ولا ينبغي لـ Guardian أن يعتمد على digest_verified الذي يبلّغ عنه إطار العمل، بل أن يقارن بنفسه مع موافقته. ويسمي مقترح التصميم الخاص بدورة حياة Skill في المستودع الحد صراحةً: يربط Digest الأداة المسجلة، لا الكود الذي تحمّله Skill لاحقًا — إذ يمر هذا التحميل اللاحق بوصفه network.egress أو process.execute عبر Tool-Hooks الاعتيادية. وفحص Marketplace قبل النشر ليس جزءًا من ACS، ولا يزال ربط Trace مفقودًا للـ Hooks الثلاثة الخاصة بـ Skills (الفصل 9).

ACS مشروع ضمن OWASP GenAI Security Project، ومصنَّف وفق بيانات OWASP-Nest الوصفية الخاصة به في المستوى 2 ‏(Incubator)؛ ويصف قائد المشروع الوضع بأنه «public preview». وACS ليس معيار ISO ولا IETF ولا W3C، وليس كذلك معيارًا منسَّقًا.

ما يقدمه v0.1 بالفعل

رغم المرحلة المبكرة، يقدم v0.1 مضمونًا: مفردات مشتركة من 19 Hook وخمس حالات تصرف (Dispositions)، و44 مخطط JSON منشورًا، ووضعية فشل (Failure Posture) موصوفة بوضوح مع التزام تدقيق لكل تجاوز، ومواصفة تسمي ثغراتها صراحةً. وفي تقديرنا، يكفي ذلك لقياس المورّدين بمعيار مفتوح ومشترك، ولتصميم نقاط التحكم الخاصة بحيث تبقى متوافقة مع الإصدارات اللاحقة — لكنه لا يكفي للاعتماد على ملصقات التوافق.

التوافق إعلان ذاتي

في Handshake يعلن Observed Agent الملفات التعريفية التي يدعمها (profiles_supported)، ويعلن Guardian ما يقبله (profiles_accepted). وهناك سبعة ملفات تعريفية بالضبط: acs-core إلزاميًا، إضافةً إلى acs-trace وacs-inspect وacs-inspect-dynamic وacs-provenance وacs-crypto وacs-audit. ولا توجد درجات أو مستويات. أما من يتحقق من ادعاءات التوافق، فتجيب المواصفة نفسها: في v0.1.0 لا أحد. لا توجد مجموعة اختبارات، ولا سجل للتطبيقات المتوافقة، ولا جهة تفصل في الادعاءات المتنازع عليها (Issue #19، مفتوحة، الأولوية P1). كما أن ACS-Core لا يضمن سوى أمرين — قناة موثَّقة، والتزام Observed Agent بقرارات Guardian. ولا يضمن سياسات صارمة: فحتى Guardian متساهل يكون متوافقًا.

التطبيق المرجعي: الوضع الفعلي بصراحة

التطبيق المرجعي الوحيد هو صراحةً إثبات مفهوم. فهو يشغّل Agent Governance Toolkit ‏(AGT) من Microsoft دون تعديل بوصفه محرك سياسات خلف ACS-Wire، مع ربط بمضيفَي Claude Code وOpenCode. ولا يدّعي acs-core إلا بشكل مقيَّد («qualified») ولا أيًّا من الملفات التعريفية الستة الاختيارية. ولا يتوفر معيار مقارنة لقابلية التشغيل البيني مع AGT؛ فهو هدف نافذة الـ 90 يومًا منذ الانطلاق في 10.09.2026. ولا يمكن أن يُستنتج من ذلك دعم Microsoft لـ ACS. تنبيه لتشابه الأسماء: في توثيق AGT يشير «ACS» إلى «Agent Control Specification» الخاصة بـ Microsoft ‏(02.06.2026)، وهي لغة السياسات في AGT — لا إلى معيار OWASP.

ثغرات مفتوحة في المواصفة ذات أهمية عملية

• الإعداد الافتراضي fail-open: يكون on_decision_failure ووضعية بدء التشغيل على proceed؛ ويجب عليكم إعداد fail-closed ‏(deny أو refuse) عن وعي.
• لا آلية إيقاف: لا يعرف v0.1 مفتاح إيقاف طارئ (Kill-Switch)؛ والمقاطعة (interruption) والبث (Streaming) مقرران لـ v0.2. وفي v0.1 لا يُوقَف الوكيل إلا تدريجيًا عبر deny.
• نطاق الإلزام في تحوّل: من شأن اقتراح مفتوح (PR #21) أن يخفض modify وsystem/ping إلى SHOULD.
• ثغرات التشغيل البيني (تحليل خاص): معلمات HKDF وتوقيع Handshake ومدخلات request_hash غير محددة بما يكفي.
• انحراف التوثيق: لا تزال بعض الصفحات تذكر 16 بدلًا من 19 Hook أو ثلاث حالات تصرف فقط. والمعياري هو المواصفة والمخططات.

ثلاثة تصنيفات مسبقة. أولًا، لا يؤسس ACS أي افتراض للتوافق؛ ولا يتضمن نص المواصفة أي ربط بـ AI Act أو NIS2 أو DORA أو CRA أو ISO/IEC 42001 — وكل عمليات الربط أدناه استنتاجات من VamiSec. ثانيًا، وكلاء الذكاء الاصطناعي ليسوا بحد ذاتهم أنظمة عالية المخاطر. وتسري التزامات المخاطر العالية الواردة في الفصل III الأقسام 1–3 من اللائحة (EU) 2024/1689 بعد Digital Omnibus ‏(اللائحة (EU) 2026/1744) اعتبارًا من 02.12.2027 للملحق III واعتبارًا من 02.08.2028 للملحق I؛ وتسري المادة 50 منذ 02.08.2026. ثالثًا، تتوقف كل حجة على الملفات التعريفية: إذ لا يتضمن ACS-Core وحده Trace ولا AgBOM ولا request_hash.

مدخل من خمس خطوات

1. 1
   الجردحصر الوكلاء وتصنيفهم

   احصروا الوكلاء والنماذج والأدوات وخوادم MCP وSkills، وحدّدوا لكل استخدام التصنيف وفق AI Act. النتيجة: سجل للوكلاء مع فئة المخاطر والمسؤولين والوصول إلى البيانات.

2. 2
   البنيةتحديد نقاط التحكم والملفات التعريفية

   تحققوا من الـ Hooks التي تطلقها منصتكم فعليًا، ومن تلك التي يؤكدها Guardian في Handshake ضمن methods_evaluated: كل ما عدا ذلك يُعدّ allow-by-default وغير محمي. اختاروا الملفات التعريفية وفق حاجة الإثبات، مثل acs-core إضافةً إلى acs-trace وacs-audit لالتزامات التسجيل.

3. 3
   السياسةصياغة السياسات ككود

   تعمل الطبقة الحتمية أولًا (مرجع v0.1: ‏OPA/Rego). صيغوا قواعد للأوامر التدميرية وEgress والمدفوعات، واشترطوا للإجراءات ذات العواقب ask مع موافِق بشري وtimeout_disposition بقيمة deny، وأشيروا إلى إصدارات السياسات في policy_references.

4. 4
   التشغيلتحديد وضعية الفشل واختبارها

   اضبطوا للوكلاء ذوي إمكانات الضرر العالية on_decision_failure على deny ووضعية بدء التشغيل على refuse. اختبروا تعطل Guardian وإعادة الإرسال وأخطاء التوقيع، وراقبوا حالات فشل القرار مباشرةً، لأن نجاح Ping لا يثبت سلامة التنفيذ.

5. 5
   دليل الإثباتربط Trace وتوثيق أدلة الإثبات

   صدّروا OCSF أو OpenTelemetry إلى SIEM، وطبّقوا حالات الاستخدام من الفصل 9، وحدّدوا فترات الاحتفاظ. أمّنوا رأس السلسلة خارجيًا، وتحققوا من بيانات التوافق لدى المورّدين عبر اختبارات خاصة بكم.

تقدم الورقة البيضاء لمسؤولي أمن المعلومات «Agent Control für CISOs» تعمقًا يتضمن برنامج 100 يوم ونموذج أدوار ومؤشرات وأسئلة تقييم لمنصات الوكلاء، ويمكنكم طلبها أدناه في هذه الصفحة. ترافق VamiSec التقييم والبنية وتصميم السياسات والاختبارات بوصفها جهة استشارية مستقلة؛ وVamiSec ليست جزءًا من مشروع ACS.