حادثة لقطة Git البرمجية من ZCode: ما الذي يمكن لوكلاء البرمجة بالذكاء الاصطناعي رؤيته وتحميله وتذكّره

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

هذا التمييز مهم لأن .git قد يحتوي على معلومات لم تعد ظاهرة في قاعدة الشفرة الحالية، بما في ذلك الأسرار المحذوفة، والإصدارات القديمة من المصدر، وسجلات reflog، وأصول LFS، وسجل الفروع المحلي. يقول ZCode إن سلوك الرفع المتأثر قد أُصلح، لكن الحادثة تترك درسًا دائمًا: يحتاج وكلاء البرمجة بالذكاء الاصطناعي إلى حدود واضحة للبيانات، وليس مجرد إذن بـ"الوصول إلى المستودع".

ماذا حدث فعلًا مع ZCode؟

في 18 سبتمبر 2026، نشر المطور ferstar تحقيقًا بالهندسة العكسية في ZCode 3.12.3 بعد ملاحظته ملفات كبيرة على نحو غير متوقع ضمن دليل البيانات المحلي للتطبيق.

وفقًا لـ التحقيق الأصلي، أنشأ العميل لقطات مشفرة لمساحة العمل كان يمكن أن تتضمن ملفات المصدر، إضافة إلى .git وكائنات Git LFS وسجلات reflog والبيانات الوصفية للمستودع. كما احتوى العميل على خط أنابيب للحصول على بيانات اعتماد الرفع وإرسال أرشيفات مشفرة إلى Alibaba Cloud OSS.

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

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

هل رُفع المستودع الخاص بحجم 313MB فعلًا؟

لا.

احتوت لقطة المشروع التجاري على نحو 42,000 ملف، وأنتجت أرشيفًا مشفرًا بحجم يقارب 313MB. ووفقًا لتحديث الباحث في 19 سبتمبر، ظلت في جهاز محلي قيد الانتظار الحالة بعد 564 محاولة فاشلة لأنه تجاوز حد الرفع. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

وصل مستودع عام أصغر منفصل إلى الخدمة بنجاح. وكان يحتوي على 538 ملفًا وأنتج حمولة مشفرة أصغر بكثير.

لذلك، فالاستنتاج الصحيح ليس أن «كل مستودع ZCode قد رُفع». بل إن العميل القديم كان يحتوي على آلية وظيفية لرفع المستودعات، وكان نجاحها الفعلي يعتمد على اللقطة.

لماذا يُعد مجلد `.git` الجزء الأهم في هذه الحادثة

في لقطة الباحث الكبيرة، لم تكن معظم الحمولة شيفرة مصدرية حالية.

وهذا يعني أن نحو 86.6% من اللقطة جاء من .git. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

وهذا يغيّر تفسير الأمان بالكامل.

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

قد يشمل التعرض التاريخي ما يلي:

• ملفات مصدر محذوفة
• مفاتيح API أو رموز مميزة قديمة
• نقاط نهاية داخلية سابقة
• ميزات متروكة
• إعدادات تاريخية
• نشاط الفروع المحلية
• حالات مقتصرة على reflog
• أصول LFS تاريخية كبيرة

توضح وثائق Git reflog أن سجلات reflog تسجل القيم السابقة للمراجع المحلية. ويمكن أن توجد هذه السجلات محليًا حتى عندما لا يكون السجل المقابل قد دُفع إلى مستودع بعيد.

وهذا يمنحنا قاعدة أمنية مفيدة:

يجب أن يكون «قراءة مشروعي» و«قراءة سجل Git الخاص بي» إذنين منفصلين.

لماذا قد تظل الأسرار المحذوفة موجودة بعد إزالتها من الشيفرة

لا يؤدي حذف بيانات الاعتماد من أحدث ملف بالضرورة إلى حذفها من Git.

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

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

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

1. أبطل بيانات الاعتماد.
2. أزل السجل الحساس حيثما كان ذلك مناسبًا.
3. امنع إعادة اعتماد السر في الالتزام.

بالنسبة لوكلاء البرمجة بالذكاء الاصطناعي، يعني هذا أن ميزة واعية بالسجل يمكنها الوصول إلى بيانات لم تعد واجهة المحرر العادية تعرضها.

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

سياق النموذج وبيانات القياس عن بُعد والتدريب وعمليات رفع المستودع ليست الشيء نفسه

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

إصدار ZCode المتأثر مهم لأن الباحث أفاد بأن تعطيل خيار التحسين/التدريب لم يعطّل مسار اللقطات المنفصل. كما ذكر التقرير أن مفتاح تبديل فهرسة لقطة المستودع لم يمنع محاولات الحزم والرفع في ذلك الإصدار. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

وهذا يقود إلى قاعدة تنطبق على ما هو أبعد بكثير من ZCode:

لا تعني عبارة «لا تدرّب على بياناتي» عبارة «لا ترسل بياناتي».

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

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

التشفير لا يجيب عن أهم سؤال متعلق بالخصوصية

تم تشفير لقطة ZCode المتأثرة قبل رفعها.

يصف تقرير الهندسة العكسية تشفير AES-256-CTR للأرشيف، وتغليفًا باستخدام RSA-OAEP-SHA256 للمفتاح المتماثل. وقد قدمت الخدمة المفتاح العام لـ RSA، بينما لم يُخزَّن المفتاح الخاص المطابق محليًا. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

