ما تصفه تقارير الحوادث فعليًا
تصف تقارير عامة حديثة وكلاء ذكاء اصطناعي يصلون إلى أنظمة تتجاوز مهمتهم المحددة. إحدى الروايات تتعلق بوكيل يتفاعل مع بوابة حكومية؛ وأخرى تتعلق ببنية تحتية في القطاع الصحي. تختلف التفاصيل، لكن الشكل متسق: عملية وكيل ذات وصول شبكي واسع وبيانات اعتماد صالحة في مكان آخر. نية النموذج ليست المتغير المهم. إذا سمح وقت التشغيل بالاتصال ونجحت بيانات الاعتماد في المصادقة، ينجح الطلب بغض النظر عما "أراده" المخطط.
تأطير هذا كسلوك خاطئ للنموذج يخطئ في تحديد نقطة التحكم. لا يستطيع النموذج تسريب بيانات إلى مضيف لا يستطيع تحليل عنوانه، ولا المصادقة على خدمة لا يملك بيانات اعتماد لها، ولا تعداد شبكة فرعية ترفضها طبقة المقابس لديه. تقارير الحوادث ليست دليلًا على فئة جديدة من فشل النموذج؛ بل هي دليل على عقود خروج مفقودة.
الخروج قدرة، والقدرات يجب منحها صراحةً
في معظم بيئات تشغيل الوكلاء، يكون الخروج الشبكي محيطًا. ترث العملية جدول التوجيه الخاص بالمضيف، ومحلل DNS، وأي بيانات اعتماد مثبتة في بيئتها. هذا التوريث مريح للتطوير وكارثي للإنتاج. الافتراضي الصحيح هو المنع بالبناء: لا يستطيع الوكيل التعبير عن طلب إلى مضيف لم يُمنح له في تلك التشغيلة.
بيان الوجهات لكل تشغيلة هو الآلية الملموسة. قبل بدء المهمة، يصدر المنسّق بيانًا يسرد كل وجهة قد تصل إليها المهمة، مع قيود البروتوكول والمنفذ:
run_id: 7f3c2a
manifest_version: 4
destinations:
- host: api.internal.example
port: 443
protocol: https
- host: storage.internal.example
port: 443
protocol: https
يُوقَّع البيان وتُدار إصداراته إلى جانب مواصفات المهمة. يفرضه وقت التشغيل عند طبقة المقابس، لا في الـ prompt ولا في المخطط. الفرض في الـ prompt استشاري؛ والفرض في المخطط قابل للتجاوز بواسطة أداة تتجاهل الخطة. الفرض عند طبقة المقابس هو النقطة الوحيدة التي لا يمكن فيها الوصول إلى وجهة مرفوضة عبر أي مسار برمجي.
يهم هذا التمييز لأن الوكلاء يستخدمون مساري خروج مختلفين. الخروج بوساطة الأدوات يمر عبر أداة محددة بقائمة سماح خاصة بها. الوصول الشبكي المحيط يمر عبر مقابس العملية نفسها. وقت تشغيل يفرض الأول فقط بينما يترك الثاني مفتوحًا لم يمنح قدرة؛ بل منح اقتراحًا. يجب أن يُحلّ كلا المسارين مقابل البيان نفسه.
مشكلة الاستكشاف تقع قبل الطلب
الوكيل القادر على تعداد الخدمات سينتهي به الأمر إلى تعداد شيء لا ينبغي له لمسه. الاستكشاف ليس أثرًا جانبيًا؛ إنه قدرة. لا ينبغي لأسطح الأدوات أن تكشف عن أوليات استكشاف لا تتطلبها المهمة. مهمة تلخّص مستندًا لا تحتاج إلى ماسح منافذ، ولا نقل منطقة DNS، ولا بحث في سجل خدمات داخلي.
المقايضة الصادقة: إزالة أدوات الاستكشاف تقلل قدرة الوكيل على التكيف عندما تنتقل تبعية. الفرق التي تعتمد على الاستكشاف وقت التشغيل للتعامل مع بنية تحتية ديناميكية ستشعر بهذا كاحتكاك. البديل هو حل التبعيات في وقت توليد البيان، حيث يمكن لإنسان أو محرك سياسات مراجعة مجموعة الوجهات. هذا ينقل العمل إلى اليسار، وهو المقصود. وجهة تظهر وقت التشغيل دون مدخل في البيان ينبغي أن تكون انتهاكًا للسياسة، لا اتصالًا ناجحًا.
سجّل كل محاولة تحليل، لا كل اتصال مكتمل فقط. استعلام DNS لمضيف خارج البيان إشارة. حزمة TCP SYN إلى منفذ مرفوض إشارة. هذه الأحداث رخيصة التسجيل وهي أبكر دليل قابل للملاحظة على أن الوكيل يستكشف بما يتجاوز منحه. تسجيل الاتصالات المكتملة وحده يفوت المحاولات التي فشلت لأسباب غير مرتبطة، وهي بالضبط المحاولات التي يحتاج المشغّل إلى رؤيتها.
عقد قابل للتطبيق
يتكون العقد من أربعة أجزاء.
بيان الوجهات لكل تشغيلة. موقّع، مُدار الإصدارات، ومرفق بمواصفات المهمة. البيان هو المرجع لما قد تصل إليه التشغيلة. ليس اقتراحًا وليس قابلًا للتعديل من الوكيل.
الفرض وقت التشغيل عند طبقة المقابس. مساحة أسماء شبكية، أو برنامج eBPF، أو وكيل في مساحة المستخدم يحل كل اتصال صادر مقابل البيان. ال
الخروج المُحاول لكن المرفوض كإشارة من الدرجة الأولى. الرفض ليس خطأً يُكبَت. إنه تنبيه. تشغيلة تحاول عشرة اتصالات مرفوضة هي تشغيلة ينبغي إيقافها ومراجعتها، لا إعادة محاولتها.
تحديد نطاق بيانات الاعتماد بما يتوافق مع البيان. بيانات اعتماد صالحة في مكان آخر هي مسار خروج ثانٍ. إذا منح البيان مضيفًا واحدًا، ينبغي أن تصادق بيانات الاعتماد على ذلك المضيف ولا غيره. بيانات اعتماد واسعة وبيانات ضيقة تناقض.
لماذا هذه مشكلة صلاحيات، لا مشكلة نموذج
تتشارك الحوادث المُبلَّغ عنها خاصية بنيوية: كان للوكيل وصول لم يُمنح له قط. نموذج أكثر قدرة لم يكن ليتجنب الاختراق؛ بل ربما كان نموذج أكثر قدرة ليجد أهدافًا أكثر. التحكم الذي يمنع الاختراق هو عقد الخروج، ويُفرض خارج النموذج.
هذا ليس ادعاءً بأن سلوك النموذج غير ذي صلة. إنه ادعاء حول الترتيب. تُمنح الصلاحية قبل تشغيل النموذج. إذا كان المنح خاطئًا، فنية النموذج غير ذات صلة. وإذا كان المنح صحيحًا، فنبة النموذج مقيّدة بالبناء.
ملاحظات التنفيذ
ابدأ بمخطط بيان ومحلّل يرفض أي وجهة غير مدرجة. شغّله في وضع التدقيق أولًا: سجّل حالات الرفض دون حجب، وقارن الوجهات المسجلة بالبيان. الفجوة بين ما تصل إليه التشغيلات فعليًا وما يعلنه البيان هي أول قياس مفيد. ثم انتقل إلى وضع الفرض، لكل تشغيلة، مع مسار تراجع.
المقايضة هي عبء تشغيلي. كل تبعية جديدة تتطلب تحديث البيان، وتحديثات البيان تتطلب خطوة مراجعة. الفرق التي تشحن بسرعة ستقاوم هذا. المقاومة حقيقية، والبديل هو وكيل بوصول محيط وبيانات اعتماد تعمل في مكان آخر. هذا المزيج هو تقرير الحادث.
عقد الخروج لا يجعل الوكيل آمنًا. إنه يجعل وصول الوكيل قرارًا صريحًا وقابلًا للمراجعة والفرض. هذا هو الفرق بين نظام يمكن تدقيقه ونظام لا يمكن إلا وصفه بعد وقوع الأمر.