تتيح خريطة الفشل الدقيقة تحديد المسؤولية بوضوح؛ فالنموذج يُنتج نصاً، لكن النظام الخلفي (backend) هو الذي يقرر ما إذا كان سيتم تنفيذ الطلب POST /v1/tools/refund.create. وفي هذا النظام الخلفي، يمكننا التحقق من نطاق صلاحيات الجهة الطالبة (principal)، واشتراط الموافقة على الإجراءات غير القابلة للتراجع، وإرفاق مفتاح لضمان خاصية “تكرار العملية دون تغيير النتيجة” (idempotency key) لمنع تكرار خصم الأموال عند إعادة المحاولة. وبمجرد فرض هذا الحد الفاصل، تصبح محاولات “حقن الأوامر” (prompt injection) مجرد مدخلات تفشل في اجتياز عمليات التحقق والتفويض، بدلاً من أن تتحول إلى تعليمات تؤدي إلى تحويل أموال.
نفترض وجود فهم عملي لرموز حالة HTTP، مما يعني أننا ندرك بالفعل دلالة استجابة الرفض أثناء نقل البيانات.
نفترض الإلمام بأساسيات JWT، مما يعني القدرة على التحقق من التوقيع والتأكد من الجهة المصدرة (issuer) والجمهور المستهدف (audience) وتاريخ الانتهاء باستخدام مكتبة برمجية موثوقة.
نفترض المعرفة بآلية “حقن التبعيات” (dependency injection) في إطار FastAPI، مما يتيح لنا دمج عمليات المصادقة والتفويض والتحقق من الحصص (quotas) كتبعيات مرتبطة بنطاق الطلب، بدلاً من تشتيت هذه الفحوصات داخل دوال المعالجة (handlers).
يتمثل المنتج النهائي الذي نبنيه خلال هذه الدورة في مسار عمل مرجعي للنظام الخلفي، حيث تتضمن كل مرحلة نقطة واضحة للرفض، وتحتوي كل سجلّة في ملفات السجل (log) على حقول ثابتة يمكن للمراجعين تحليلها وفهمها، وترتبط كل حالة اختبار تراجع (regression case) بضابط أمني محدد. الهدف ليس صياغة أمر (prompt) ذكي، بل بناء نظام خلفي قادر بأمان على إجراء عمليات “التوليد المعزز بالاسترجاع” (RAG) على سجلات الحساب، واستدعاء دالة refund.create فقط عندما يكون المستخدم u_123 مؤهلاً وحاصلاً على الموافقة، وتشغيل نصوص برمجية للتحليل دون منح صلاحيات الوصول إلى الشبكة أو البيانات السرية. يوضح الرسم البياني التالي مسار الطلب الذي سنعمل على تعزيز أمنه وتحصينه مرحلة تلو الأخرى.
عادةً ما يفشل النظام الخلفي (backend) للمساعد الذكي -المبني باستخدام FastAPI- بطريقة تقليدية. يقرأ النظام الخلفي سجل الحساب acct_987؛ فيقترح النموذج خطوات تالية، ويقوم استدعاء أداة (tool call) بإصدار استرداد مالي للعملية txn_456 لأن نص تذكرة الدعم كان يبدو واثقاً. لم يحدث شيء غير مألوف؛ فقد قبل التطبيق نصاً غير موثوق من التذكرة، وتعامل مع الاقتراح على أنه تفويض، ونفذ الأمر refund.create بصلاحيات الخدمة نفسها بدلاً من التحقق من صلاحيات المستخدم النهائي أو المرور عبر بوابة موافقة.
يتمحور العمل الأمني في هذه الدورة حول بناء مراحل الإنفاذ المفقودة في المواقع الوحيدة القادرة على تطبيقها. لا يمكن لصياغة “المطالبة” (prompt) أن تمنع موجه الأدوات (tool router) من إرسال طلب، كما لا يمكن للنموذج إثبات أن المستخدم u_123 لديه صلاحية استرداد المبلغ للعملية txn_456. فإما أن يرفض النظام الخلفي الطلب قبل تشغيل الأداة، أو يقوم بتشغيل الأداة وإنفاق أموال حقيقية.
نعتمد مرجعاً ثابتاً ومحدداً لكل درس لضمان تطبيق كل عنصر تحكم على نفس المكونات الديناميكية. الجهة المستأجرة (tenant) هي t_acme، والمستخدم النهائي هو u_123، والحساب هو acct_987، والعملية المرشحة للاسترداد هي txn_456. أداة الاسترداد الوحيدة تحمل الاسم refund.create، والمسار الوحيد للوصول إليها هو POST /v1/tools/refund.create.
كما نحدد اسم النطاق (scope) الوحيد الذي يسمح بإجراء استرداد مالي. يمكن للطرف (principal) الذي يفتقر إلى الصلاحية support:refund أن يناقش السياسات، ويلخص سجل الحساب، ويصيغ رداً، لكن لا يُسمح له بتنفيذ refund.create. يظل اختيار النموذج صريحاً ولكنه مجرد (غير مقيد بتنفيذ محدد)؛ حيث يستدعي التطبيق نموذج محادثة عبر المتغير $CHAT_MODEL ويستخدم $MODERATION_MODEL في الحالات التي تتطلب فيها دروس لاحقة عملية فحص مخصصة.
بمجرد تحديد الأسماء، يمكننا رسم مسار طلب واحد وتحديد نقاط دخول البيانات غير الموثوقة. تُعد رسالة المُرسِل غير موثوقة حتى لو صدرت عن وكيل دعم مصادق عليه، لأن الرسالة قد تحتوي على نصوص منسوخة من العميل أو محتوى التذكرة. وتُعتبر أجزاء سجل الحساب المسترجعة غير موثوقة لأن عملية الاسترجاع تعيد كل ما يحتويه المخزن، بما في ذلك الملاحظات القديمة والنصوص الحرة التي قد تحاول توجيه سلوك النموذج. كما أن نتائج الأدوات غير موثوقة لأن الأنظمة اللاحقة قد تعيد سلاسل نصية أو حقولاً غير متوقعة، ومخرجات النموذج غير موثوقة لأن النموذج يعمل على تحسين النص ليكون مقنعاً ومنطقياً، وليس لضمان الامتثال للسياسات.
يركز هذا المسار على بناء نقاط إنفاذ قادرة على تحويل المدخلات غير الموثوقة إلى إجراءات محددة النطاق وقابلة للتدقيق. نحن نتحقق من هوية الكيان (Principal) ونربطها بالطلب، بحيث يحمل كل طلب المعرفين t_acme وu_123 كحقائق موثقة من قِبَل الخادم، وليس كمجرد ترويسات (headers) يقدمها الطرف المستدعي. كما نقيس استهلاك الحصة المخصصة قبل استدعاء المزود لضمان عدم استنزاف مخصصات شهر كامل من الرموز (tokens) في ليلة واحدة. ونقوم بتفويض عملية الاسترجاع عند نقطة الاستدعاء بحيث لا تجلب الواجهة الخلفية (backend) سوى الأجزاء التي يحق للمستخدم u_123 الاطلاع عليها، مع التعامل مع كل جزء مسترجع باعتباره محتوى غير موثوق به. كذلك، نتحقق من صحة مخرجات النموذج المهيكلة قبل وصولها إلى أي مكون توجيه (router) أو محلل (parser) أو قالب (template) أو أداة. ونخضع استدعاءات الأدوات لعمليات التفويض والموافقة، بحيث لا يمكن تنفيذ إجراء مثل refund.create لمجرد أن النموذج قدّم اقتراحاً مقنعاً. ونعزل نصوص التحليل البرمجية في بيئة آمنة (sandbox) لمنع الكود المُولَّد من الوصول إلى الشبكة أو البيانات السرية. وأخيراً، ندقق في كل حالة رفض وكل إجراء مُنفَّذ، مع توفير بيانات كافية توضح هوية الفاعل وطبيعة الإجراء، والكيان المستأجر (tenant) المعني، وسبب سماح النظام الخلفي بذلك.
عندما يحاول نص تذكرة الدعم الفني بدء عملية استرداد مالي، ما هي المرحلة التي كان بإمكانها رفض هذا الاسترداد قبل تشغيل أي أداة؟