حوكمة استخدام الأدوات من قِبَل الوكلاء في سير العمل المالي

الوكيل القادر على استدعاء الأدوات قادر على تحريك الأموال، وطبقة التفويض هي التي تقرّر ما إذا كان يجوز له ذلك. قبل أن يلمس الوكيل أي نظام مالي نشترط أربعة أمور حول كل أداة: هوية مُقيّدة النطاق تُسمّي الوكيل والشخص الذي يعمل نيابةً عنه معاً، وفحص سياسة (policy) يجري على خادم الأداة لا داخل الأمر (prompt)، وحدود لكل إجراء ولكل نافذة زمنية، وسجلّ لا يقبل إلا الإضافة (append-only) لكل محاولة.

النموذج يقترح، وطبقة الأداة هي التي تحسم. الإخفاق الذي يتخيّله الجميع هو أن يقول النموذج شيئاً خاطئاً. أمّا الإخفاق الذي يكلّفك فعلاً فهو أن يُصدر النموذج استدعاءً يبدو سليماً مثل transfers.create بطرفٍ مقابلٍ خاطئ، أو أن يعيد محاولة دفعة ثلاث مرات لأن انتهاء المهلة بدا وكأنه فشل. النموذج اللغوي مولِّد لخطواتٍ تاليةٍ معقولة، وواجهة الدفع (payment API) تفعل بالضبط ما يُطلب منها. لا شيء داخل المُحوِّل (transformer) يعرف أن هذا الـPOST بالذات يُفرِغ حساباً تشغيلياً في نهاية الربع. لذلك لا يمكن للحوكمة أن تعيش داخل الاستدلال. عليها أن تجلس على السلك الواصل بين الوكيل ونظام السجل (system of record).

الهوية وأقل امتياز عند حدود الأداة

ابدأ برفض أن يرث الوكيل كامل صلاحيات الإنسان. الوكيل الذي يقرأ سجلّ معاملات عميلٍ في خدمة الدعم لا يحتاج إلى النطاق الذي يُطلِق ردّ أموال، ولا أيٌّ من هذين يحتاج إلى النطاق الذي يغيّر مستفيداً. صِغْ كل أداة بوصفها إذناً مستقلاً، لا كل نظام.

نمنح الوكيل هوية خدمة (service identity) خاصة به، ونمرّر المستخدم المُنفِّذ بوصفه طرفاً أصيلاً (principal) منفصلاً في كل طلب. عندئذٍ يُقاطع خادم الأداة بين أمرين: ما يُسمح لفئة هذا الوكيل بفعله أصلاً، وما يحقّ لهذا المستخدم بعينه فعله. فأداة ردّ الأموال التي يستطيع المستخدم استدعاءها يدوياً تصبح قابلة للاستدعاء من الوكيل داخل هذا التقاطع فقط. وهذا يعالج أيضاً مشكلة النائب المخدوع (confused deputy)، حيث يملك الوكيل صلاحيات واسعة ويستعيرها أمرٌ مُتلاعَبٌ به. فإذا كان نطاق الوكيل نفسه ضيّقاً، لن يجد الأمر المُختطَف ما يستعيره إلا القليل.

وبعبارة ملموسة، يعني أقل امتياز هنا:

• بيانات اعتماد واحدة لكل سطح أداة، تُصدَر قصيرة الأجل، لا مفتاح منصّة مشترك أبداً.
• نطاقات مُعبَّر عنها كأفعال على موارد (invoices.read، payments.initiate_below_1000)، لا أدوار عريضة مثل finance_admin.
• الفصل بين القراءة والكتابة في أداتين مختلفتين حتى حين تدعمهما الواجهة نفسها، كي لا يُمنح سير عمل للقراءة فقط صلاحية كتابةٍ بالخطأ.
• فحوص الاستحقاق تُحلّ مقابل خدمة التفويض نفسها التي يقصدها مستخدموك البشر، فيكون هناك مصدر حقيقة واحد وموضع واحد للإلغاء.

تحقّق من الإجراء، لا من الجملة

