تأمين وكلاء الذكاء الاصطناعي باستخدام أدوات Laravel MCP

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

لقد قمت مؤخرًا ببناء أدوات MCP لتطبيق Laravel متعدد المستأجرين (multi-tenant). كان لدي هدف واحد: السماح للوكيل بقيادة التطبيق دون السماح له برؤية بيانات شخص آخر.

المشكلة في أدوات MCP

كل أداة MCP هي نقطة نهاية (endpoint). يقوم الوكيل باستدعاء أداة، ويقوم خادمك بتشغيل الكود. في تطبيق متعدد المستأجرين، يجب على كل أداة الإجابة على سؤالين:

  • هل يُسمح لك بالقيام بهذا؟
  • هل يُسمح لك بالقيام بذلك في هذه المؤسسة المحددة؟

إذا أغفلت أحدهما، فستتسرب البيانات.

لماذا تفشل تقنية تعدد المستأجرين القياسية هنا

في تطبيقات الويب العادية، لديك جلسات (sessions). تستخدم النطاقات العامة (global scopes) لتصفية البيانات حسب معرف المؤسسة (organization ID). هذا يعمل لأن "المؤسسة الحالية" تكون دائمًا في الجلسة.

أدوات MCP لا تستخدم الجلسات، بل تستخدم الرموز (tokens). لا توجد برمجيات وسيطة (middleware) لضبط سياق المستأجر (tenant context). إذا اعتمدت على نطاق عام يبحث عن جلسة، فلن يجد شيئًا، وقد يؤدي ذلك بعد ذلك إلى إرجاع كل صف في قاعدة بياناتك. هذا تسريب صامت للبيانات.

الحل: التصفية الصريحة

لا تعتمد أبدًا على النطاق المحيط (ambient scope) مع مصادقة الرموز. قم بالتصفية بشكل صريح في كل مرة.

لقد أنشأت trait واحدًا للتعامل مع هذا:

trait ResolvesOrgEvents
{
    protected function resolveOrgEvent(Authenticatable $user, string $uuid): ?Event
    {
        if (empty($user->organization_id)) {
            return null;
        }

        return Event::query()
            ->withOrganization($user->organization_id)
            ->where('uuid', $uuid)
            ->first();
    }
}

يتبع هذا النهج أربع قواعد:

  • استخدم UUIDs: لا تستخدم أبدًا المعرفات ذات الزيادة التلقائية (auto-increment IDs). يجب ألا يتمكن الوكلاء من تخمين المعرفات عن طريق تغيير رقم.
  • مصدر واحد للحقيقة: يعيش فلتر المؤسسة في trait واحد، وتستخدمه كل أداة.
  • إعادة استخدام الأذونات: لا تبتكر أذونات جديدة للوكلاء. استخدم نفس سلاسل الأذونات (permission strings) التي يستخدمها تطبيق الويب الخاص بك. هذا يمنع الوكيل من امتلاك قوة أكبر من المستخدم البشري.
  • تحديد الآثار الجانبية: استخدم التعليقات التوضيحية (annotations) لتوضيح ما إذا كانت الأداة للقراءة فقط أو مُمكّنة للكتابة.

اختبار الحدود

يجب عليك اختبار المسار السلبي. لا تكتفِ باختبار ما إذا كانت الأداة تعمل، بل اختبر عدم قدرة مستخدم من المؤسسة (أ) على رؤية بيانات المؤسسة (ب).

إذا حاول وكيل الوصول إلى UUID من مستأجر آخر، يجب أن تعيد الأداة "غير موجود" (not found). لا ينبغي أن تخبر الوكيل بأن البيانات موجودة ولكنها تخص شخصًا آخر.

تعامل مع كل أداة ذكاء اصطناعي كنقطة نهاية غير موثوقة. الانضباط هو الطريقة الوحيدة للحفاظ على أمان بياناتك.

Source: https://dev.to/nasrulhazim/giving-an-ai-agent-the-keys-without-giving-it-the-building-rbac-org-scoped-mcp-tools-in-laravel-43oi