الوصول للقراءة فقط ليس كافياً: ضوابط الحماية لوكلاء الذكاء الاصطناعي
غالباً ما يقول كبار المهندسين شيئاً واحداً للحفاظ على سلامة وكلاء الذكاء الاصطناعي: امنحهم صلاحية الوصول للقراءة فقط.
يبدو الأمر آمناً. يمكن للوكيل فحص الاستعلامات البطيئة أو تلخيص المخططات (schemas) دون كسر أي شيء.
لكن الوصول للقراءة فقط ليس نموذجاً للأمان، بل هو مجرد قيد.
في اللحظة التي يحتاج فيها وكيلك إلى القيام بعمل مفيد، سيعيقه وضع القراءة فقط. إذا وجد الوكيل فهرساً سيئاً أو صفاً تالفاً، فلن يتمكن من إصلاحه. سينتهي بك الأمر مع مساعد يشير إلى الحريق ولكنه لا يستطيع الإمساك بخرطوم المياه.
غالباً ما تستسلم الفرق وتمنح الوكيل صلاحية الكتابة. وهنا يبدأ الخطر الحقيقي.
السؤال الحقيقي ليس "هل يجب أن يكتب الوكيل"، بل السؤال الحقيقي هو "كيف تتحكم في عمليات الكتابة تلك".
لا تحاول التحكم في عمليات الكتابة عبر التعليمات. لا تضع قواعد في المطالبة النظامية (system prompt) مثل "لا تحذف جدولاً أبداً".
إن "حقن المطالبات" (Prompt injection) يجعل هذه القواعد عديمة الفائدة. يمكن للمهاجم استخدام صف من البيانات أو تعليق لخداع الوكيل وجعله يتجاهل قواعدك. إذا كانت ضوابط الحماية موجودة في نفس نافذة الوكيل، فيمكن للوكيل الالتفاف عليها عبر الجدال.
أنت بحاجة إلى التمييز بين عمليات الكتابة غير الخاضعة للرقابة وعمليات الكتابة الوسيطة.
• عمليات الكتابة غير الخاضعة للرقابة: يقرر الوكيل تشغيل أمر ما، وتقوم قاعدة البيانات بتنفيذه. التحكم الوحيد هو حكم الوكيل نفسه. • عمليات الكتابة الوسيطة: يمر الأمر عبر نقطة تفتيش خارج نطاق الوكيل. تقع نقطة التفتيش هذه في مسار البيانات بين الوكيل وقاعدة البيانات.
تعمل عملية الكتابة الوسيطة على النحو التالي:
- يقترح الوكيل عبارة (statement).
- يقوم بروكسي (proxy) أو مستوى تحكم (control plane) بتحليل العبارة.
- يصنف البروكسي مستوى المخاطر.
- يقرر البروكسي ما إذا كان سيسمح بها أو يطلب موافقة بشري.
هذا النهج يحميك من حقن المطالبات. قد تخدع تعليمات خبيثة الوكيل لكتابة أمر DROP TABLE ، لكنها لا تستطيع خداع البروكسي. فالبروكسي لا يقرأ نية الوكيل، بل ينظر فقط إلى أمر SQL الفعلي.
استخدم هذا الهيكل لتبقى آمناً:
- السماح التلقائي لعمليات القراءة الآمنة. اترك الوكلاء يشغلون استعلامات
SELECTبحرية للحفاظ على سرعة العمل. - تقييد عمليات الكتابة الخطرة. تطلب موافقة بشرية لعمليات
DELETEأوUPDATEأو تغييرات المخطط (schema). - تسجيل كل شيء. احتفظ بسجل غير قابل للتغيير يوضح من اقترح التغيير ومن وافق عليه.
لا تعتمد على النسخ المتماثلة للقراءة (read replicas) من أجل الأمان. تساعد النسخ المتماثلة في التحقيق، لكنها لا تستطيع تطبيق الإصلاحات. لإصلاح مشكلة في بيئة الإنتاج، يجب عليك الكتابة في قاعدة البيانات الأساسية (primary database).
تسمح الوساطة للوكيل بأن يكون مفيداً مع الحفاظ على سلامة بياناتك.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi