خدمة أسماء الوكلاء من مؤسسة لينكس: كيف تعمل هوية وكلاء الذكاء الاصطناعي المرتكزة على DNS ومتى تعتمدها

خدمة أسماء الوكلاء (Agent Name Service أو ANS) من مؤسسة لينكس (Linux Foundation) معيار مفتوح يمنح وكلاء الذكاء الاصطناعي أسماءً ذات إصدارات مرتكزة على DNS، وشهادات هوية تُصدر بعد التحقق من النطاق، وقيودًا عامة في سجلات الشفافية. لماذا ينبغي أن يهتم قائد تقنية المعلومات بذلك؟ لأن وكلاء الذكاء الاصطناعي باتوا يستدعون وكلاء آخرين، ويطلبون البيانات، ويطلقون المعاملات عبر حدود المؤسسات. ولا يستطيع أحد أن يجزم بعد بما إذا كانت ANS ستصبح المخطط السائد.

ما خدمة أسماء الوكلاء، ولماذا هي تحت مظلة مؤسسة لينكس؟

في 10 نوفمبر 2026، رحّبت مؤسسة لينكس بخدمة أسماء الوكلاء معيارًا مفتوحًا للهوية الموثوقة لوكلاء الذكاء الاصطناعي والتحقق منهم واكتشافهم باستخدام بنية DNS التحتية القائمة. تمتد المواصفة الكاملة على سبعة مستندات تغطي التسمية المرتكزة على النطاق، والتسجيل وإدارة الإصدارات، والنشر في DNS، وتدقيق السجلات العامة، ومراقبة السلامة، والمصادقة بين الوكلاء. وتتولى اللجنة التوجيهية التقنية للمشروع تطويره الآن بشكل علني.

منذ الإعلان عن نية الإطلاق في يونيو 2026، ساهمت 11 مؤسسة في المعيار أو اعتمدته، من بينها Cisco وCloudflare وDigiCert وGoDaddy وInfoblox وSalesforce وOWASP.

بدأت ANS في GoDaddy. اختار الفريق بناء اكتشاف الوكلاء على DNS، الذي تقول GoDaddy إنه يعالج أكثر من مئة مليون طلب في الثانية، وترسيخ الثقة عبر البنية التحتية للمفاتيح العامة (PKI) نفسها التي تؤمّن كل اتصال HTTPS. ويعيد هذا البناء استخدام بنية DNS التحتية لدى GoDaddy وخدمة شهادات تدير أكثر من 100 مليون شهادة SSL وTLS نشطة.

بالنسبة إلى مشتري المؤسسات، فإن خطوة الحوكمة هي الجزء الأهم. فالمواصفة العامة تحت مظلة مؤسسة محايدة تمنحك أرضية أصلب لصياغة السياسات. وقد عبّر جيم زملين (Jim Zemlin)، الرئيس التنفيذي لمؤسسة لينكس، عن ذلك بوضوح: وكلاء الذكاء الاصطناعي المستقلون يُجرون معاملات عبر أنظمة عالمية، لكنهم لا يستطيعون النجاح من دون هوية قابلة للتحقق.

لماذا أصبحت هوية وكلاء الذكاء الاصطناعي مشكلة حوكمة لتقنية المعلومات

يمكنك أن ترى الضغط داخل المؤسسات بالفعل. فقد وجد استطلاع أجراه تحالف أمن السحابة (Cloud Security Alliance) وشمل 418 متخصصًا في تقنية المعلومات والأمن، بتكليف من Token Security ونُشر في أبريل 2026، أن 82% من المؤسسات اكتشفت وكلاء ذكاء اصطناعي يعملون في بنيتها التحتية دون علم أحد. ووجد الاستطلاع نفسه أن 65% تعرضت لحادث أمني مرتبط بالوكلاء خلال الأشهر الـ12 السابقة. ومن بين المؤسسات التي تعرضت لمثل هذا الحادث، أفادت 61% بانكشاف بيانات و35% بخسائر مالية. وهاتان النسبتان حصتان من الـ65% التي تعرضت لحادث، لا من جميع المشاركين.

