ضوابط MCP: صلاحيات آمنة لوكلاء الذكاء الاصطناعي

رمز MCP هو كلمة مرور حسابك وقد رُكّبت عليها واجهة API. أعطه لوكيل وسيصبح لديك مستخدم لا يتعب أبدًا، يقرأ أي صفحة تشير إليها، وينفّذ بالضبط ما تقوله آخر تعليمة في سياقه. في أغلب الأوقات هذا ما تريده. هذه الصفحة عن بقية الأوقات.

كل ما يلي تم التحقق منه على الخادم الفعلي في التاريخ المذكور أعلى الصفحة: قائمة الأدوات مأخوذة من tools/list على https://mcp.eqvps.com/mcp، والحدود من الـ API نفسها. إن كنت جديدًا، فاقرأ أولًا ربط عميل MCP ورموز API، ثم عُد إلى هنا.

نموذج التهديد: ما الذي يسوء فعلًا

ثلاثة أمور، بالترتيب الذي نراها به:

1. الوكيل يسيء الفهم. عبارة "نظّف جهاز الاختبار" تتحول إلى إعادة تثبيت الخادم الخطأ. لا نية سيئة، مجرد نموذج ملأ فراغًا في التعليمات.
2. حقن التعليمات (prompt injection). يقرأ الوكيل نصًا لم تكتبه أنت (ملف README، رد من الدعم، صفحة ويب مسحوبة) فيطلب منه ذلك النص فعل شيء ما. إذا كان الوكيل يحمل رمزًا بصلاحيات كاملة، فالتعليمة المحقونة تملكها أيضًا.
3. الرمز يتسرّب. ينتهي به المطاف في سجل shell أو مستودع عام أو إعداد MCP مشترك أو سطر في ملف سجل.

يتحقق خادم MCP من أن الرمز صالح وأن الخادم يتبع ذلك الحساب (أو مفوَّض له). لا يعرف ما الذي قصدته. كل ضابط أدناه يجيب عن سؤال واحد: ما حجم الضرر الممكن إذا كانت التعليمات خاطئة؟

كل أدوات MCP حسب مستوى الخطر

يرى رمز العميل 45 أداة (خادم MCP 1.6.0). أما رمز الموزّع (rk_…) فيرى مجموعة منفصلة من 30 أداة للموزّعين ولا يرى أيًا من هذه، لذا تضم نقطة النهاية 75 أداة إجمالًا. يحصل عميلك من tools/list على مجموعته فقط.

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

لا نرسل بعد تعليقات أدوات MCP التوضيحية (readOnlyHint وdestructiveHint)، لذا لا يستطيع عميلك تصنيفها بنفسه. اضبط الموافقات يدويًا وفق المستويات أدناه.

المستوى 0 — عامة، بلا رمز (5)

المستوى 1 — قراءة الحساب، بلا آثار جانبية (15)

المستوى 2 — تغيّر الحالة، لا تنفق شيئًا (17)

المستوى 3 — تنفق المال أو تحذف البيانات أو تمنح الوصول (8)

سجل تغييرات مجموعة الأدوات

الإصدار العامل متاح للعموم: curl -s https://mcp.eqvps.com/healthz. عندما يتغير، يتغير هذا الجدول معه.

الرصيد هو سقف الإنفاق

EQVPS خدمة مسبقة الدفع. لا بطاقة محفوظة ولا حد ائتماني ولا رصيد سالب: أقصى ما يستطيع الوكيل إنفاقه هو ما في الرصيد. ثلاث أدوات تنفق: order_vps وchange_plan وcreate_sandbox. وتجديدات خوادمك الحالية تُخصم من الرصيد نفسه.

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

تحذير واحد، وهو جدي. إذا أبقيت الرصيد منخفضًا جدًا لكبح الوكيل، فستبدأ تجديدات خوادمك أنت بالفشل وتدخل الخوادم فترة السماح. قاعدتنا العملية: دورة تجديد واحدة لما يعمل لديك أصلًا، مضافًا إليها ميزانية المهمة الحالية للوكيل. يشرح دليل ميزانية الوكيل طريقة الحساب. وإذا أعطيت الوكيل محفظة خاصة به فيها أموال، فتلك المحفظة تصبح سقفًا ثانيًا عليك مراقبته أيضًا.

