خصوصية وكلاء البرمجة بالذكاء الاصطناعي: 5 خرافات تم دحضها

عشرات رسائل الاحتيال يومياً، مخصصة باسمك الأول والأخير الحقيقيين، والخرق ليس قاعدة بيانات مُخترقة ولا قائمة تسويقية مسرّبة. إنه ترويسة User-Agent التي أرفقها وكيل البرمجة بالذكاء الاصطناعي بطلبات ويب لم توافق عليها عن علم. هذا ما اكتشفه المطورون حين تتبعوا موجة رسائل مزعجة إلى Claude Code، الذي كان يختم عناوين البريد الإلكتروني للحسابات على طلبات HTTP الصادرة أثناء عمليات جلب الويب والبحث. وتفسير Anthropic نفسه أسوأ من الخلل تقريباً: فقد حقنوا بريد الحساب في سياق النموذج ليتمكن من كتابة وسوم @author بشكل سليم، لكن النموذج، بوصفه روبوتاً مساعداً متعاوناً، بدأ يعرضه على أي موقع يطلب جهة اتصال. قضيت سنوات في تدقيق سلوك الشبكة لأدوات تعمل على أجهزة المطورين، وهذه الحادثة مثال تعليمي شبه مثالي. لنأخذ إذن الخمس معتقدات التي أسمعها أكثر من غيرها عن خصوصية أدوات الوكلاء، ونختبر كلاً منها أمام ما حدث فعلاً.

الخرافة 1: «وكيل البرمجة الخاص بي يتواصل فقط مع واجهة برمجة مزود النموذج»

هذا هو النموذج الذهني الذي يبدأ به أغلب الناس: الوكيل أنبوب أنيق بين طرفيتك وخوادم Anthropic (أو OpenAI، أو أي جهة أخرى). شيفرتك تدخل، والرموز تخرج، ونقطة الشبكة الوحيدة المهمة هي api.anthropic.com.

هذا خطأ. أداة السطر الأوامر الوكيلة الحديثة عميل HTTP عام الغرض يصادف أن يقوده نموذج لغوي. لديها أداة WebFetch تجلب أي رابط، وأداة WebSearch تصل إلى بنية البحث التحتية، وأداة Bash، أي أن بإمكانها تشغيل curl وwget وpip install وnpm install وgit clone وكل ملف تنفيذي آخر على نظامك يتعامل مع الشبكة. حين تقرر أنها تحتاج توثيقاً أو حزمة أو سجل تغييرات أو وثيقة من هيئة الأوراق المالية، تذهب وتحضره من المكان الذي تظن أن الشيء موجود فيه. كل تلك الطلبات تصدر من عنوان IP الخاص بك، من شبكة شركتك، حاملةً أي ترويسات قرر النموذج كتابتها في ذلك الصباح.

والنموذج قادر على الإبداع. بعد انتشار قصة البريد الإلكتروني، فحص مهندس سجلات خادم الويب الخاص به فوجد طلبات من وكلاء فرعيين بسلاسل User-Agent مثل company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup)، تحمل اسم جهة عمله ومستودع GitHub الذي كان يعمل فيه. لم يكن الوكيل يسرّب قيمة إعداد، بل كان يؤلف ترويسات تعريفية من السياق، تماماً كما قد يوقّع متدرب متعاون اسمه الكامل وفريقه ومشروعه على كل بريد بارد. إذا أردت نظرة أعمق على سبب سهولة حدوث ذلك بسبب البنية، فقد كتبنا عن كيف تُبنى أدوات سطر الأوامر للبرمجة الوكيلة، والخلاصة أن الحلقة والسياق ومجموعة الأدوات قوية بقدر ما تحتاج لتسبب المتاعب.

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

الخرافة 2: «وضع بريد للتواصل في User-Agent من آداب الروبوتات الحسنة»

في هذه الخرافة ذرة حقيقة، وهذا ما يجعلها خطيرة. هناك عرف حقيقي يقضي بأن الزواحف المنضبطة تعرّف نفسها وتوفر جهة اتصال. بعض الخدمات تفرضه بصرامة. فواجهة EDGAR التابعة لهيئة الأوراق المالية الأمريكية، على سبيل المثال، ترفض بشكل قاطع الطلبات التي تحمل User-Agent عامة من curl وتطالب بجهة اتصال معلنة، ويمكنك التحقق من ذلك بنفسك في عشر ثوانٍ:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

لذلك فالنموذج الذي تعلّم أن «بعض الواجهات تريد عنوان اتصال في User-Agent» ليس يهلوس، بل يطابق نمطاً من آداب الإنترنت الحقيقية. وإذا كان ذلك النموذج يحمل بريد حسابك في سياقه، فلديه عنوان اتصال واحد متاح ليعرضه. وقد قال مهندس Anthropic الذي شرح الحادثة ذلك بالحرف: بعض المواقع تطلب من الوكلاء جهة اتصال، وكان Claude يقدم أحياناً البريد الذي بحوزته.

هنا ينكسر الزعم. العرف يقضي بأن مشغّل الروبوت يوفر جهة اتصاله هو، أي الكيان الذي يشغّل الزاحف، ليتمكن مشرف منزعج من الوصول إلى جهة مسؤولة. زاحف Anthropic يعرّف نفسه بأنه Anthropic، وزاحف Google بأنه Google. لكن حين يجلب وكيلك صفحة، ينبغي أن تكون جهة الاتصال للمشغّل هي صفحة الدعم لدى مزود الأداة أو عنوان قمت أنت بضبطه عمداً، لا بريد الحساب الشخصي الذي استخدمته لدفع الاشتراك. توصي RFC 9110 بعدم الإفراط في معلومات التعريف في User-Agent، وكل مهندس خصوصية أعرفه يعتبر بيانات التعريف الشخصية غير المطلوبة في ترويسات الطلبات عيباً، دون نقاش. آداب الروبوتات لم تُوضع أصلاً لكشف هوية الإنسان الجالس خلف الروبوت.

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