اقرأ الاستطلاع مع مراعاة تحفظين. فقد كلّفت به جهة بائعة، وهو يقيس الرؤية الداخلية أكثر مما يقيس الهوية الخارجية. ومع ذلك يُظهر أن انتشار الوكلاء غير المنضبط مشكلة تشغيلية قائمة، لا افتراضية.

أسهل طريقة لتصوّر الجانب الخارجي هي السيناريو الوارد في مسودة ANS v2 لدى IETF. يتلقى وكيل الدفع لدى إحدى الشركات تعليمات بتحويل 50,000 دولار إلى وكيل الفوترة لدى أحد الموردين، ويقدّم وكيل الفوترة عنوان URL لموقع ويب مؤمَّن بشهادة TLS. تخبر تلك الشهادة وكيلَ الدفع بأن جهةً ما تتحكم في النطاق. وبالنسبة إلى نظام على وشك إرسال الأموال من تلقاء نفسه، فإن التحكم في النطاق دليل ضعيف.

كيف تعمل ANS: أسماء ذات إصدارات، وشهادات موثقة، وسجلات شفافية

تأخذ ANS آليات يعرفها بالفعل كل من يدير بنية تحتية للويب، وتضيف فوقها مستويات تحقق.

أسماء ans:// ذات الإصدارات

يحصل كل وكيل على اسم ذي إصدار بأسلوب DNS مثل ans://v1.0.0.my-agent.example.com. اقرأه من اليمين إلى اليسار. يربط النطاق (example.com) الوكيل بمؤسسة، ويحدد الوسم (my-agent) الوكيل نفسه، وتثبّت البادئة (v1.0.0) إصدارًا دلاليًا. ولا يحتوي عنوان URL العادي على ما يشبه هذا الجزء الأخير. ومع ANS، يمكن أن يظهر أي تغيير في الوكيل على هيئة تغيير في اسمه.

تحدد مسودة ANS v2 حدًا أقصى لاسم ANSName الكامل يبلغ 400 ثُمانية (octet)، ما يترك هامشًا للنقل الآمن عبر ترويسات HTTP وحقول TLS وأعمدة قواعد البيانات. ويمكن لأنظمتك الحالية تخزين هذه الأسماء وتمريرها دون معالجة خاصة.

شهادات الهوية بعد التحقق عبر DNS/ACME

لا تُصدر شهادة هوية ANS إلا بعد التحقق من النطاق عبر DNS/ACME. ومن الناحية التشغيلية، لا جديد هنا. أما المأخذ، الذي نعود إليه في قسم التحفظات، فهو أن هوية الوكيل لا يمكن أن تكون أقوى من التحكم في النطاق الذي تستند إليه.

سجل الشفافية العام

ينتج عن كل تسجيل أيضًا قيد عام في سجل الشفافية، بحيث يستطيع أي طرف التحقق بشكل مستقل من هوية الوكيل وقدراته وتاريخه دون الوثوق بوسيط.

مستويات التحقق البرونزي والفضي والذهبي

تعرّف مسودة ANS v2 ثلاثة مستويات للتحقق: البرونزي (Bronze) ويعتمد على PKI، والفضي (Silver) ويعتمد على PKI مع DANE، والذهبي (Gold) ويعتمد على PKI مع DANE مع سجل الشفافية، كي يتمكن العملاء من اختيار مستويات ضمان تناسب مخاطر المعاملة. يربط DANE معلومات الشهادة بسجلات DNS ويعتمد على DNSSEC. تذكّر هذه التبعية، فسنعود إليها لاحقًا.

يمثل العمود الأخير توصيتنا وليس جزءًا من المواصفة. حدّد عتباتك الخاصة.

علاقة ANS بـ DNS-AID وAGNTCY Directory

