فصل أدوات القراءة عن أدوات الكتابة في MCP: أثره على الأمان والاختبار

إذا كانت Tool واحدة get_or_update_profile تقرأ أو تعدل حسب arguments، يصبح من الصعب معرفة خطرها ومنح permission دقيقة. فصل read عن write يجعل side effects واضحة من الاسم وال schema ويساعد Agent والإنسان على فهم ما سيحدث.

اجعل read خالية من الأثر قدر الإمكان

Read Tool لا تغير selection أو navigation إذا لم يكن ذلك جزءًا صريحًا. إذا احتاجت cache داخليًا فلا يجب أن يغير business state. هذا يسمح باستخدامها في planning و verification بثقة.

اكتب write بأسماء صريحة

set_proxy و close_tab و send_message توضح الأثر. required fields يجب أن تتضمن target ID لا تعتمد على current selection إن كان ممكنًا.

ابنِ permissions منفصلة

Agent التخطيط قد يملك read catalog فقط، والتنفيذ يحصل على write مؤقتة بعد approval. هذا pattern يقلل blast radius خصوصًا في Work mode.

اختبر dry run بسهولة

مع فصل الأدوات يمكن تشغيل planning بالكامل ثم مقارنة proposed writes بدون تنفيذ. اختبارات integration تستخدم mock writes وتقرأ postconditions.

تجنب wrappers العامة

Tool عامة execute_action تعيد الغموض. إذا اضطررت لها لأسباب بنيوية، اجعل action enum محدودًا وتطبق permissions لكل action داخل server.

تعامل مع Read Tools التي تغير العالم ضمنيًا

بعض الأدوات المسماة قراءة قد تفتح URL أو mark message as read أو تحدث last_accessed. صنفها بدقة: pure read أو observational side effect أو write. إذا كان الأثر مهمًا للتطبيق، لا تمنحها permission قراءة عادية. وثق behavior في description. هذا يمنع افتراض أن catalog read-only آمن بينما Tool قياس مثل get_page قد تنفذ navigation أو trigger server-side behavior. الاختبار يجب أن يراقب state قبل وبعد الأدوات المصنفة قراءة.

استخدم Different Credentials لمرحلة القراءة والتنفيذ

فصل catalog يمكن تعزيزه بفصل credentials أو tokens. مرحلة planning تعمل بهوية read-only، وعند approval يحصل executor على token قصير العمر ل write محددة. حتى لو تم حقن planner أو أخطأ، لا يملك secret يمكنه الكتابة به. هذا pattern أكثر تعقيدًا لكنه مفيد في البيئات الحساسة. تأكد أن executor لا يقبل arbitrary plan بلا إعادة تحقق وأن token مقيدة بال resource/action/expiry.

اختبر الفصل مع سيناريو Token مسروق

في بيئة اختبار، افترض أن read token تسربت وحاول استخدامها لاستدعاء write Tool مباشرة أو عبر Tool wrapper. يجب أن يرفض server قبل الوصول لل implementation. ثم جرّب write token بعد expiry أو على resource مختلف. هذه الاختبارات السلبية تثبت أن الفصل فعلي في طبقة authorization وليس مجرد اتفاق بين Agent و orchestrator، وتوضح حجم الضرر لو انكشفت credential واحدة.

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

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