أقل الصلاحيات: لا يوجد رمز للقراءة فقط (بعد)

بصراحة: كل رمز عميل يملك الصلاحيات نفسها التي يملكها الحساب في لوحة التحكم. اسم الرمز ومدة صلاحيته قابلان للضبط، أما النطاقات (scopes) فلا.

أضيق ما هو متاح اليوم هو التفويض. تمنح الوكيل حسابه الخاص برصيد صفري وتفوّض له خادمًا واحدًا:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

والأمر نفسه عبر REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

يجب قبول الدعوة أثناء تسجيل الدخول بذلك البريد (accept_delegation)، ويمكن أن تكون expires_days من 1 إلى 365. خطوة بخطوة مع لقطات شاشة: تفويض الوصول والوصول في التوثيق.

انتبه إلى آخر سطرين في العمود الأيمن. لا يستطيع المفوَّض إنفاق أموالك، لكنه يستطيع مسح ذلك الخادم. فعّل النسخ الاحتياطي على أي خادم يستطيع الوكيل إعادة تثبيته.

نظافة الرموز

رمز واحد لكل وكيل، باسم واضح. أنشئه من لوحة التحكم ← الإعدادات ← رموز API للوكلاء، أو هكذا:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

يُعرض الرمز مرة واحدة فقط. مدة الصلاحية من 1 إلى 1825 يومًا، و365 إن لم تحدد. للوكلاء كنا سنختار 90.

احفظه في ملف لا يقرؤه أحد سواك، لا في المستودع ولا في الموجّه (prompt) ولا في متغير shell تنسخه هنا وهناك:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # المتوقع: -rw-------

ثم حمّله في خدمة الوكيل عبر EnvironmentFile= (systemd) أو set -a; . ~/.config/eqvps/agent.env; set +a.

دوّره قبل انتهاء صلاحيته. أداة refresh_token، أو POST /auth/tokens/{id}/refresh، تصدر رمزًا جديدًا بالاسم نفسه وتلغي القديم فورًا. إذا كان الرمز مكتوبًا مباشرة في إعدادات عميل MCP، فحدّثها فورًا بعد ذلك، وإلا ستحصل الجلسة التالية على 401.

تحقق مَن يستخدم ماذا: يعرض GET /auth/tokens كل رمز مع اسمه وتاريخ انتهائه وlast_used_at. رمز لا تعرفه، أو رمز استُخدم بعد أن أوقفت الوكيل، هو إشارة الإنذار.

إذا تسرّب رمز

بهذا الترتيب:

1. ألغِه. لوحة التحكم ← الإعدادات ← رموز API للوكلاء ← إلغاء، أو curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. يتوقف عن العمل من الطلب التالي.
2. ابحث عن رموز جديدة لم تنشئها أنت، وألغِها أيضًا.
3. افحص ما قد يكون تأثر: سجل الخدمة لكل خادم، والفواتير والرصيد، وlist_delegations بحثًا عن وصول لم تمنحه.
4. غيّر كلمات مرور root على كل خادم كان ذلك الرمز يراه. فـ get_vps_status مع reveal: true يسلّم كلمة مرور root، أي أن الرمز المسرّب يعني كلمة مرور root مسرّبة. وافحص ~/.ssh/authorized_keys وأنت هناك.
5. أغلق باب كلمة المرور. إذا لم يكن لحسابك كلمة مرور قط، فربما عيّن حامل الرمز واحدة عبر set_password. سجّل الدخول برمز يصلك بالبريد وغيّرها.

الوقاية من الخطوة 5 مجانية: عيّن كلمة مرور للحساب بنفسك الآن، وستعيد set_password الرمز 409 لكل من يأتي بعدك.

الموافقة البشرية

ما يفرضه الخادم:

