تصميم صلاحيات MCP Tools حسب مستوى الخطورة بدل قائمة واحدة للجميع

إذا حصل Agent على كل MCP Tools بمجرد الاتصال، يصبح أي prompt أو خطأ تخطيط قادرًا نظريًا على تنفيذ أقوى إجراء متاح. الأفضل تصنيف الأدوات حسب الأثر: قراءة، تعديل قابل للتراجع، تغيير حساس، وتنفيذ نظام. ثم ربط كل طبقة بصلاحية وموافقة وسجل مناسب.

صنف الأداة حسب الأثر لا الاسم

read_tab و read_file عادة أقل خطرًا من send_message أو delete_profile أو run_command. قيّم الوصول للبيانات وحجم الضرر وقابلية الرجوع. أداة اسمها inspect قد تكشف secrets فتحتاج مستوى أعلى.

استخدم capabilities صغيرة

بدل permission مثل mcp.full، استخدم مجموعات: browser.read و browser.write و files.read و system.exec. هذا يسمح بإعطاء Agent أقل مجموعة لازمة للمهمة.

أضف gates للأثر العالي

Tool يرسل رسالة أو ينفذ command يمكن أن يطلب confirmation أو policy approval. لا تعتمد على أن ال ـLLM سيسأل تلقائيًا. enforcement يجب أن يكون في server.

سجل من طلب ومن نفذ

Audit يجب أن يفرق بين المستخدم وال Agent والجلسة و Tool call. سجل arguments بعد redaction والنتيجة ووقت التنفيذ. هذا يجعل التحقيق ممكنًا بدون حفظ secrets.

اختبر escalation

تأكد أن Agent بصلاحية read لا يستطيع تمرير input يجعل Tool داخليًا ينفذ write. راجع الحدود داخل implementation لا schema فقط.

اربط الصلاحية بال Resource Scope وليس بال ـTool فقط

قد يكون read_file مقبولًا داخل مجلد مشروع وغير مقبول على كامل filesystem، و browser.write مسموحًا لبروفايل اختبار لا للإنتاج. لذلك capability وحدها غير كافية؛ أضف resource scopes مثل profile IDs أو workspace paths أو domains. enforcement يجب أن يطابق tool + action + resource. اختبر wildcard expansion بعناية حتى لا يمنح scope أوسع من المقصود. بهذا يصبح نفس Agent قادرًا على العمل بمرونة داخل حدود مشروعه بدون امتلاك وصول شامل لكل بيانات المؤسسة.

اختبر Deny Paths بنفس جدية Success Paths

من السهل اختبار أن المستخدم المخول يستطيع استدعاء Tool، لكن الأهم أن المستخدم غير المخول يفشل في كل variation. اختبر IDs خارج scope، wildcard غريب، resource محذوف، profile من workspace آخر، و Tool alias إن وجد. تأكد أن error لا يكشف وجود مورد حساس. استخدم property-based tests لل ـscope matcher إذا كان يدعم patterns معقدة. أي bypass في طبقة authorization يجعل دقة Agent غير مهمة، لذلك يجب أن تكون اختبارات المنع جزءًا من CI عند إضافة Tool أو نوع resource.

اختبار التحكم قبل منح الصلاحية

في «تصميم صلاحيات MCP Tools حسب مستوى الخطورة بدل قائمة واحدة للجميع» اختبر النظام بأداة قراءة أولًا ثم أداة تغيير منخفضة المخاطر، مع تسجيل المدخل والقرار والنتيجة دون أسرار. افصل بين ما يستطيع النموذج اقتراحه وما يستطيع تنفيذه، وضع approval أو policy على الأفعال الحساسة. جرّب مدخلًا غامضًا ومدخلًا يحتوي تعليمات متعارضة، وتأكد أن حدود الصلاحيات لا تتغير بسبب صياغة المستخدم. القيمة هنا ليست في عدد الأدوات التي يستطيع ال ـAgent استدعاءها، بل في أن كل استدعاء يمكن تفسيره ومراجعته وإيقافه عند فشل شرط الأمان أو عدم اكتمال السياق.