ليست ANS مشروع الوكلاء الوحيد القائم على DNS في مؤسسة لينكس. فقد انطلق DNS-AID، وهو مشروع منفصل لاكتشاف الوكلاء بطريقة لا مركزية، بأعضاء أوائل هم Cloudflare وCSC وEquinix وGoDaddy وIDC وIndeed وInfoblox وInternet Systems Consortium وWWT.

يجيب المشروعان عن أسئلة مختلفة. إذ تنص مسودة DNS-AID على أن المستهلكين يجب أن يتعاملوا مع سجلات DNS-AID بوصفها وسيلة نقل قابلة للتحقق للبيانات الوصفية، لا بوصفها إشارة ثقة بحد ذاتها، وأن أحكام الثقة يجب أن تُتخذ خارج النطاق (out of band) عبر الجمع بين تلك السجلات وأنظمة السمعة أو الإثبات أو السياسات المؤسسية. وANS مرشحة لتكون طبقة الهوية تلك. فهي تعمل جنبًا إلى جنب مع DNS-AID ولا تحل محله.

يوضح مشروع AGNTCY Directory سبب الاهتمام المتزايد بـ ANS. ففي ذلك المشروع مهمة كبرى (epic) مفتوحة تتابع التحقق من مطالبات هوية ans://، وتشير إلى أن كل مخطط آخر يتطلب من الناشر استضافة مواد المفاتيح، مثل ملف JWKS أو سجل TXT أو مستند DID، وأن أحدًا تقريبًا لا يفعل ذلك، فلا يُتحقق من شيء. أما تسجيل ANS فينتج بالفعل شهادة هوية ومؤشرًا في DNS وإدخالًا في سجل الشفافية. بعبارة أخرى، يتوفر الدليل افتراضيًا بدلًا من أن يعتمد على قيام الناشرين بعمل إضافي.

لا يزال المجال مزدحمًا. ففي يونيو 2026، أحصى موقع The New Stack أربع مبادرات على الأقل قائمة على DNS، من بينها DNS-AID من Infoblox، وباتت Infoblox تدعم ANS أيضًا. أما المقترح المنافس DNSid فهو مسودة إنترنت (Internet-Draft) فردية لمؤلف واحد لم تعتمدها أي مجموعة عمل، وتنتهي صلاحية نسختها الحالية في 31 ديسمبر 2026.

متى تسجّل وكلاءك: سُلّم Optijara «المرساة-الإصدار-المستوى»

يصف الاسم التسلسل. ارسِ كل وكيل على نطاق ستحتفظ به، وحدّث إصداره بما يتماشى مع عمليات الإطلاق لديك، وامنح كل حالة استخدام مستوى تحقق. وتعتمد كل درجة على الدرجة التي تحتها، لذا فإن الترتيب مهم. هذا إطار للتخطيط، وليس تقريرًا عن نتائج عملاء.

