تقوم منصة Ledgerline بتوجيه طلب الدعم الخاص بأحد الموظفين عبر واجهة برمجة تطبيقات (API) للمساعد الذكي، ومزود للنموذج اللغوي، وأداة لمعالجة عمليات استرداد الأموال. احتوت تذكرة دعم (على نظام Jira) على نص يطلب استرداد مبلغ لعميل؛ فتعامل المساعد الذكي مع هذا النص باعتباره “تعليمات”، ثم استخدم منفذ الأداة حساباً مشتركاً لخدمة المدفوعات لتنفيذ العملية. لم يكن لدى مقدم الطلب صلاحية إجراء الاسترداد، لكن النظام الخلفي لم يتحقق من هوية مقدم الطلب عند لحظة التنفيذ. لم تكن هناك حاجة لبرمجيات خبيثة أو بيانات اعتماد مسروقة؛ إذ دخل نص التذكرة غير الموثوق في حلقة عمل الوكيل الذكي ووصل إلى عملية ذات صلاحيات عالية كان التطبيق قد أتاحها مسبقاً.
يجمع هذا الخلل بين حقن الأوامر (Prompt Injection) - حيث يغير نص غير موثوق سلوك التطبيق الموجه بواسطة النموذج - وبين الصلاحيات المفرطة للوكيل (Excessive Agency) - حيث يمنح التطبيق ذلك السلوك صلاحيات تتجاوز حقوق الموظف الذي بدأ الطلب. وتصنف منظمة OWASP هذه المشكلات تحت المسميين LLM01 (حقن الأوامر) وLLM06 (الصلاحيات المفرطة للوكيل) في إرشاداتها لعام 2025، التي نشرها مشروع أمان الذكاء الاصطناعي التوليدي (GenAI Security Project) التابع لـ OWASP في نوفمبر 2024. لا يمكن لصياغة الأمر (prompt) أن تمنح تفويضاً باسترداد الأموال لأن النموذج يولد نصوصاً فقط؛ بينما يتخذ الخادم القرار بشأن تنفيذ عملية الدفع من عدمه.
تمت عملية استرداد الأموال لأن Ledgerline سمحت لطلب واحد بتجاوز حدود ثقة متعددة دون الاحتفاظ بمعلومات حول مصدر الطلب الأصلي. تُعد رسالة الموظف غير موثوقة، وكذلك مستند الدعم المسترجع يُعد غير موثوق حتى لو قامت Ledgerline بتخزينه. وتُعتبر نتيجة الأداة مدخلاً غير موثوق للاستدعاء التالي للنموذج. كما أن مخرجات النموذج غير موثوقة أيضاً، لأن اقتراح إجراء “استرداد” (refund) لا يعد دليلاً على أن الموظف يملك صلاحية تنفيذه.
تقوم واجهة برمجة تطبيقات المساعد بالتحقق من هوية الموظف قبل تجميع الأمر (prompt). وتعمل صلاحيات الاسترجاع على حصر المستندات المتاحة ضمن نطاق المستأجر (tenant) وصلاحيات الموظف قبل دمج نص المستند في الأمر. يتلقى منفذ الأداة بيانات الطرف الموثق والمعلمات المطلوبة، ثم يطبق سياسة الإجراء قبل التواصل مع نظام المدفوعات. ويسجل سجل التدقيق (audit log) بيانات الطرف المنفذ، والإجراء المطلوب، والقرار المتخذ، والنتيجة. يقوم مزود النموذج بتوليد إجراء مقترح، لكنه لا يمنح الإذن بالتنفيذ أبداً. يجعل مسار الطلب كل حدٍّ مرئياً:
يفصل هذا المسار بين معالجة النصوص وصلاحيات التنفيذ. يمكن لعملية المصادقة رفض طلب من جهة غير معروفة، ويمكن لعملية الاسترجاع حجب سجل عميل غير مصرح بالوصول إليه، كما يمكن لبوابة الأدوات رفض عملية استرداد مالي حتى لو أوصى النموذج بذلك بشدة. ورغم أن سجل التدقيق لا يمنع الإجراء نفسه، إلا أنه يتيح لنظام Ledgerline تحديد الجهة (المستخدم/الكيان) وقرار السياسة والمعاملات التي أدت إلى تلك النتيجة.
نظراً لأن كل نقطة فحص (أو حاجز) تتعامل مع نوع مختلف من حالات الفشل، فإن Ledgerline تعيد رمز حالة (Status Code) محدداً وثابتاً بدلاً من اعتبار كل حالة رفض خطأً في النموذج. يعني الرمز 401 Unauthorized (غير مصرح به) أن الطلب يحتوي على بيانات اعتماد مفقودة أو غير صالحة أو ملغاة أو مخترقة. ويعني الرمز 403 Forbidden (ممنوع) أن الموظف -رغم مصادقة هويته- يفتقر إلى الصلاحيات المطلوبة، مثل طلب استرداد مالي دون امتلاك صلاحية القيام بذلك، أو محاولة استرجاع بيانات تقع خارج نطاق صلاحياته.
تستخدم المراحل الأخرى نتائج أكثر تحديداً:
409 Conflict (تعارض): يعني أن الطلب الأول الذي يستخدم مفتاح ضمان التكرار الآمن (idempotency key) لا يزال قيد التنفيذ.422 Unprocessable Content (محتوى غير قابل للمعالجة): يعني أن مخرجات النموذج لم تتوافق مع مخطط الإجراء المطلوب في Ledgerline، أو أنه تمت إعادة استخدام مفتاح ضمان التكرار الآمن بمعاملات مختلفة.429 Too Many Requests (طلبات كثيرة جداً) مع ترويسة Retry-After: يعني أن المستأجر (العميل) قد استنفد حد المعدل أو حد الإنفاق المسموح به.503 Service Unavailable (الخدمة غير متاحة): يعني أن Ledgerline غير قادرة على تطبيق عداد مطلوب، أو أن آلية حماية النظام (قاطع الدائرة/circuit breaker) تمنع الاتصال بمزود الخدمة.504 Gateway Timeout (انتهاء مهلة البوابة): يعني أن مزود النموذج تجاوز المهلة الزمنية المحددة من قبل Ledgerline.يحدد رمز الحالة نقطة الفحص التي اتخذت القرار. فإذا رُفض طلب البحث عن عميل قبل تجميع “المطالبة” (prompt) وإرسالها للنموذج، تعيد Ledgerline الرمز 403 Forbidden؛ وبالتالي لا يصل أي مستند مسترجع إلى المزود. وإذا كانت معاملات عملية الاسترداد المقترحة غير صحيحة الصياغة، يعيد الخادم الرمز 422 Unprocessable Content قبل أن يتواصل منفذ الأداة مع نظام المدفوعات. تحوّل هذه النتائج عملية الرفض إلى سلوك يمكن رصده في النظام الخلفي (backend)، بدلاً من مجرد عبارة نصية ضمن تعليمات النظام (system prompt).
قاعدة الصلاحيات قد تتولى هوية خدمة مشتركة نقل الطلب، ولكن لا يجوز لها أن تحل محل هوية الموظف (الكيان الأصلي) المستخدمة لمنح الإذن بتنفيذ الإجراء.
تتمثل الحادثة المذكورة في البداية في مشكلة “الوكيل المرتبك” (Confused Deputy)؛ حيث كان لدى مُنفِّذ عمليات الاسترداد في نظام Ledgerline صلاحيات خدمة واسعة، واستخدم تلك الصلاحيات نيابةً عن موظف لا يملك الإذن المقابل. ورغم أن واجهة برمجة تطبيقات المدفوعات (Payments API) قد تتحقق من صحة بيانات اعتماد الخدمة الخاصة بـ Ledgerline، إلا أنها لا تستطيع استنباط أحقية الموظف المفقودة ما لم تقم Ledgerline بتمرير بيانات ذلك الموظف والتحقق منها. إن نقل آلية التحكم إلى مرحلة مبكرة —أي مرحلة إعداد المطالبة (prompt assembly)— يترك المجال للنصوص اللاحقة ونتائج الأداة ومخرجات النموذج لتغيير الإجراء المقترح.
تكمن نقطة الإنفاذ الموثوقة في معالج الأداة (tool handler) الموجود على جانب الخادم؛ حيث تتوفر لدى Ledgerline الحقائق اللازمة لاتخاذ القرار: هوية الموظف الموثقة ومعلمات الاسترداد المحددة. صحيح أن قواعد المطالبة يمكن أن توجه سلوك النموذج، وأن المزود يمكنه إرجاع استدعاء مقترح للأداة، إلا أن أياً من هاتين الآليتين لا يضمن تطبيق سياسة التفويض الخاصة بـ Ledgerline. إذن، ما هي المرحلة التي ينبغي أن توقف عملية استرداد المبلغ المرتبطة بتذكرة Jira في المقام الأول: قواعد المطالبة، أم النموذج، أم معالج الأداة، أم واجهة برمجة تطبيقات المدفوعات؟