يمكن استخدام أدوات WebMCP التي تعرضها للعملاء لاختطافهم

أضف WebMCP إلى موقع الويب الخاص بك، ويمكنك تسليم وكلاء الذكاء الاصطناعي الزائرين مجموعة من الأدوات المسماة للاتصال بها. يمكن استخدام هذه الأدوات نفسها لقلب العملاء ضد الأشخاص الذين أرسلوهم. يحمل موقع مطور Chrome الآن إرشادات الأمان الخاصة بـ WebMCP، ويتم كتابة الكثير منها لمواقع الويب التي تعرض الأدوات بدلاً من الشركات التي تبني الوكلاء. اجعل موقع الويب الخاص بك جاهزًا للوكيل باستخدام WebMCP، وبذلك تكون قد فتحت أيضًا سطح هجوم، وإغلاقه هو مهمتك، وليس الوكيل.

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

تم تسمية Chrome بطريقتين لاختطاف العملاء من خلال WebMCP

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

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

يعمل هذا بسبب شيء ليس خطأ ولن يتم تصحيحه. تقول الإرشادات: “يتعامل طلاب LLM مع جميع النصوص والتعليمات وبيانات المستخدم، كتسلسل واحد من الرموز المميزة”، لذلك لا يمكن للنموذج فصل الجزء الذي قصدته كبيانات بشكل موثوق من الجزء الذي قصده المهاجم كأمر. ولهذا السبب يقول Chrome “إن الطبيعة الاحتمالية لـ LLMs تجعل من المستحيل ضمان السلامة داخل النموذج نفسه.” هذه هي نفس مشكلة الحقن الفوري التي لا يوجد بها حل نظيف داخل النموذج، والآن يرتدي البروتوكول. يوفر WebMCP لهذا الهجوم طريقًا نظيفًا ومنظمًا للتسليم من خلال الأدوات التي نشرتها عن قصد.

يتضمن جعل وكيل موقع الويب جاهزًا الآن جعله آمنًا للوكيل

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

الدفاعات ملموسة، وهي عبارة عن تعليقات توضيحية ترفقها بالأدوات التي تشحنها. untrustedContentHint “يصنف الحمولة بشكل صريح على أنها غير موثوق بها، للمساعدة في حماية سلامة موقعك مع توفير إشارة إلى الوكيل بأن هذه البيانات تتطلب تدقيقًا شديدًا”، ويقول Chrome متى يتم استخدامها: “إذا قامت إحدى الأدوات بإرجاع محتوى من إنشاء المستخدم (UGC) أو بيانات من مصادر خارجية، ففكر في إضافة ContentHint غير الموثوق به إلى الأداة.” readOnlyHint يمثل أداة لا تغير الحالة، والتي “تسمح للوكيل باتخاذ قرارات أفضل حول متى يطلب تأكيدات المستخدم.” exposedTo يقيد الأداة بمجموعة من الأصول التي تثق بها، والمكتوبة في التسجيل نفسه:

document.modelContext.registerTool({...}, {
 exposedTo: ['https://trusted.com']
});

يحدد Chrome ميزانيات الأحرف أيضًا، ووصف الأداة بـ 500 حرف ومخرج الأداة الواحدة بحوالي 1500 حرف، ويضيف requestUserInteraction() مسار لتأكيد الإجراء قبل إطلاقه. لنأخذ المثال الواضح، الأداة التي تعرض مراجعات المنتجات لوكيل التسوق. تأمينه ليس عملاً غريبًا: قم بتمييز مخرجاته بـ untrustedContentHint، تعيين readOnlyHint لأنه يقرأ بدلاً من أن يشتري، ويحد exposedTo إلى الأصول التي تخدمها فعلا. لا شيء من هذا هو عمل الوكيل. إنها مهمة مؤلف الأداة، والتي في معظم الفرق هي الويب أو CRO أو الأشخاص التسويقيون الذين يضيفون WebMCP ليبدو محدثًا، وليس الأشخاص الأمنيين الذين يقرؤون نماذج التهديد. هذه الفجوة هي المكان الذي تسوء فيه الأمور. أصبح الآن تحديد أي من المحتوى الخاص بك عبارة عن بيانات وليس أوامر جزءًا من شحن أداة، تمامًا كما أصبحت طريقة تعقيم المدخلات جزءًا من شحن نموذج.

اعتمد WebMCP، ولكن ضع نموذج التهديد لكل أداة أولاً

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

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

WebMCP مبكر. إنه موجود في تجربة Chrome Origin، ولا تزال المواصفات قيد التنفيذ، ولم تكشف معظم مواقع الويب عن أداة واحدة. هذه هي النافذة التي تقرر أن أمان الوكيل هو جزء من جاهزية الوكيل، قبل أن يتبين أن الأداة الأولى التي تشحنها هي الأداة التي تسلم الوكيل مراجعاتك وأي شيء يخفيه شخص ما بداخلها.

المزيد من الموارد:

تم نشر هذا المنشور في الأصل على No Hacks.

صورة مميزة: رومان سامبورسكي / شاترستوك