سياسات الوكلاء الشخصيين في Cloudflare: كيف تسمح لمساعدي الذكاء الاصطناعي بدخول موقعك أو تقيّدهم أو تحظرهم

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

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

لماذا يحتاج الوكلاء الشخصيون إلى سياسة خاصة بهم

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

مع برامج الزحف، تسأل نفسك: هل تريد أن يُستخدم محتواك؟ أما مع الوكلاء الشخصيين، فتسأل: هل تريد خدمة عميل اختار أن يرسل برنامجًا بدلًا منه؟ ولجانب برامج الزحف مجموعة قرارات خاصة به، نتناولها في خريطة ترحيل برامج الزحف في Cloudflare لفرق البحث.

تعامل مع حجة الحجم بحذر. ترى Cloudflare أن حركة مرور الوكلاء تنمو بسرعة وقد تتجاوز التصفح البشري التقليدي في المستقبل القريب. وفي سبتمبر، توقع الرئيس التنفيذي لـ Cloudflare، ماثيو برينس، أن تبلغ حركة مرور الروبوتات 1,000 ضعف حركة المرور البشرية خلال خمس سنوات. هذه توقعات صادرة عن شركة تبيع أدوات لإدارة هذه الحركة، وليست قياسات.

الفكرة الأكثر فائدة هي ما تسميه Cloudflare مبدأ الوساطة (Intermediation Principle): يجب الحفاظ على العلاقة التجارية بين المستخدمين والمواقع، وعلى المسؤوليات الأمنية لكل طرف، بصرف النظر عن وجود وسيط. فعميلك يظل عميلك حين يتولى مساعدٌ النقر بدلًا منه. وجزء كبير من هذا الإصدار محاولة لجعل هذا المبدأ قابلًا للتطبيق.

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

ما الذي تغيّر في سياسات الوصول

توجد الإعدادات في Security Settings (إعدادات الأمان). وكما يوضح إعلان Cloudflare عن الوكلاء الشخصيين، تضبط سياسة عامة للوكلاء (Agents)، ثم تختار سياسة مختلفة لكل وكيل شخصي مدعوم. ويحصل كل وكيل على أحد الإجراءات التالية:

• السماح بلا حظر (Allow, do not block): تمر حركة المرور المطابقة. وسأشير إليه من الآن فصاعدًا بـ«السماح».
• الحظر على الصفحات التي تحتوي على إعلانات (Block on pages with ads): يُوقَف الوكيل على الصفحات التي تعرض إعلانات، لكنه يظل قادرًا على الوصول إلى بقية الموقع.
• الحظر (Block): تُحظر حركة المرور المطابقة في الموقع بأكمله.

وللسياق، قُدّمت لوحة Account Abuse Protection (الحماية من إساءة استخدام الحسابات) التي تقوم عليها هذه الميزات في 2 أكتوبر 2026.

كيف تعمل الوراثة

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

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

قراءة فئة Personal Assistants

في Security Analytics (تحليلات الأمان)، يعرض مخطط Bot Analysis (تحليل الروبوتات) الآن فئة جديدة باسم Personal Assistants (المساعدون الشخصيون)، إلى جانب Verified Bot وLikely Human وLikely Automated وAutomated. افتح هذا العرض قبل أن تلمس أي سياسة. تحقق من حجم حركة مرور المساعدين المعروفين التي تصلك، وهل هي ثابتة أم ترتفع فجأة حول أحداث معينة. والأهم من ذلك، تحقق من المسارات التي تصل إليها.

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

ثمة قيد ينطبق منذ اليوم الأول. تنص وثائق Cloudflare على أن الطلبات الواردة من مساعدين لا تتعرف عليهم تظهر كحركة مرور عادية. لذا تعامل مع هذه الفئة باعتبارها حدًا أدنى، لا عدًّا كاملًا.

التحكم على مستوى الحساب عبر Hashed User ID

هذا هو الجزء من الإصدار الذي يعالج فخ الوكيل المشترك مباشرة. فإذا بدا أن مهاجمًا يستخدم وكيلًا على حساب ما، يستطيع محللو الاحتيال التخفيف من خطر ذلك الحساب عبر قاعدة WAF تستهدف Hashed User ID (معرّف المستخدم المجزّأ) الخاص به، من دون حظر الوكيل عن كل من يعتمد عليه. وتصف تغطية مستقلة من Unite.AI الآلية نفسها: فالقاعدة تستهدف Hashed User ID الخاص بالحساب لا الوكيل ككل.