• تتطلب reinstall_vps وreset_password وcancel_service مع type: immediate أن يكون confirm مساويًا لاسم المضيف بالضبط (وDELETE صالح أيضًا لإعادة التثبيت وإعادة التعيين).
• تتطلب change_plan القيمة confirm: true.
• الإلغاء الافتراضي هو end_of_period: يعمل الخادم حتى نهاية الفترة المدفوعة، وundo_cancel تتراجع عنه.
• حدود المعدل لكل حساب: إعادة التثبيت 4/دقيقة، إعادة تعيين كلمة المرور 6/دقيقة، الطاقة 20/دقيقة، الطلبات 20/دقيقة. تكفي لمنع حلقة من تكرار الأمر خمسين مرة، لكنها لا تكفي لإيقاف استدعاء خاطئ واحد.

كن واضحًا بشأن ماهية confirm. إنه يمنع الوكيل من التصرف بناءً على "نظّف ذلك". ولا يوقف مهاجمًا، لأن اسم المضيف على بُعد استدعاء واحد لـ get_vps_status. الموافقة الحقيقية موجودة في عميل MCP الخاص بك. معظم العملاء يستطيعون السؤال قبل كل استدعاء أداة: دع المستويين 0 و1 يعملان بحرية، واجعل المستوى 3 يسأل دائمًا. في العملاء التي تدعم صلاحيات لكل أداة، مثل ملف settings.json في Claude Code (الخادم مسجّل باسم eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

وأضف سطرًا إلى تعليمات الوكيل أيضًا. وحده ليس إجراء أمان، لكنه يقلل حالات سوء الفهم (اتركه بالإنجليزية، فالنماذج تفهمه بالقدر نفسه):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

إذا كان الوكيل يسجّل الدخول برمز بريد إلكتروني بدلًا من حمل رمز طويل الأجل، فراجع تسجيل دخول الوكيل عبر MCP.

التدقيق: ما الذي تراه لاحقًا

• قائمة الرموز (GET /auth/tokens، أو الإعدادات ← رموز API للوكلاء): الاسم وتاريخ الإنشاء والانتهاء وlast_used_at. لهذا السبب تحديدًا يستحق الأمر تسمية الرموز حسب الوكيل.
• سجل الخدمة (لوحة التحكم، صفحة الخادم): إجراءات الطاقة، وإعادات التثبيت، وإعادات تعيين كلمة المرور، وتغييرات الخطة، والمدفوعات، ولكل منها وقت وفاعل: أنت أو الدعم أو تلقائي. لا يخبرك أي رمز أو أي مفوَّض قام بالإجراء، بل فقط أنه جاء من جهتك.
• الفواتير والرصيد: كل خصم وكل استرداد.
• list_delegations: من يملك الوصول إلى ماذا، وحتى متى.

هذه الفجوة في سجل الخدمة هي الحد الصادق للتدقيق من جهة الخادم اليوم. إذا احتجت إلى معرفة أي وكيل فعل ماذا، فسجّل كل استدعاء أداة مع وسائطه (دون الأسرار) من جهة الوكيل.

الإعداد الذي كنا سنختاره

لوكيل يدير خادم إنتاج واحدًا:

1. حساب مستقل للوكيل، برصيد صفري، والخادم مفوَّض مع expires_days: 90.
2. رمز المالك يبقى معك، ولا يوجد في أي إعداد للوكيل.
3. نسخ احتياطي على ذلك الخادم، لأن المفوَّض يستطيع إعادة التثبيت.
4. أدوات المستوى 3 على "ask" أو "deny" في العميل.
5. رمز الوكيل في ملف بصلاحيات 600، يُجدَّد قبل انتهائه.

أما الوكيل الذي يحتاج إلى طلب خوادم أو تشغيل بيئات sandbox، فالتفويض لا يكفيه، لأنه يحتاج إلى رصيد. هنا يكون الرصيد هو سقفك: اشحنه لكل مهمة، وسمِّ الرمز، وراجع last_used_at مرة كل أسبوع. إذا كان رمز للقراءة فقط سيغيّر طريقة تشغيلك للوكلاء، فأخبرنا عبر الدعم: فهذا النوع من الملاحظات هو ما يحدد ما نبنيه لاحقًا.