1. الجرد والتصنيف. أدرج كل وكيل تشغّله وصنّفه: داخلي فقط، أو موجّه للشركاء، أو عام، أو خاص بالمعاملات. ونظرًا لكثرة المؤسسات التي تكتشف وكلاء لم تكن تعلم بوجودهم، توقّع مفاجآت هنا.
2. ابدأ بالوكلاء الخارجيين وعاليي المخاطر. سجّل أولًا الوكلاء الذين يستدعيهم وكلاء مؤسسات أخرى، إضافة إلى كل ما يمس المدفوعات أو مشاركة البيانات أو الإجراءات التعاقدية. ويمكن للوكلاء الداخليين فقط الانتظار، لأن ضوابط الهوية والوصول الحالية لديك تغطيهم بالفعل.
3. المرساة: اختر النطاق عن قصد. استخدم نطاق علامة تجارية ستحتفظ به لسنوات، لا نطاق حملة. وتعامل مع انتهاء صلاحية نطاق علامتك التجارية بوصفه حدثًا أمنيًا، لأن سلطة التسجيل تلغي التسجيلات عند فشل التحقق من النطاق.
4. الإصدار: اربط الأسماء بعمليات الإطلاق. اربط الإصدار الدلالي في كل اسم ans:// بعملية الإطلاق لديك. ويجب أن يُنتج أي تغيير جوهري في التعليمات (prompts) أو الأدوات أو النماذج أو الصلاحيات إصدارًا جديدًا وإدخالًا جديدًا في السجل.
5. جرّب خارج بيئة الإنتاج. نفّذ التسجيل والتحقق في بيئة اختبار أولًا، واقرأ التحفظ المتعلق بالنضج أدناه قبل أن يعتمد أي قرار ثقة في بيئة الإنتاج على ANS.
6. المستوى: حدّد مستويات الضمان والمسؤولين. حدّد المستوى المستهدف لكل حالة استخدام، وعيّن مسؤولين عن تجديد الشهادات وسجلات DNS ومراقبة سجل الشفافية. واجعل الأشخاص أنفسهم مسؤولين عن الأسرار التي يحتفظ بها كل وكيل. فمعرفة هوية الوكيل لا تحدّ مما يمكنه الوصول إليه، وأنماط مثل وكيل بيانات اعتماد يُبقي مفاتيح API بعيدًا عن وكلاء الذكاء الاصطناعي تعالج تلك الطبقة المنفصلة.

استخدام هويات ANS في المشتريات وقوائم السماح وقت التشغيل

في المشتريات

تمنح ANS فرق المشتريات مفردات ملموسة لهوية الوكلاء. وهذه أسئلة تستحق أن تطرحها على البائعين:

• هل لوكلائكم أسماء ans://، وما النطاق الذي ترتكز عليه؟
• ما مستوى التحقق الذي يمكنكم دعمه اليوم: البرونزي أم الفضي أم الذهبي؟
• هل منطقة الارتكاز موقّعة بـ DNSSEC، بحيث تكون لفحوص DANE قيمة فعلية؟
• كيف ترتبط إصدارات الوكلاء بإصدارات منتجاتكم وسجلات التغييرات؟
• من المسؤول في مؤسستكم عن تجديد النطاق والوصول إلى حساب المسجّل؟

ينبغي أن تشترط العقود إشعارًا مسبقًا قبل تغييرات إصدارات الوكلاء التي تغيّر قدراتهم، وقبل أي تغيير في نطاق الارتكاز أو المسجّل. فهذه هي الأحداث التي تغيّر ما وافقت عليه فعلًا.

مصفوفة قرار البائعين

لفرز إجابات البائعين، نستخدم مصفوفة بسيطة مبنية على ثلاث إشارات. ومثل ربط المستويات، فهي تمثل رأينا وليست جزءًا من المواصفة.

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

وقت التشغيل

في وقت التشغيل، تتحول درجة المستوى إلى قاعدة إنفاذ. أدرج الوكلاء في قوائم السماح باسم ANSName الكامل ذي الإصدار مع فحوص الشهادة، ولا تعتمد أبدًا على عنوان URL أو النطاق وحده. فإن تجاهلت الإصدار، يرث وكيلٌ تغيّر جوهريًا موافقةً منحتها لنسخة أقدم منه. اشترط المستوى الذهبي، بما في ذلك فحص سجل الشفافية، للإجراءات عالية المخاطر مثل المدفوعات، ولا تقبل المستوى البرونزي إلا لعمليات البحث منخفضة المخاطر. وهذا يتوافق مع مقصد المسودة نفسها في أن يوائم العملاء مستوى الضمان مع مخاطر المعاملة.

لن يوقف التحقق الذهبي وكيلًا محدد الهوية بشكل صحيح إذا بدأ يسيء التصرف. لذا اقرن متطلبات المستوى الذهبي بطريقة مُختبرة لإيقاف الوكيل بسرعة، وراجع ما يوقفه مفتاح الإيقاف الطارئ للذكاء الاصطناعي وما يظل دليل تشغيل وكلائك بحاجة إليه.

