يمكن لوكيل (Proxy) مركزي مبني على Node استنزاف ميزانية شهر كامل مخصصة لمزود الخدمة في ليلة واحدة؛ وذلك عندما يُستخدم مفتاح خدمة مخترق للوصول إلى مسار “إكمال” (completion route) متساهل، بينما يثق الوكيل في توجيهات يحددها المُرسِل -مثل provider=openai و model=$OPENAI_CHAT_MODEL- ضمن متن الطلب.
في نظامنا التشغيلي، يقوم تطبيق AcmeSupportApp باستدعاء البوابة نيابة عن المستأجر t_acme_prod؛ فتقوم البوابة بتوجيه الطلب (توزيع المهام) إلى $OPENAI_CHAT_MODEL أو $ANTHROPIC_CHAT_MODEL أو $LLAMA_CHAT_MODEL، مع وجود ذاكرة تخزين مؤقت دلالية (semantic cache) مشتركة بالقرب من البوابة لتوفير الرموز (tokens) عند تكرار المطالبات (prompts).
لا يتمثل الفشل في اختراق معقد للنموذج؛ فالمهاجم يحتاج فقط إلى مفتاح يجتاز الفحوصات السطحية المطبقة حالياً، ثم يرسل عدداً كبيراً من الطلبات التي تتضمن مطالبات طويلة وحدوداً عالية للمخرجات. وتقوم البوابة بتمرير هذه الطلبات لعدم وجود ميزانية محددة لكل مستأجر (يتم فرضها تقنياً) قبل بدء الاتصال بالمزود.
وبمجرد أن يقوم الوكيل ببث مخرجات المزود غير المفلترة وإعادتها إلى المُرسِل، يمكن للمفتاح المخترق نفسه أن يتسبب في تمرير محتوى غير آمن إلى الردود اللاحقة على تذاكر الدعم، نظراً لعدم وجود آلية تفرض سياسة معينة على النص المُولَّد عند حدود البوابة.
بالنظر إلى هذا التسلسل، ما هي المرحلة التي كان بإمكانها رفض الطلب الأول تماماً قبل حدوث أي إنفاق وقبل توليد أي مخرجات غير آمنة؟
تُعد البوابة المكون الوحيد الذي يرى هوية المُرسِل وخيار المزود في آن واحد؛ لذا فهي المكان الذي يمكننا فيه ربط AcmeSupportApp بالمستأجر t_acme_prod ورفض أي نموذج أو مسار يقع خارج نطاق صلاحياته قبل استخدام مفتاح المزود.
تفتقر كل مرحلة أخرى (أو محطة في مسار الطلب) إلى معلومة جوهرية؛ فالمزود لا يرى سوى بيانات اعتماد البوابة الخاصة به، وبالتالي لا يمكنه التمييز بين المستأجرين داخل منصتنا. أما ذاكرة التخزين المؤقت فلا ترى سوى مفتاح مشتق من محتوى الطلب، وبالتالي لا يمكنها فرض قيود على من يُسمح له بالإنفاق أو تحديد النموذج الذي يمكن للمُرسِل الوصول إليه.
تدخل بيانات غير موثوقة من نقاط متعددة حتى عند صحة اتصال TLS؛ إذ يمكن لترويسات الطلب (headers) تضليل النظام بشأن الهوية إذا قبلنا معرفات المستأجرين التي يقدمها المُرسِل، ويمكن لمتن الطلب تضليل النظام بشأن التوجيه واختيار النموذج إذا اعتمدنا تلك البيانات، كما تُعد استجابة المزود مخرجات غير موثوقة قد تحتوي على محتوى ينتهك السياسات أو حقولاً مهيكلة تخالف المخطط (schema) المتوقع. فيما يلي مسار الطلب موضحاً عليه حدود الثقة ونقاط فرض السياسات.
يوضح هذا المخطط القيد العملي الذي نبني عليه بقية محتوى الدورة. البوابة (Gateway) هي الجهة الوحيدة القادرة على مصادقة الجهة الطالبة، وتقييم السياسة المطبقة على كل طلب، وحجز الحصة (quota) مقابل عداد مشترك، وفرض عمليات التحقق من المدخلات والمخرجات المتدفقة قبل عودة الاستجابة إلى نظام الجهة الطالبة.
تحافظ البوابة على سلوك يمكن التنبؤ به أثناء التعرض لهجمات عندما يكون لكل نقطة إنفاذ رمز رفض واحد ومحدد، ويتم توليد هذا الرمز قبل الانتقال إلى الخطوة التالية المكلفة (من حيث الموارد). نستخدم خريطة رفض موحدة طوال الدورة لضمان اتساق السجلات والتنبيهات وسلوك العميل عبر مختلف المزودين.
تؤدي بيانات اعتماد الجهة الطالبة المفقودة أو غير الصالحة أو الملغاة أو المخترقة إلى إرجاع الرمز 401 Unauthorized (غير مصرح به).
عندما تطلب جهة طالبة مصادق عليها مساراً (route) أو نموذجاً (model) خارج قائمتها المسموح بها، يتم إرجاع الرمز 403 Forbidden (ممنوع)، وترفض البوابة الطلب قبل الاتصال بأي مضيف تابع للمزود.
يؤدي استنفاد حد المعدل (rate limit) أو حصة الرموز (tokens) والتكلفة إلى إرجاع الرمز 429 Too Many Requests (طلبات كثيرة جداً) مرفقاً بمعلومات Retry-After (إعادة المحاولة بعد فترة محددة)؛ وذلك لأن العميل يحتاج إلى اتفاقية واضحة بشأن التراجع (backoff)، ويجب ألا تؤدي عمليات إعادة المحاولة إلى تضخيم التكلفة.
إذا تعذر على البوابة فرض القيود بأمان —بسبب تعطل مخزن العدادات المشترك أو حجب عمليات التحقق بواسطة آلية “قاطع الدائرة” (circuit breaker) المفتوحة— فإنها تعيد الرمز 503 Service Unavailable (الخدمة غير متاحة) بدلاً من السماح بمرور الطلب (failing open) وتحمل تكاليف دون إمكانية نسبها للجهة الصحيحة.
إذا تجاوز وقت استدعاء المزود المهلة المحددة في البوابة، تعيد البوابة الرمز 504 Gateway Timeout (انتهاء مهلة البوابة) ولا تقوم ببث المخرجات الجزئية باعتبارها استجابة ناجحة.
إذا كنا نشترط مخرجات مهيكلة (structured output) وفشلت استجابة المزود في اجتياز التحقق من المخطط (schema validation)، تعيد البوابة الرمز 422 Unprocessable Content (محتوى غير قابل للمعالجة) لضمان عدم تشغيل أي محلل بيانات (parser) لاحق على حقول غير موثوقة.
في السيناريو الأولي، يجب أن تكون نقطة الرفض الأولى هي مرحلة المصادقة والتحقق من السياسة عند البوابة، وذلك قبل حجز أي حصة وقبل استدعاء أي مزود؛ لأن المراحل اللاحقة تفتقر إلى المعلومات اللازمة لربط التكلفة والأذونات بالمعرف t_acme_prod بمجرد بدء تدفق الطلب إلى الخارج.