آليات الأمان في A2A: نظام بوابات الثقة المتبادلة بين الوكلاء الأذكياء

عندما يتصل وكيلان ذكيان ببعضهما “هاتفيًا”، ما أكثر ما نخشاه؟ ليس استمرار حديثهما بلا نهاية، بل دخول شخص غريب يتظاهر بأنه معروف.

مبدأ التصميم الأمني: أغلق الباب أولًا ثم افتحه

تخيّل أنك انتقلت إلى منزل جديد، أول ما تفعله ليس تعليق الستائر، بل تغيير قفل الباب. مصممو بروتوكول A2A فكروا بنفس الطريقة — الآمن افتراضيًا، وكل توسيع للصلاحيات يتطلب إجراءً صريحًا. هذه الآلية تشبه نظام بوابات متكامل: قفل الباب (token)، بطاقة الدخول (مفتاح النظير)، ثقب الباب (التحقق من الهوية)، كاميرا المراقبة (سجلات التدقيق). في منصة رسائل Hermes، تأتي ميزة A2A كإضافة (plugin)، لكن الإعدادات الأمنية الافتراضية لا تتنازل أبدًا: عند عدم تكوين token، يستمع الخادم فقط على العنوان المحلي 127.0.0.1 — وكأن الباب مقفل والمفتاح في يدك وحدك.

تفصيل خطوط الدفاع الأربعة

الخط الأول: الربط المحلي + token (قفل الباب)

افتراضيًا، يستمع A2A على الجهاز المحلي فقط، ولا يمكن للعالم الخارجي الوصول إلى الباب إطلاقًا. لتقديم خدمة للخارج، يجب توفر شرطين معًا: تعيين A2A_HOST لعنوان التعرض، وتكوين bearer token. هذا يشبه أنك لا تفتح النافذة فحسب، بل تضع أيضًا صبارًا شائكًا على حافة النافذة — كلاهما لا غنى عنه.

الخط الثاني: مفتاح مستقل لكل نظير (بطاقة دخول)

لكل نظير token خاص به، يُكوَّن عبر A2A_PEER_TOKENS="alice:tok1,bob:tok2". هذا ليس مفتاحًا رئيسيًا يفتح كل الأبواب، بل بطاقة دخول مستقلة لكل زائر. الهوية المصادق عليها تقود تحديد المعدل (rate limiting)، وقوائم الثقة، والتدقيق — من مرر البطاقة، وكم مرة، ومتى، كل ذلك مسجل.

الخط الثالث: تصفية الحقن + إخفاء البيانات (بوابة التفتيش الأمني)

النصوص الواردة تُصفى وتُوسم بأنها “مدخلات من نظير غير موثوق”، ولا يمكن للنظير البعيد استدعاء أوامر المشغل المائلة (slash commands). هذا يشبه تفتيش المطار، حيث يجب إخراج السوائل من الحقيبة لفحصها منفردة. في الردود الصادرة، تُمسح تلقائيًا السلاسل التي تشبه بيانات الاعتماد (مفاتيح API، JWT، token) — وكأن الرسائل البريدية الصادرة تُخفي تلقائيًا رقم الهوية الوطنية للمستلم.

الخط الرابع: سجلات التدقيق + منع الحلقات (كاميرا المراقبة)

كل تبادل يُلحق بملف ~/.hermes/a2a_audit.jsonl، وكأن باب المنزل مزود بكاميرا مراقبة على مدار الساعة. أما حد الجولات لمنع الحلقات فيشبه جهاز الاتصال الداخلي عند جارك — إذا استمر وكيلان في الحديث بلا نهاية، يقوم النظام بقطع الاتصال تلقائيًا.

قصص هجمات حقيقية: 3 مشكلات اكتشفها المجتمع وأصلحها

القصة الأولى: تجاوز SSRF (#78298) — خداع قفل الباب بـ“رمز رقمي”

اكتشف مهاجم أن فحص الأمان لعنوان URL لمعاودة الاتصال (callback) يستخدم مطابقة بادئة السلسلة النصية لاسم المضيف، مثل التحقق مما إذا كان يبدأ بـ 127.. لكن عنوان IP له “تهجئة صحيحة” — 2130706433 هي طريقة أخرى لكتابة 127.0.0.1. هذا يشبه كتابة رقم المنزل بشفرة مورس، فلا يتعرف عليه الحارس ويسمح بالدخول. الإصلاح: تحليل مضيف المعاودة إلى IP قياسي أولًا ثم الحكم، وكأن الحارس يترجم أي شكل من أشكال العنوان إلى رقم منزل قياسي قبل المقارنة.

القصة الثانية: انهيار الهوية خلف الوكيل العكسي (#80534/#80779) — الجميع يصبح شخصًا واحدًا

عند النشر خلف nginx أو K8s، تستنتج إضافة A2A هوية المتصل من عنوان socket. لكن الخادم الوكيل يقف في المنتصف، فيظهر جميع النظائر بنفس عنوان IP — عنوان الوكيل. هذا يشبه كشك الأمن في مبنى سكني، حيث يُسجل جميع الزوار باسم “توقيع كشك الأمن”. تحديد المعدل يتشارك في حاوية واحدة (انشغال واحد يعطل الجميع)، وقائمة الثقة لا يمكن ملؤها إلا بعنوان الوكيل، والتدقيق لا يرى المتصل الحقيقي. الإصلاح: استنتاج الهوية الحقيقية من X-Forwarded-For، ولكن فقط بعد التأكد من أن الطلب جاء “خلف وكيل موثوق”.

القصة الثالثة: ثغرة التدقيق (#81003/#81042) — طرق الباب المرفوض لا يُسجل

سجلات التدقيق تسجل فقط الحركة المقبولة. طلبات 401 (token غير صالح) و403 (غير موثوق) لا تولد أي سجل. هذا يشبه كاميرا مراقبة تصور فقط من يدخل بنجاح، بينما لا تُسجل مشاهد محاولة كسر القفل. هجمات حشو البيانات (credential stuffing)، وفحص tokens الملغاة، ومحاولات الحركة الجانبية — هذه السلوكيات الهجومية هي بالضبط ما يحتاجه التدقيق لالتقاطه. الإصلاح: جميع حالات رفض المصادقة تُلحق أيضًا بسجل تدقيق غير قابل للتعديل (append-only)، مع حقل decision + رمز حالة HTTP + عنوان IP للمتصل.

ماذا يعني ذلك للمستخدم

المنطق الأساسي لهذه الآلية هو: الأمان ليس إصلاحًا لاحقًا، بل حالة افتراضية. كمستخدم لـ Hermes، لا تحتاج إلى أن تكون خبيرًا أمنيًا لتحصل على حماية أساسية — خطوط الدفاع الأربعة تعمل تلقائيًا. الأهم من ذلك، أن المجتمع يواصل تقوية النظام في مواجهة الهجمات الحقيقية: من تجاوز SSRF إلى انهيار الهوية خلف الوكيل العكسي، وصولًا إلى ثغرة التدقيق، كل مشكلة تقابل سيناريو حقيقيًا. بروتوكول A2A يشبه قلعة تتعزز باستمرار، كل لبنة فيها خضعت لاختبارات ميدانية. في المرة القادمة التي يتصل فيها وكيلان ذكيان ببعضهما “هاتفيًا”، لن يكون بينهما فقط قفل الباب وبطاقة الدخول وبوابة التفتيش وكاميرا المراقبة، بل أيضًا حراس يراقبون السجلات باهتمام.