ادمج فحوص ANS مع ضوابط السياسات والسمعة الخاصة بك. فمبدأ «خارج النطاق» الوارد في مسودة DNS-AID ينطبق هنا أيضًا: دليل الهوية يغذّي القرار، لكنه ليس القرار. راقب سجلات الشفافية بحثًا عن تسجيلات غير متوقعة تحت نطاقاتك، وانتبه للتسجيلات على نطاقات تشبه نطاقاتك، إذ يستطيع من يملك نطاقًا مشابهًا تسجيل وكيل موثّق بالكامل عليه.

إذا كان ما يقلقك هو وصول مساعدي الذكاء الاصطناعي إلى مواقعك الإلكترونية، لا الاستدعاءات بين الوكلاء، فأنت بحاجة إلى مجموعة مختلفة من الضوابط؛ راجع دليلنا حول السماح لمساعدي الذكاء الاصطناعي بالوصول إلى موقعك أو تقييدهم أو حظرهم.

تحفظات وانتقادات يجب موازنتها قبل الالتزام

الثقة الموروثة من DNS

يحدد تحليل تحالف أمن السحابة DNSSEC بوصفه التبعية التي تعتمد عليها ANS أكثر من غيرها لجعل الروابط بين الأسماء والمفاتيح كاشفةً لأي تلاعب. وبعد عقدين من طرحه، يُتحقق من DNSSEC على نحو ثلث مسارات الاستعلام تقريبًا، لكنه موقّع تشفيريًا على نحو سبعة بالمئة فقط من المناطق. لذا يعتمد ضمان المستويين الفضي والذهبي على ما إذا كان الطرف المقابل قد أنجز أعمال DNSSEC التي لم تمنحها مؤسسات كثيرة أولوية قط. افحص مناطقك قبل أن تعد شركاءك بمستوى لا يمكنك تقديمه.

النضج

وفقًا لمراجعة تحالف أمن السحابة في يونيو 2026، كان المشروع في مرحلة ما قبل الإصدار 1.0، وكان تطبيقه المرجعي يستخدم تشفيرًا وهميًا لأغراض العرض بدلًا من PKI بمستوى الإنتاج. التشفير الوهمي مناسب للتعلّم، لكنه غير مناسب للتعامل مع الأموال. قد تسرّع حوكمة المؤسسة عملية التحصين، لكن تحقّق من الحالة الراهنة مباشرة في منظمة المشروع على GitHub بدلًا من الافتراض.

حوافز المسجّلين

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

النطاقات المشابهة والمنتحلون الموثّقون

يربط التحقق الوكيلَ بنطاق، لكنه لا يستطيع أن يخبرك بأن النطاق يعود إلى الجهة التي تظنها. لا تعالج ANS انتحال النطاقات عبر الأخطاء الإملائية (typosquatting)، والوكيل الموثّق بالكامل على نطاق مشابه يظل منتحلًا. وتبقى مراقبة العلامة التجارية وفحوص اعتماد الأطراف المقابلة من مسؤوليتك.

الرؤية المتوازنة

الإيجابيات حقيقية. فالمواصفة علنية وموزعة على سبعة مستندات. وقد ساهمت فيها أو اعتمدتها إحدى عشرة مؤسسة من بائعي الشبكات والأمن والشهادات وخدمات SaaS. ونرى أن هذا الدعم إلى جانب الحوكمة المحايدة يمنح ANS نقطة انطلاق أقوى من المقترحات الصادرة عن بائع واحد أو مؤلف واحد. ولأن عدة مخططات قائمة على DNS لا تزال تتنافس، ضع فحوص هوية الوكلاء خلف طبقة تجريد داخلية حيثما كان ذلك منخفض التكلفة، حتى لا يجبرك تغيّر المخطط الفائز على إعادة كتابة كل تكامل. والحجة هنا للاعتماد المرحلي، لا للتجنب.