هناك إجراءان: Managed Challenge (التحدي المُدار) يضيف قدرًا من الاحتكاك، بينما Block يوقف طلبات الحساب كليًا. وتقول وثائق Account Abuse Protection من Cloudflare إن الحساب المستهدف وحده هو الذي يتأثر، بما في ذلك عندما يستخدم مساعد ذكاء اصطناعي يعتمد عليه مستخدمون آخرون.

تعرض اللوحة أيضًا إشارات خاصة ببيانات الاعتماد. ففي مثال اللوحة الذي قدمته Cloudflare نفسها، أسفر نحو 2.4K حدث عن نتيجة تشير إلى تسريب اسم المستخدم أو كلمة المرور، مقارنة بـ 11.7K حدث صُنّفت فيها بيانات الاعتماد على أنها سليمة. يوضح ذلك شكل العرض، لكنه ليس معيارًا مرجعيًا لحركة المرور لديك.

خطّط مع مراعاة قيدين. أولًا، Account Abuse Protection متاحة في مرحلة الوصول المبكر (Early Access) لعملاء Bot Management Enterprise، من دون تكلفة إضافية لفترة محدودة حتى تصبح متاحة للجميع. ضع ميزانيتك على افتراض أن التسعير سيتغير. ثانيًا، تقصر وثائق Cloudflare رؤية مساعدي الذكاء الاصطناعي على أحداث تسجيل الدخول وإنشاء الحساب، لذا فإن أي إساءة في مواضع أخرى من الجلسة لن تُنسب إلى مساعد عبر هذه الميزة.

مصفوفة القرار بحسب نموذج العمل

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

الناشرون الممولون بالإعلانات

حين يقرأ مساعدٌ مقالك ويلخصه لمستخدمه، فقد لا تحقق تلك الزيارة أي إيرادات إعلانية. وقد مالت Cloudflare نفسها إلى هذا الاتجاه، إذ ذكر إعلانها في يوليو 2026 أنه بالنسبة لجميع النطاقات الجديدة المنضمة إلى Cloudflare، ستُحظر فئتا Training وAgent افتراضيًا على الصفحات التي تعرض إعلانات، بينما تظل فئة Search مسموحًا بها. غير أن الوثائق الحالية تصف إعدادات افتراضية مختلفة، وسأعود إلى ذلك أدناه، لذا تحقق من مناطقك (zones) بنفسك.

منتجات SaaS

بالنسبة لمنتج SaaS، فإن الوكيل الذي يسجل الدخول هو على الأرجح عميل يدفع ويؤتمت عمله الخاص. وحظر الوكلاء بالجملة يهدد بتعطل سير العمل وموجة من تذاكر الدعم. ويناسب إعداد السماح الموصى به هذا النموذج. وعندما تظهر إساءة، تصرّف على مستوى Hashed User ID بدلًا من الوكيل بأكمله.

التجارة الإلكترونية

الوكلاء يصلون بالفعل إلى صفحات الدفع. فقد أظهرت بيانات Microsoft Clarity ظهور صفحة الدفع في 25% من جلسات وكلاء الذكاء الاصطناعي مقابل 15% لدى البشر. فإذا حظرت وكيلًا، فقد تكون تحظر مشترين.

الحظر الشامل يحدث فعلًا. ففي أوائل أكتوبر، استحوذ Muse من Meta على 72% من طلبات وكلاء الذكاء الاصطناعي في بيانات HUMAN، وحظرت Amazon وكيل Muse من التسوق على موقعها. ونقترح التعامل مع أي حظر شامل منفرد باعتباره قرار شركة بعينها، لا نموذجًا يُحتذى لقرارك.

والتعرض للاحتيال حقيقي أيضًا. فقد أفادت Arkose Labs بأن 65.2% من عملائها شهدوا وصول وكلاء ذكاء اصطناعي إلى مسارات تسجيل الدخول والتسجيل والدفع. وهذه نسبة من عملاء Arkose، لا من الجلسات. ونقترح قراءتها كمؤشر على الاتجاه لا كمعيار لموقعك. ومع ذلك، فهي تدعم الجمع بين السماح والمراقبة النشطة للحسابات بدلًا من التعامل مع القرار على أنه فتح أو إغلاق.

المحتوى والتجارة معًا

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

جدول ملخص

دليل التشغيل: خط الأساس ثم الوراثة ثم التجاوز ثم الاحتواء ثم المراجعة (Baseline-Inherit-Override-Contain-Review)

نقترح تنفيذ هذا الدليل كحلقة من خمس خطوات. تُنتج كل خطوة مُخرجًا ملموسًا واحدًا، فتعرف متى تكتمل ومن أين تستأنف في المراجعة التالية.

الخطوة 1: خط الأساس