استدعاء الوكيل للأداة هو ادّعاء، وينبغي أن تعامله كما تعامل أي مُدخَل من عميل: غير موثوق حتى يُثبت الخادم أنه آمن. مكان التحقّق هو خادم الأداة أو وكيل وسيط (proxy) أمامه، لأنه الموضع الوحيد الذي لا يبلغه حقن الأوامر (prompt injection).

لأي إجراء دفعٍ أو دفتر أستاذ (ledger)، نفحص على جانب الخادم، قبل تنفيذ أي شيء:

• صحّة المخطّط والنوع، بما في ذلك أن يكون المبلغ موجباً، وبالعملة التي يحملها الحساب فعلاً، وضمن الدقّة الرقمية (precision) التي يستخدمها دفتر الأستاذ.
• الثوابت التجارية (business invariants) التي لا يملك النموذج رؤية موثوقة لها: أن الطرف المقابل موجود وليس على قائمة عقوبات أو قائمة حظرٍ داخلية، وأن الحساب المصدر يملك أموالاً مُصفّاة، وأن الإجراء لا يخرق عتبة موافقة تستوجب تدخّل إنسان.
• صحّة الرقم عند لحظة القرار (point-in-time correctness) لأي قيمة حسبها الوكيل. فإن جمع الوكيل تعرّضاً (exposure) ليبرّر رفع حدٍّ ما، أعِد حسابه من مخزن السمات (feature store) اعتباراً من طابع زمن القرار بدلاً من الثقة بالرقم الوارد في الأمر.
• التكرار الآمن (idempotency). كل استدعاء يُحدِث تغييراً يحمل مفتاحاً يولّده العميل، كي لا تؤدّي إعادة محاولة، أو خطوة خطّةٍ مُكرَّرة، أو انتهاء مهلة شبكة أساء الوكيل تفسيره على أنه فشل، إلى تنفيذٍ مزدوج. المعالجة المباشرة الشاملة (straight-through processing) دون مفتاح تكرارٍ آمن هي الطريق الذي تصير به تعليمة واحدة دفعتين.

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

حدود المعدّل والميزانيات وسجلّ التدقيق

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

نضع سقوفاً على التواتر وعلى القيمة التراكمية معاً. تحصل كل أداة على حدٍّ أقصى لعدد الاستدعاءات في الدقيقة، وتحصل الأداة المُحدِثة للتغيير على ميزانية نقدية متدحرجة أيضاً: ما لا يزيد على N من التحويلات أو X من إجمالي القيمة في الساعة لهوية هذا الوكيل، بصرف النظر عمّا إذا كان كلٌّ منها يجتاز التفويض. خرق الميزانية يُدخل الوكيل في وضع مُتراجِع (degraded mode) يستطيع فيه القراءة والصياغة، لكن عليه أن يسلّم كل عملية كتابةٍ إلى إنسان. هذا هو منطق ميزانية الإيجابيات الكاذبة (false-positive budget) نفسه الذي تشغّله أصلاً في مراقبة المعاملات، مُطبّقاً على الوكيل نفسه بوصفه فاعلاً.

السجلّ الكامن تحت كل هذا ليس اختيارياً. كل استدعاء أداة، سواء سُمح به أو رُفض، يكتب حدثاً لا يقبل إلا الإضافة (append-only): هوية الوكيل، والطرف الأصيل المُنفِّذ، والنطاق المُحلّل، والوسائط الدقيقة بعد التحقّق، والقرار، وإصدار السياسة الذي اتخذه. يمنحك ذلك سلسلة نسب (lineage) من قيدٍ في دفتر الأستاذ رجوعاً إلى تشغيل الوكيل المحدَّد والأمر الذي أطلقه. حين يسأل المُراقِب المالي لماذا خرجت دفعة في الثانية صباحاً من آخر يوم في الربع، يكون الجواب استعلاماً لا تحقيقاً. وهو أيضاً ما يجعل الانحراف (drift) مرئياً: إن ارتفع معدّل الرفض على أداةٍ أسبوعاً بعد أسبوع، فإمّا أن سلوك النموذج تغيّر أو أن أحداً يجسّه، وكلاهما أمرٌ تريد أن تراه قبل أن تراه التسوية.