التحكم في خروج الوكلاء: لماذا الوصول فشل في التوجيه

نمط الحادثة

عندما يُبلَّغ عن أن أسطول وكلاء لامس بوابة حكومية أو صحية لا ينبغي له الوصول إليها، نادرًا ما يكشف تحليل ما بعد الحادثة عن تصعيد صلاحيات. لا يوجد استغلال لثغرة في النواة، ولا بيانات اعتماد مسروقة، ولا خلل confused-deputy في خدمة تخويل. ما يوجد هو طلب HTTP صادر إلى اسم مضيف لم يكن مطلوبًا من الوكيل أن يحلّه أصلًا، واستجابة عادت منه.

هذه هي التفصيلة التي تضيع في ملخصات مثل هذه التقارير: الوكيل لم يكتسب قدرة جديدة. اكتسب اسم مضيف قابلًا للوصول. كل ما احتاجه لإجراء الطلب — حزمة TLS، ومحلّل DNS، وأداة fetch في بيانه — كان موجودًا بالفعل ويعمل كما صُمّم. لم يكن الفشل في ما يستطيع الوكيل فعله. كان في إلى أين يستطيع الوكيل الذهاب.

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

لماذا لا تستطيع guardrails على مستوى الـ prompt الصمود عند هذا الخط

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

system prompt يقول "لا تتصل بأنظمة حكومية" هو توزيع مسبق على متتاليات الـ token. يصمد في معظم الأوقات ويتدهور بطرق يصعب حصرها: خطة متعددة الخطوات تعيد تأطير الهدف، نتيجة أداة توفّر URL غير متوقع، سياق طويل تكون فيه القيد بعيدًا عن نقطة القرار، نتيجة retrieval تتعامل مع رابط خارجي كأنه تعليمة. لا شيء من هذا يتطلب خصمًا. يتطلب فقط متتالية tokens معقولة.

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

هذه ليست حجة ضد guardrails على مستوى الـ prompt. فهي مفيدة لتشكيل النية وللرفض المبكر الرخيص. لكنها ببساطة الطبقة الخاطئة لحدود يجب أن تصمد عندما يكون النموذج مخطئًا، أو متعبًا، أو مُوجَّهًا. الحدود التي يمكن إقناعها بالتخلي عن وجودها ليست حدودًا.

تصميم عقد الخروج

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

Two professionals engaging in a business meeting, signing documents for a consulting agreement.

قائمة السماح حسب الوجهة والطريقة وفئة الحمولة

اسم المضيف وحده خشن جدًا. قاعدة تسمح بـ api.example.gov تسمح بكل مسار، وكل طريقة، وكل جسم. العقد الأكثر إحكامًا يسمّي ثلاثة أشياء معًا:

الوجهة: scheme والمضيف وبادئة المسار — https://api.example.gov/v1/records/ بدلًا من الأصل بأكمله.
الطريقة: GET وHEAD مسارات قراءة؛ POST وPUT وPATCH وDELETE مسارات كتابة ويجب تبريرها بشكل منفصل.
فئة الحمولة: شكل ما قد يخرج. وكيل retrieval يرسل معرّفًا فقط مختلف في مخاطره عن وكيل يستطيع إرفاق جسم مستند. يمكن فرض فئة الحمولة عبر schema، أو عبر سقف حجم، أو عبر مصنّف عند الـ proxy.

القاعدة التي تربط الثلاثة معًا قابلة للتدقيق بطريقة لا تتيحها قائمة أسماء المضيفين. عندما يسأل مراجع "هل كان يمكن لهذا الوكيل إرسال بيانات إلى بوابة صحية؟"، تكون الإجابة بحثًا في سجل، لا استنتاجًا.

الرفض افتراضيًا، مع تذكرة صريحة

الوضع الافتراضي هو الرفض. يُمنح الوصول عبر استثناء يسمّي:

requesting_agent: intake-classifier-v3
purpose: fetch public reference data for citation
destination: https://api.example.gov/v1/records/
methods: [GET, HEAD]
payload_class: identifier-only
requested_by: platform-team
justification: ticket OPS-4821
expires_at: 2026-09-30T00:00:00Z

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

سجّل حالات الرفض كأحداث من الدرجة الأولى

معظم الـ proxies تسجّل المرور المسموح بتفصيل، وحالات الرفض كعدّاد. اعكس هذا التركيز. حالة الرفض تحمل هوية الوكيل، والوجهة المحاولة، والطريقة، والقاعدة التي فُعّلت، ومعرّف ارتباط يعود إلى التشغيل.

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

أحد التنفيذات العملية يضع وسيطًا بين بيئة تشغيل الوكيل والشبكة. أداة fetch لدى الوكيل لا تفتح sockets. بل تنادي الوسيط بطلب منظّم:

Close-up view of Westminster Palace's intricate Gothic architecture in London, UK.

{
  "agent": "intake-classifier-v3",
  "run_id": "r-8f21c",
  "method": "GET",
  "url": "https://api.example.gov/v1/records/4412",
  "payload_class": "identifier-only"
}

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

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

المقايضة الصادقة

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

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

التبعات التشغيلية

ممارستان تتبعان من التعامل مع الخروج كعقد.

قواعد الخروج تصبح عناصر مُصدَّرة بإصدارات. تعيش في المستودع نفسه الذي يعيش فيه بيان أدوات الوكيل، وتُراجَع في التغيير نفسه. طلب pull request يضيف أداة تجلب من أصل جديد يجب أن يضيف أو يعدّل قاعدة الخروج المقابلة، ويرى المراجع الاثنين معًا. بيان الأدوات يقول ما ينوي الوكيل فعله؛ وعقد الخروج يقول ما يُسمح له بفعله. التباعد بينهما نتيجة مراجعة، لا مفاجأة وقت التشغيل.

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

خاتمة

وصول وكيل إلى بوابة لا ينبغي له لمسها ليس في المقام الأول قصة سلوك نموذج. إنها قصة توجيه. مُنح الوصول في مكان ما — عبر افتراضي متساهل، أو استثناء قديم، أو محلّل غير مثبّت — وهذا المنح هو موضع الإصلاح. guardrails على مستوى الـ prompt تشكّل النية؛ لكنها لا تفرض الوصول. حدود خروج واحدة قابلة للتدقيق، ترفض افتراضيًا، وتسجّل حالات الرفض بالأمانة نفسها التي تسجّل بها النجاحات، وتُصدَّر بإصدارات جنبًا إلى جنب مع بيان الأدوات، هي ما يجعل الإجابة عن "هل كان يمكن لهذا الوكيل الوصول إلى ذلك المضيف؟" بحثًا في سجل بدلًا من أمنية.

وكيل يصل إلى بوابة حكومية هو فشل في التوجيه