وهذا يحمي البيانات بطريقة تختلف عن التشفير الشامل الذي يتحكم فيه المستخدم.

إذًا، عبارة «كان المستودع مشفّرًا» غير مكتملة.

والسؤال الأقوى هو:

من يستطيع فك تشفيره؟

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

ما مقدار الوصول إلى المستودع الذي يحتاج إليه وكيل البرمجة فعليًا؟

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

لكن «قد يحتاج الوكيل إلى سياق واسع» لا يعني أن «كل ميزة ينبغي أن تتلقى كل بايت في المستودع».

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

بالنسبة إلى وكلاء البرمجة، نحتاج إلى حدّين مستقلين:

• حد الإجراءات: ما الذي يمكن للوكيل تغييره أو تنفيذه؟
• حد البيانات: ما الذي يمكن للوكيل قراءته أو إرساله؟

يمكن لوكيل لا يملك إذن الكتابة أن يسبب تعرضًا خطيرًا للخصوصية إذا كانت أذونا القراءة والشبكة لديه غير مقيّدة.

ما الذي غيّره ZCode بعد الحادثة؟

لا ينبغي وصف الحادثة كما لو كان معروفًا أن السلوك نفسه موجود في إصدارات ZCode الحالية.

في فحص لاحق لـ ZCode 3.14.0، أفاد الباحث بإزالة الملحق الجانبي السابق للرفع، وأن نقطة نهاية بيانات الاعتماد القديمة أعادت الحالة 404. واحتفظ المسار الذي جرى فحصه بوظيفة نقاط التحقق المحلية من دون آلية الرفع عن بُعد السابقة. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

تصف وثائق Wiki المستودع الحالية أيضًا حدًا للبيانات أضيق بكثير.

يذكر أن سياق Wiki يستثني:

• .git
• مجلدات التبعيات
• ناتج البناء
• ذاكرات التخزين المؤقت
• حالة وقت التشغيل المحلية
• مدعوم .gitignore الاستثناءات
• ملفات الإعدادات الحساسة المشتبه بها
• أهداف الروابط الرمزية

يُوثَّق ناتج Wiki المستودع باعتباره بيانات تطبيق محلية، وليس محتوى يُكتب مجددًا إلى المستودع.

يختلف هذا اختلافًا جوهريًا عن سلوك اللقطة الذي أُبلغ عنه في الإصدار 3.12.3.

هل يكفي المصدر المفتوح لجعل وكيل البرمجة خاصًا؟

لا.

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

قائمة التحقق الأكثر فائدة هي:

ولهذا السبب تُعرَّف بنية الذكاء الاصطناعي الخاصة بتدفق بياناتها أكثر مما تُعرَّف بكون ترخيص برنامجها مفتوح المصدر أم لا.

كيف ينبغي للمطورين تدقيق وكيل برمجة جديد بالذكاء الاصطناعي؟

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

1. اقرأ وثائق معالجة البيانات. افصل بين الاستدلال والقياس عن بُعد والتدريب والفهرسة والمزامنة والنسخ الاحتياطي.
2. تحقق من قواعد الاستبعاد. ابحث تحديدًا عن .git و.env والملفات المستبعدة والتبعيات وبيانات الاعتماد والروابط الرمزية.
3. ابدأ بمستودع قابل للتخلص منه. استخدم تعليمات برمجية غير حساسة أولًا.
4. افحص مساحة تخزين التطبيق المحلي. قد تكشف ذاكرات التخزين المؤقت أو اللقطات الكبيرة غير المتوقعة عن نطاق البيانات المخفي.
5. راقب حركة البيانات الصادرة. يمكن لسجلات الجدار الناري أو DNS أو الوكيل أو الموجّه تحديد الخدمات البعيدة.
6. استخدم ملفات اختبار غير ضارة. اختبر ما إذا كانت الملفات غير المرتبطة تدخل في سياق النموذج أو الرفع.
7. امنح أضيق الصلاحيات أولًا. وسّعها فقط عندما تتطلبها مهمة محددة.

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

ما ينبغي لوكيل البرمجة الذي يتبع مبدأ المحلية أولًا أن يفعله بشكل مختلف

لا تعني المحلية أولًا أن كل مهمة يجب أن تعمل دون اتصال.

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

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

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

الدرس الأكبر: الوصول إلى المستودعات إذن أمني

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

قد يجمع وكيل البرمجة الحديث بين:

• قراءة المشروع بالكامل
• دراية بـ Git
• تنفيذ الأوامر الطرفية
• الوصول إلى المتصفح
• نماذج عن بُعد
• مهام تعمل في الخلفية
• ذاكرة طويلة الأمد
• تحرير الملفات بشكل مستقل

وهذا يعني أن على المطورين مراجعة ما هو أكثر من الأوامر التي يمكن للوكيل تنفيذها.

ويحتاجون أيضًا إلى طرح الأسئلة التالية:

• ما الملفات التي يمكنه مراقبتها؟
• إلى أي مدى يمكنه الرجوع في السجل؟
• أيّ من تلك البيانات يغادر الجهاز؟
• أي خدمة تستقبلها؟
• ما مدة الاحتفاظ بها؟
• من يمكنه فك تشفيرها؟

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