الخرافة 3: «نوافذ الإذن والصندوق الرملي يحفظان هويتي»

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

أولاً، أنظمة الأذونات تتحكم في أي الأدوات تعمل، لا في ما يكتبه النموذج داخل الطلبات التي تقوم بها تلك الأدوات. الموافقة على «نعم، اجلب هذا الرابط» لا تخبرك شيئاً عن الترويسات التي ألّفها النموذج لعملية الجلب. والموافقة على استدعاء Bash يشغّل curl تخبرك بأقل من ذلك، فسلسلة الأمر تمر أمامك ولا أحد يقرأ العلامة -A. ثانياً، واجهة الأذونات تعمل لكل إجراء على حدة، بينما التسريب خاصية للسياق. فبمجرد حقن بريد حسابك في سياق النظام، وهو أمر لم يره المستخدمون ولم يستطيعوا رفضه، أصبح متاحاً لكل استدعاء أداة، ولكل وكيل فرعي، ولكل سطر curl، طوال الجلسة. رُسم محيط الصندوق الرملي حول نظام الملفات، ومسار التسريب كان النص الذي يولده النموذج نفسه.

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

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

الخرافة 4: «إنه مجرد إعداد، قلب المفتاح وتصبح في أمان»

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

جاء العلاج في جزأين. أولاً، إضافة مدمجة (cc-plugin-privacy، مفعّلة افتراضياً من الإصدار v2.1.317) تمنع السلوك بشكل حتمي، أي فحص صارم لا اقتراح يُقدَّم للنموذج. وثانياً، وهو الأهم، أزالت Anthropic بريد الحساب من سياق النموذج بالكامل. لاحظ ترتيب الأهمية هنا. الإضافة مرشح على المخرجات، أما إزالة البريد من السياق فهي إزالة للقدرة نفسها. المرشح قد يفوته شيء، أما نموذج لم يعرف بريدك أصلاً فلا يستطيع تسريبه، مهما كان مبدعاً في تأليف الترويسات.

لا يمكنك أن تتخلص من كشف البيانات بالتوجيه بالكلام. إن كان النموذج يرى شيئاً، فبإمكانه أن يُخرجه. الإخفاء الموثوق الوحيد هو الحذف من المصدر.

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

الخرافة 5: «أصلح المزود الخلل، إذن يمكنني التوقف عن القلق»

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

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

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

كيف تدقق حركة شبكة وكيلك بنفسك

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

1. اعترض الحركة. وجّه الوكيل إلى mitmproxy ودعه يعمل جلسة عمل حقيقية. أدوات سطر الأوامر المبنية على Node تحترم عادة متغيرات بيئة الوكيل بعد أن تثق بشهادة CA الخاصة بك:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

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

2. افحص سجلات بنيتك التحتية. إن كنت تدير أي خدمات ويب، فابحث في سجلات الوصول عن سلاسل User-Agent الخاصة بالوكلاء. بهذه الطريقة اكتُشفت الترويسات المؤلفة في الخرافة الأولى. هذا لا يكلفك شيئاً، وغالباً ما يكشف حركة الوكلاء الفرعيين التي يفوتها التقاط الجهاز المحلي.

3. قيّد الخروج من الشبكة. أقوى ضابط هو جعل فئات كاملة من التسريب مستحيلة. شغّل الوكيل داخل حاوية أو آلة افتراضية تسمح سياسة شبكتها فقط بنقاط النهاية التي يحتاجها بشكل مشروع: واجهة النموذج، ومستودعات الحزم لديك، وربما GitHub. مع Docker يعني ذلك شبكة مخصصة مع جدار ناري للخروج، وعلى جهاز Mac توفر Little Snitch أو Lulu قواعد لكل عملية. إن لم يستطع الوكيل الوصول إلى مواقع ويب عشوائية من صندوقه الرملي، فلن يسلّم هويتك لمواقع عشوائية أيضاً. سيضطر إلى أن يطلب منك جلب الأشياء، وهذا احتكاك، والاحتكاك هو الغاية.

4. قلّل ما تعرفه الأداة. استخدم بريداً مخصصاً منخفض القيمة لحسابات الأدوات، لا عنوان عملك الأساسي. وأزل التفاصيل التعريفية من ملفات الإعداد العامة التي يقرؤها الوكيل (~/.gitconfig ملف شائع تسحبه الوكلاء). وإن دعمت الأداة ذلك، فشغّلها تحت مستخدم نظام تشغيل منفصل بمجلد منزل خاص به. التقليص يتفوق على الترشيح في كل مرة.

5. على مستوى المؤسسة، وجّه الحركة عبر وكيل مُدار. إن كانت شركتك توفر أدوات الوكلاء للمهندسين، فأجبر حركتهم على المرور عبر وكيل خروج مع تسجيل، وأضف فحص الترويسات إلى خط المعالجة. سجلات استعلامات DNS وحدها كانت ستكشف نمط وكيل يتفرع إلى مئات النطاقات غير المعتادة. وهذا هو الموقف نفسه الذي تطبقه على أي CI runner أو جهاز بناء، وهو الإطار الصحيح تماماً: الوكيل بنية بناء لديها آراء.

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