راجع حركة مرور Personal Assistants في Bot Analysis على مدى فترة طويلة بما يكفي لتغطية الدورات الأسبوعية المعتادة وأي عروض ترويجية. صنّف الصفحات التي يصل إليها المساعدون إلى صفحات إعلانات، وصفحات تسجيل الدخول وإنشاء الحساب، وصفحات المنتجات، وصفحات الدفع. المُخرج: عرض محفوظ في Bot Analysis وأبرز المسارات لكل وكيل.

الخطوة 2: الوراثة

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

الخطوة 3: التجاوز

ابدأ بكل وكيل على السماح. ولا تنقل أي وكيل إلى الحظر على الصفحات التي تحتوي على إعلانات أو إلى الحظر إلا عندما يبرر ذلك قيدٌ في السجل. إليك نموذجًا توضيحيًا، وليس سجلًا حقيقيًا لعميل:

المُخرج: قيد واحد لكل تجاوز. وأي تجاوز بلا قيد يعود إلى السياسة الأم في المراجعة التالية.

الخطوة 4: الاحتواء

إذا كان لديك Bot Management Enterprise، ففعّل Account Abuse Protection وصِغ قواعد WAF تستهدف Hashed User ID. ابدأ بـ Managed Challenge، ولا تصعّد إلى Block إلا عندما تدعم الأدلة ذلك. واكتب مسار التصعيد على غرار دليل تشغيل مفتاح إيقاف وكلاء الذكاء الاصطناعي، مع محفزات ومسؤولين واضحين، حتى لا يضطر المحلل المناوب إلى الارتجال. وسجّل كل قاعدة حساب بالطريقة التي تسجل بها التجاوز: مرجع الحساب، والإجراء، والمحفز، والمسؤول، وتاريخ الانتهاء. المُخرج: مسار تصعيد مكتوب وسجل للقواعد.

الخطوة 5: المراجعة

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

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

أخطاء شائعة

التعامل مع السماح على أنه هوية. كما يشير Forkast، تتحكم سياسة الوكيل في ما إذا كانت حركة المرور المطابقة مسموحًا بها، لكنها لا تثبت بمفردها هوية حساب المستخدم أو من فوّض الإجراء المحدد. ولا تزال المصادقة المعتادة لديك سارية، سواء كانت كلمات مرور مع المصادقة متعددة العوامل (MFA) أو طرح مفاتيح المرور مع آلية استرداد متينة.

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

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

نسيان الوراثة. إذا عدّلت سياسة Agents الأم، فستحتاج إلى إعادة تطبيق كل خيار خاص بكل وكيل.

قراءة رقم صغير في Personal Assistants على أنه دليل على قلة حركة مرور الوكلاء. يظهر المساعدون غير المعروفين كحركة مرور عادية، لذا قد تخفي فئة صغيرة صورة أكبر.

تحفظات وحدود

فجوة الرؤية. لا يحصل على التصنيف والتحكم لكل وكيل إلا المساعدون الذين تتعرف عليهم Cloudflare. فسياستك تغطي الوكلاء الذين تستطيع Cloudflare تحديدهم، لا كل مساعد مؤتمت.

تضارب المصادر بشأن الإعدادات الافتراضية. ذكرت مدونة يوليو 2026 أن النطاقات الجديدة ستحظر Training وAgent على صفحات الإعلانات افتراضيًا. أما الوثائق الحالية فتقول إن Search وAgents وTraining تستخدم السماح افتراضيًا للنطاقات الجديدة. وعندما يتعارض المصدران، فثق بلوحة التحكم لديك.

حدود الاكتشاف. في اختبار أجرته Resemble AI بنفسها، رصدت أدوات كشف الروبوتات ما بين 3.1% و14.8% من وكلاء الذكاء الاصطناعي المتنكرين. إنه رقم صادر عن مورّد دون حجم عينة منشور، لكن الاتجاه واضح: الوكلاء المصممون ليبدوا بشرًا يصعب اكتشافهم.

فجوة الهوية. وجدت Arkose Labs أن 97.7% من جلسات وكلاء الذكاء الاصطناعي المشروعة لم تحمل أي معرّف موثق بين 1 يوليو و30 سبتمبر. ونقترح التخطيط على افتراض أن حركة مرور الوكلاء المشروعة قد تصلك دون أي هوية موثقة مرفقة بها.

معايير في بداياتها. يشير منشور Trusted Agent Delegation إلى تحالف يعمل على تفويض الوكلاء، لكنه لا يذكر اسم عضو واحد، ولا يذكره موقع التحالف نفسه أيضًا. ويقول ذلك الموقع إن المعايير المفتوحة يجري تطويرها في IETF وW3C. توقّع أن تتغير الآليات مع نضج هذا العمل.

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