يمكن أن تتحول محادثة الدعم الفني إلى إجراء يتضمن تحويل أموال عندما يقبل النظام الخلفي (المبني باستخدام FastAPI) مخرجات النموذج باعتبارها أمراً موثوقاً أو مصرحاً به.
في سيناريو الفشل المستخدم في هذه الدورة، يرسل تطبيق مستدعٍ رسالة تبدو عادية إلى نقطة النهاية POST /v1/chat؛ فتقوم خدمة FastAPI بتمرير ذلك النص إلى مزود النموذج، ليعيد النموذج بدوره تعليمات لاستخدام أداة (tool instruction) تشبه طلب استرداد الأموال.
ينفذ النظام الخلفي استدعاء الأداة بمجرد أن يقترحها النموذج، وذلك دون التحقق مما إذا كان المستخدم النهائي مخولاً للقيام بذلك الإجراء، ودون التعامل مع مخرجات النموذج كنص غير موثوق به.
لا يتطلب حدوث هذا الفشل أي ظروف استثنائية أو معقدة؛ فالنظام الخلفي يؤدي وظيفته المصمم لأجلها تماماً، لكنه ينفذ الخطوة الأكثر حساسية (وهي إجراء الأداة) بناءً على نص (سلسلة نصية) ورد من خارج نطاق الثقة.
بمجرد تنفيذ إجراء لا يمكن التراجع عنه، لا يمكن لأي مرشح (فلتر) لاحق إلغاء الأثر الجانبي الناتج؛ لذا يتعين علينا تحديد الموضع المناسب لوضع أول نقطة توقف فعالة.
يعبر الطلب نفسه عدة حدود تتحول فيها النصوص غير الموثوقة إلى عمليات إنفاق أو آثار جانبية، وتلتزم الدورة بهذا المسار الواحد لضمان وضع كل آلية تحكم في مكانها المحدد.
تدخل النصوص غير الموثوقة من ثلاثة مصادر حتى عندما يتصرف التطبيق المستدعٍ بشكل سليم: تصل رسالة المستدعي عبر طلب HTTP، وتصل المستندات المسترجعة من مخازن بيانات النظام الخلفي نفسه، وتعود نتائج الأدوات من أنظمة أخرى قد تكون خاطئة أو معادية.
يمكن أن يحدث استهلاك للموارد (أموال وبيانات) في نقطتين: استدعاء مزود النموذج يستهلك الرموز (tokens) ويكلف مالاً، بينما يمكن لتنفيذ الأداة قراءة أو تعديل موارد حقيقية قد لا يملكها المستخدم.
تتمثل نقاط الإنفاذ الموثوقة الوحيدة في عمليات التحقق التي تتم من جانب الخادم (في خدمة FastAPI) والمحيطة بنقاط الاستهلاك تلك. تبني الدورة آليات المصادقة، وربط المستأجر (tenant binding)، والحصص (quotas)، ومرشحات المدخلات والمخرجات، وتفويض استخدام الأدوات، وبيئات العزل (sandboxing)، وسجلات التدقيق كبوابات صريحة؛ ولا يمكن لصياغة “موجه النظام” (system prompt) فرض أي منها، لأن موجه النظام قابل للقراءة والنموذج يتبع النص فقط.
يوضح الرسم البياني أدناه كل مدخل غير موثوق وكل نقطة إنفاذ على مسار الطلب الواحد الذي نواصل توسيعه. دعونا نحدد بدقة النقطة التي يتحول فيها النص إلى أمر نافذ (سلطة تنفيذية) والنقطة التي يمكننا فيها رفض الطلب.
يوضح هذا المخطط قاعدة واحدة: أي سهم يحمل نصاً يُعد مصدراً غير موثوق، ووحدات الخدمة (الممثلة بالمربعات) هي الوحيدة القادرة على رفض الطلبات، أو وضع قيود عليها، أو التحقق من صحتها، أو منح الإذن، أو تسجيل الأحداث.
تتطلب اتفاقية واجهة برمجة التطبيقات (API) الآمنة رموز رفض متسقة؛ لأن كلاً من العملاء وعمليات تصحيح الأخطاء (عند الاستدعاء الطارئ) يعتمدون على نتائج يمكن التنبؤ بها عندما ترفض إحدى بوابات التحكم طلباً ما.
نقوم بتحديد مخطط الرفض مرة واحدة ثم نعيد استخدامه، مع ربط كل حالة رفض دائماً بحدود النظام (boundary) التي تفرض هذا الرفض، وليس بالنموذج (model) نفسه.
401 Unauthorized (غير مصرح به): يرفض الطلبات التي تستخدم بيانات اعتماد مفقودة أو غير صالحة أو ملغاة أو مخترقة، وتصدر الخدمة هذا الرد قبل استهلاك الحصة المخصصة أو استدعاء المزود الخارجي.403 Forbidden (ممنوع): يرفض الطلبات الصادرة عن مستخدم تم التحقق من هويته ولكنه يعمل خارج النطاق المسموح به (بما في ذلك الحالات التي يكون فيها الإذن مرفوضاً أو منتهي الصلاحية)، كما يرفض محاولات جلب أداة (tool fetch) موجهة إلى وجهة محظورة لا يتم الاتصال بها مطلقاً.422 Unprocessable Content (محتوى غير قابل للمعالجة - RFC 9110): يرفض مخرجات النموذج التي تفشل في التحقق من مطابقة المخطط (schema validation)؛ لأن المخرجات غير المتحقق منها تظل مجرد نص عادي حتى يثبت الخادم مطابقتها لاتفاقية الأداة.429 Too Many Requests (طلبات كثيرة جداً) مع ترويسة Retry-After: يرفض الطلبات عند استنفاد حد المعدل (rate limit) أو الحصة المخصصة، ويجب أن تكون بيانات العداد مشتركة بين النسخ المختلفة للخدمة لمنع مضاعفة الحد المسموح به بشكل غير مقصود.503 Service Unavailable (الخدمة غير متاحة): يظهر هذا الخطأ عند تعطل مخزن عداد الحصص أو عند تفعيل آلية الحماية (circuit breaker) التي تمنع فرض القيود، حيث يتعذر على الخدمة اتخاذ قرار آمن بشأن السماح بالاستهلاك.504 Gateway Timeout (انتهاء مهلة البوابة): يظهر هذا الخطأ عندما يتجاوز استدعاء المزود الخارجي المهلة الزمنية المحددة للخدمة؛ لأن الاستدعاءات المعلقة تمثل استهلاكاً غير محدود للموارد.لضمان الطابع العملي للدورة، نقوم ببناء مكون برمجي واحد قابل للتشغيل ونعمل على تعزيز أمانه خطوة بخطوة. يتمثل هذا المكون في مسار POST /v1/chat يدعم تعدد المستأجرين (tenant-aware) وقادر على استدعاء أداة واحدة فقط، وتضيف كل محاضرة لاحقة بوابة تحكم جديدة إلى هذا المسار.
في حالات الفشل الأولي، قد يكون الطرف المستدعي (المستخدم) شرعياً؛ مما يعني أن عملية التحقق من الهوية قد تنجح بينما يؤدي الطلب في الوقت نفسه إلى تنفيذ إجراء غير مصرح به عبر الأداة.
إذا انتظرت الخدمة للتحقق من صحة مخرجات النموذج إلى ما بعد تنفيذ استدعاء الأداة، فقد تنجح عملية التحقق من المخطط (schema validation) في رفض البيانات ذات التنسيق الخاطئ، لكنها لا تستطيع التراجع عن إجراء يبدو صحيحاً من الناحية الشكلية ولكنه كان ينبغي ألا يُسمح به من الأساس.
القرار الجوهري يكمن في تحديد المرحلة القادرة على رفض الطلب قبل تنفيذ إجراء لا رجعة فيه بواسطة الأداة. فأي نقطة توقف مبكرة هي التي تكتشف الفشل أولاً: المصادقة، أم تفويض استخدام الأداة، أم التحقق من صحة المخرجات؟