GateRook يتحقق من طلبات وكلاء الذكاء الاصطناعي في 3 خطوات قبل الوصول إلى البنية التحتية

إن منح وكيل ذكاء اصطناعي طرفية وكلمة مرور قاعدة البيانات طريقة سريعة للتخلص من النسخ اليدوي للسجلات. لكنه أيضا طريقة سريعة لفقدان السيطرة على ما قرأه الوكيل أو عدّله تحديدا. عبارة مثل «لا تلمس بيئة الإنتاج أبدا» داخل نص التوجيه ليست حماية قوية هنا: فقد يخطئ النموذج في تحديد البيئة، أو يسيء فهم تعليمة عثر عليها، أو يرسل استعلام SQL صحيحا إلى قاعدة البيانات الخطأ.

يقترح GateRook نقل التحكم إلى طبقة تنفيذ مستقلة بين عميل الذكاء الاصطناعي والبنية التحتية. وهو تطبيق مكتبي محلي يضم بوابة MCP وموصلات لقواعد البيانات والسجلات وواجهات API والخوادم، إلى جانب سياسات وصول وسجل موحد للاستدعاءات. المشروع مفتوح بموجب ترخيص Apache 2.0، لكن المادة كتبها مؤلف المشروع نفسه، ولذلك ينبغي التعامل مع الادعاءات المتعلقة بقدراته بوصفها عرضا لتصميم المنتج، لا تدقيقا أمنيا مستقلا.

ليست طرفية، بل أداة محددة النطاق

بدلا من وصول SSH عام، يحصل الوكيل، على سبيل المثال، على أداة للبحث في السجلات. ويحدد الطلب صراحة الاتصال والملف وعبارة البحث والفترة والحد الأقصى لحجم البيانات الممسوحة وعدد الأسطر المعادة. يستطيع الوكيل اختبار فرضية، لكنه لا يحصل على سطر أوامر عام.

هذا العقد أكثر فائدة من إذن عام يتيح «إلقاء نظرة على الخادم». يرى المالك الوسائط الفعلية للاستدعاء، ولا يظهر سر SSH في المحادثة، كما يكون حجم القراءة مقيدا مسبقا. وللعمليات المتكررة، تتوفر أوامر runbook ذات معاملات محددة الأنواع. لكن الغلاف لا يضمن شيئا في حد ذاته: فالأمر الخطير داخل runbook سيظل خطيرا.

تُقسم الموارد إلى ثلاثة كيانات. يصف Connector كيفية التعامل مع MySQL أو MongoDB أو Redis أو SSH أو أي نوع آخر من الأنظمة. وتحتفظ Connection بإعدادات مورد محدد وبيئته. أما Endpoint فيحدد الاتصالات والأدوات التي يراها عميل ذكاء اصطناعي بعينه. وبذلك يمكن فصل بيئتي التطوير والإنتاج عبر نقطتي دخول مختلفتين، من دون الاعتماد على انتباه النموذج.

لماذا لا تكفي موافقة واحدة

من الأمثلة الدالة استعلام SELECT من دون تحديد صريح لقاعدة البيانات. الاستعلام نفسه آمن من حيث نوع العملية، لكن الاتصال يتيح قاعدتي بيانات. يرفض GateRook الاستدعاء قبل وصوله إلى نظام إدارة قواعد البيانات، ويوضح السبب: لم تُحدد قاعدة البيانات. ولا تلغي عبارة المستخدم «أوافق» هذا الشرط الإلزامي.

تكون العملية أكثر صرامة عند الكتابة. يقترح الوكيل أمر UPDATE، فتصنفه البوابة على أنه تعديل وتنشئ طلب تأكيد مؤقتا. يرى الإنسان نص SQL الدقيق والاتصال والبيئة وتقديرا للأثر. وبعد الموافقة، تعيد النواة التحقق من الإعدادات وتنفذ الاستعلام المحفوظ. ولا يستطيع الوكيل استبدال SQL الذي تمت الموافقة عليه بتعبير آخر.

هذه نقطة معمارية مهمة: الإذن لا يرتبط باسم الأداة، بل بالمحتوى المحدد للعملية. إذا لم يرد المستخدم في الوقت المناسب، تنتهي صلاحية الطلب. وإذا كانت نتيجة الكتابة مجهولة بسبب انتهاء المهلة، فلا يجوز إعادة تنفيذ التعديل تلقائيا؛ فغياب الرد لا يعني أن قاعدة البيانات لم تتغير.

ما الذي ينبغي نقله إلى نظامك الخاص

لا تقتصر القيمة العملية لـ GateRook على التطبيق الجاهز. فهو نموذج جيد لأي بنية تحتية يُسمح للوكلاء بالوصول إليها: توفير أدوات متخصصة بدلا من shell، وفصل البيئات، ومنع الطلبات الملتبسة، وتأكيد payload غير قابل للتغيير، وتسجيل القرار مع نتيجته.

ومع ذلك، لا تحل البوابة محل صلاحيات البنية التحتية نفسها. ينبغي تنفيذ القراءة من بيئة الإنتاج عبر حساب مستقل يتمتع بأقل قدر من grants، مع تقييد الكتابة على مستوى نظام إدارة قواعد البيانات وواجهة API والخادم. كما أن التخزين المحلي للأسرار لا يعني أن البيانات لا تغادر الحاسوب مطلقا: إذ تُرسل نتائج الطلبات المسموح بها إلى عميل الذكاء الاصطناعي، وربما بعد ذلك إلى مزود النموذج. لذلك يلزم إخفاء البيانات الحساسة، وفرض حدود على المخرجات، ووضع سياسة واضحة للاحتفاظ بالسجلات.

الخلاصة الأساسية للمطور بسيطة: لا يجوز ترك التحكم في وصول الوكلاء داخل نص التوجيه. وعلى مستوى المنتج، ينبغي لواجهة التأكيد أن تعرض الإجراء وعواقبه، لا مجرد زر Allow مجهول المضمون. يعرض GateRook هذا النهج بصورة مقنعة، رغم أن التنفيذ ونموذج التهديدات والضمانات المعلنة لا تزال تحتاج إلى مراجعة مستقلة.