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

إذا كنت تستخدم Claude Code أو أي وكيل برمجة آخر بالذكاء الاصطناعي، فخصّص عشر دقائق لمستودعاتك أولًا. ابحث عن ملفات إعدادات الوكلاء التي جرى رفعها إلى المستودع، وبدّل كل بيانات اعتماد تحتويها، وفعّل فحص الأسرار (secret scanning) في GitHub. المفاتيح المسروقة تُعاد بيعها بسرعة (تصف Unit 42 حالة استغرقت دقائق فقط)، لذلك تأتي الفحوصات قبل القصة.

شغّل هذه الفحوصات على مستودعاتك أولًا

ابدأ بالملف الذي تدور حوله قصة Claude Code: .claude/settings.local.json. وجدت شركة الأمن Apiiro منه 104,185 نسخة في 103,617 مستودعًا عامًا، وضمّت 1,122 نسخة منها سرًّا واحدًا على الأقل (The Hacker News). وهذه طريقة البحث عن ملفاتك.

1. 1ابحث في مؤسستك على GitHub عن الملف باسمه (استبدل اسم مؤسستك بالاسم الموجود هنا؛ يتطلب GitHub CLI).
2. 2تحقق مما إذا كان الملف قد رُفع يومًا في كل مستودع تعمل عليه، بما في ذلك الفروع القديمة. فالسجل التاريخي يحتفظ بما حذفه آخر commit.
3. 3اقرأ الموافقات المحفوظة بحثًا عن أي شيء يشبه كلمة مرور أو token أو سلسلة اتصال.
4. 4افحص السجل التاريخي كاملًا، وأضف قاعدة لكلمات المرور المكتوبة داخل الأوامر، فمجموعات القواعد الافتراضية تفوّتها غالبًا.

# 1. Find the files across an organization
gh search code --owner YOUR-ORG --filename settings.local.json

# The same search in the GitHub web search box
#   org:YOUR-ORG path:.claude/settings.local.json

# 2. Was it ever committed, on any branch?
git log --all --oneline -- .claude/settings.local.json .claude/settings.json

# 3. List what you have approved with "don't ask again"
jq -r '.permissions.allow[]' .claude/settings.local.json

# 4. Grep the folder and its history for the usual suspects
grep -rEn 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}' .claude/
git log --all -p -- .claude | grep -E 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}'

هذه أوامر قياسية في git وjq وgrep، لكن تعامل مع مخرجاتها كخيط يقودك، لا كحكم نهائي. فبحث الكود في GitHub لا يرى إلا ما هو موجود اليوم على الفرع، ولهذا وُجدت الخطوة 2.

لمرحلة الفحص بالأدوات، Gitleaks وTruffleHog هما الأداتان اللتان استخدمتهما Apiiro. شغّلهما على السجل التاريخي، ثم أضف قاعدة مخصصة، لأن القواعد الافتراضية تلتقط المفتاح لكنها لا تلتقط كلمة مرور تأتي بعد خيار في الأمر.

gitleaks git --redact -v .
trufflehog git file://.

# .gitleaks.toml
[extend]
useDefault = true

[[rules]]
id = "password-inside-command"
description = "Password passed on a command line"
regex = '''(PGPASSWORD=|sshpass -p |mysql -p)\S+'''

هذه القاعدة المخصصة تستحق مكانها. شغّلت Apiiro الأداتين على كل ملف وجدته: رصدت gitleaks 564 ملفًا من أصل 1,122 ملفًا تحوي أسرارًا، ورصدت TruffleHog منها 643، وفاتت الأداتين معًا 215 حالة، معظمها كلمات مرور مكتوبة بعد PGPASSWORD= أو sshpass -p أو mysql -p (The Hacker News).

وتنصح Apiiro فرق الأمن أيضًا بمعاملة .claude/ و.cursor/ و.gemini/ و.specstory/ وملفات ذاكرة الوكلاء كمجلدات تحمل أسرارًا، مثل .env. وسنجري البحث نفسه لكل وكيل مثبّت لدى فريقك: فالسجل الذي يحفظه Cursor أو GitHub Copilot أو Codex قد يحوي مفتاحًا لُصق فيه أيضًا.

كيف تضع نقرة موافقة واحدة كلمة مرور في مستودعك

يسأل Claude Code قبل تشغيل معظم أوامر الـ shell. اختر "Yes, and don't ask again" فيكتب قاعدة سماح في .claude/settings.local.json. وتقول وثائق Anthropic إن موافقة Bash بهذه الطريقة تدوم "permanently per repository and command" (Claude Code docs). المشكلة في شكل القاعدة. فقد تكون نمطًا مثل npm test *، وقد تكون الأمر نفسه حرفيًا، وحين يحتوي الأمر على كلمة مرور تصبح كلمة المرور محفوظة بنص صريح.

يُفترض أن يبقى الملف محليًا. وبحسب وثائق الإعدادات لدى Anthropic، ففي أول مرة يكتب فيها Claude Code الملف داخل مستودع لا يتجاهله أصلًا، يضيف **/.claude/settings.local.json إلى قائمة استثناءات git العامة لديك، أما الملف الذي تنشئه يدويًا فيحتاج سطرًا خاصًا بك في .gitignore (Claude Code docs). وهذا يحمي جهازًا واحدًا، لا نسخة مستنسخة جديدة، ولا ملفًا أُنشئ يدويًا، ولا ملفًا رُفع قبل وجود قاعدة التجاهل.

أكثر من ثلث الأسرار التي وجدتها Apiiro يفتح قاعدة بيانات مباشرة، بينها 379 كلمة مرور لقواعد بيانات. ومن بقية الأسرار 43 بيانات دخول SSH لخوادم عامة، و42 token لـ GitHub وGitLab وnpm، و23 مفتاح AWS. وتملك ثلاث وستون مؤسسة ملفات متأثرة، وفي نصف المستودعات التي فيها سر كان الملف موجودًا 217 يومًا على الأقل. لم تختبر Apiiro ما إذا كان أي منها لا يزال يعمل، غير أن شركة أبلغتها أكدت أن مفتاحها كان فعّالًا.

ردّ Anthropic حتى الآن هو تعليق واحد على Hacker News

أغلق بوت آلي بلاغ خلل قُدّم في 2025 بحالة "not planned" بعد 60 يومًا دون نشاط، وتقول Apiiro إن أيًّا من البلاغات الأخرى ذات الصلة التي تستشهد بها لم يتلقَّ ردًّا من Anthropic (The Hacker News). وجاء الرد العلني على Hacker News من معلّق عرّف نفسه بأنه "Boris from the Claude Code team". كتب أن "Historically Claude Code has not done secret scrubbing"، وأن الفريق "looking into what we can do to prevent this"، وأن "the files were manually created and checked in" في هذه الحالة. وأضاف: "Permission rules are old hat. Everyone should be using auto mode instead."

بيانات Apiiro لا تنسجم مع تفسير الإنشاء اليدوي. ففي 539 مستودعًا من أصل 1,105 مستودعًا تتبعتها، عدّل الملف commit يذكر Claude كمشارك في التأليف. وسطر المشاركة في التأليف لا يثبت من نفّذ git، لكن يصعب التوفيق بينه وبين ملفات أنشأها شخص يدويًا. نرى أن بيانات الـ commits أصعب في الرد من التعليق، وسنتعامل مع الملف على أنه شيء يستطيع Claude Code رفعه إلى المستودع إلى أن تقول Anthropic غير ذلك.

Grok Build سرّب مرتين، وبطريقتين مختلفتين

هناك قصتان عن Grok Build تختلطان معًا، وتحتاج كل منهما إلى إصلاح مختلف. (تسمي التغطيات الشركة SpaceXSI أو SpaceXAI.)

جاءت الأولى في وقت سابق من 2026. حلّل باحث ينشر باسم cereblab النسخة Grok Build 0.2.93 وأفاد بأنها رفعت مستودعات Git كاملة مُتتبَّعة، بما فيها سجل الـ commits والأسرار ومفاتيح API المرفوعة، إلى تخزين سحابي (The Next Web). وبحسب ذلك التحليل كان الرفع أكبر بنحو 27,800 مرة مما تحتاجه المهمة، وأفيد بأن مفتاح الخصوصية لم يفعل شيئًا. وكانت xAI قد روّجت للأداة بعبارة "nothing from your codebase transmitted to xAI servers during a session". أقرّ Elon Musk بحدوث عمليات النقل وقال إن بيانات المستخدمين السابقة ستُحذف. وتضيف TNW أنه لا يوجد تدقيق مستقل أكد الحذف.

أما الثانية فهي التي تتصدر الأخبار الآن، ولا علاقة لها بالمستودعات. وجدت شركة الأمن Claroc أن روابط المشاركة في Grok Build يمكن العثور عليها من أشخاص لم تُرسل إليهم أصلًا (Claroc). تذكر Engadget أن كل رابط استخدم عبارة عشوائية من أربع كلمات بانتروبيا تصل إلى 38 بت، وُضعت "to the left of the domain" (Engadget). أي أنها داخل اسم المضيف (hostname)، وتشرح Claroc أن خدمات DNS السلبي (passive DNS) تجمع عمليات البحث هذه. أما المحادثات المشتركة في ChatGPT وGemini فتبقي سرّها في مسار الـ URL، وهو ما لا يراه DNS. تكتب Claroc: "Nobody would guess one, and nobody needs to, because the dataset lists them."

احتوت التطبيقات المكشوفة على مواد حقيقية. تذكر Claroc خريطة مناطق مبيعات لـ 594 حسابًا استراتيجيًا، وثمانية عروض إعلانية على X، وأربع لوحات حسابات معلنين حية، وتطبيقًا للعاملين في مجموعة مستشفيات يضم قائمة بأكثر من 3,500 موظف، ولوحة مناوبات حية لإدارة إطفاء بها اسم كل رجل إطفاء ورقم شارته. ومن العناوين التي اختبرتها، فُتح 94.7% منها دون تسجيل دخول. وتقدّر Claroc أن نحو 2% من التطبيقات احتوت مواد خطيرة بما يكفي لتصنَّف عالية أو حرجة.

تقول Claroc إن SpaceXSI أزالت التطبيقات الأربعة والعشرين التي بناها موظفوها، "but not the apps of other Grok users and organizations". وتضيف Engadget أن الشركة لم تستجب بحسب التقارير إلا بعد أن أشارت Claroc إلى Musk ومسؤول آخر في الشركة على X. وتذكر مدونة Claroc أن SpaceXSI أجابت عن أسئلة أحد الصحفيين وقالت إن تطبيقات Grok خاصة إلى أن يختار صاحبها مشاركتها، لكنها لم ترد على البلاغ نفسه. لم نجد أي بيان يقول إن التطبيقات الأخرى ستُزال.

الحل للمستخدمين صريح. تعامل مع كل ما بُني أو شورك عبر Grok Build على أنه عام، وأزل الروابط التي لا تحتاجها، وبدّل أي بيانات اعتماد لامست تطبيقًا شاركته. لا يفيد هنا أي سطر في .gitignore.

المفاتيح المسروقة تُعاد بيعها خلال دقائق

تصف Unit 42 التابعة لـ Palo Alto Networks ما تسميه "token jacking"، حيث تُباع مفاتيح API المسروقة للذكاء الاصطناعي عبر "محطات تحويل" (transfer stations) في السوق الرمادية تبيع وصولًا مخفّضًا إلى النماذج المتقدمة (Unit 42). ومن مصادر المفاتيح التي تذكرها مستودعات الكود المكشوفة وبرمجيات سرقة المعلومات (infostealers) وحزم npm الملوثة. وفي إحدى الحالات دمج المهاجمون بيانات اعتماد مكشوفة في محطة تحويل خلال دقائق، وتبعتها "nearly a million dollars in charges" قبل اكتشاف الأمر. وتقول Unit 42 إن الضحايا لديهم "very little recourse to recover funds". ودفاعاتها هي المملة المعتادة: حدود إنفاق مع تنبيهات، وtokens قصيرة الأجل بدل المفاتيح طويلة الأجل، ومراجعة كل حساب ذي صلاحيات يستطيع تعديل الحدود.

أصلح التسريب: تجاهل، ثم أوقف التتبع، ثم بدّل المفاتيح

بدّل المفاتيح أولًا، ونظّف ثانيًا. فالمفتاح الملغى لا قيمة له في كل نسخة متفرعة ونسخة مخزنة مؤقتًا، أما المفتاح الذي حذفته من آخر commit فقط فما زال فعّالًا في السجل التاريخي. يقول GitHub إنه ينبغي تبديل بيانات الاعتماد المكشوفة فورًا، ويصف تنظيف السجل بأنه "time-intensive and often unnecessary if you've already revoked the credential" (GitHub docs).

# Rotate the exposed credentials first (table below), then:

# Stop tracking the local file (keeps your copy on disk)
git rm --cached .claude/settings.local.json

# Add to the repo's OWN .gitignore, not just your global excludes
printf '%s\n' '.claude/settings.local.json' '.specstory/' >> .gitignore

git add .gitignore
git commit -m "Stop tracking agent local settings"

# Drop any allow rule that looks like it holds a secret, even if never committed
jq '.permissions.allow |= map(select(test("PGPASSWORD|password|token|secret|key"; "i") | not))' \
  .claude/settings.local.json > .claude/settings.local.json.new \
  && mv .claude/settings.local.json.new .claude/settings.local.json

فكّر قبل تجاهل .cursor/ أو .gemini/ بالكامل، فبعض الفرق ترفع قواعد مشتركة إليهما عمدًا.

تبديل المفاتيح لدى المزوّدين الكبار

لكل مزوّد زر في لوحة التحكم لهذا الغرض، والترتيب الآمن هو: أنشئ البديل، ثم انشره، ثم أوقف المفتاح القديم. فالحذف أولًا قد يوقف الإنتاج.

لأي مزوّد غير مذكور في الجدول، ومنهم Anthropic وxAI، لم نتحقق من خطوات التبديل، فاتبع وثائقه الخاصة. أما كلمات مرور قواعد البيانات وبيانات دخول SSH، وهي معظم ما وجدته Apiiro، فغيّر كلمة المرور، وأنهِ الجلسات المفتوحة، ثم راجع سجلات الوصول منذ اليوم الذي رُفع فيه الملف أول مرة.

فعّل ماسحات GitHub وتعرّف على حدودها

يفحص secret scanning السجل التاريخي الكامل لكل فرع، إضافة إلى issues وpull requests وdiscussions وwikis. وهو مجاني وتلقائي في المستودعات العامة؛ أما المستودعات الخاصة والداخلية في المؤسسات فيتطلب GitHub Secret Protection (GitHub docs). وعند رصد صيغة مفتاح تخص شريكًا، يُبلغ GitHub ذلك المزوّد، وقد يلغي المفتاح دون أي تنبيه في مستودعك.

Push protection هي الطبقة التي كانت ستوقف كثيرًا من هذه الملفات قبل أن تصبح عامة. فهي تمنع أي push يحتوي على سر مرصود. وبحسب وثائق GitHub، فإن إعداد المستوى الشخصي مفعّل افتراضيًا للـ push إلى المستودعات العامة على GitHub.com، بينما إعداد مستوى المستودع معطّل افتراضيًا ويحتاج إلى مدير المستودع أو مالك المؤسسة أو مدير الأمان لتفعيله (GitHub docs). وهي تفحص أنماط المزوّدين، والأنماط العامة مثل المفاتيح الخاصة وسلاسل الاتصال، وأنماطك المخصصة، وفئة يرصدها الذكاء الاصطناعي للأسرار غير المهيكلة مثل كلمات المرور، وهي في معاينة عامة. وتبدو هذه الفئة الأخيرة موجّهة إلى الفجوة التي وجدتها Apiiro. ولا تنطبق الحماية على الـ push عبر REST API؛ أما الـ push من سطر الأوامر وcommits واجهة الويب ورفع الملفات فتشملها.

اعرف أيضًا باب الالتفاف. فبشكل افتراضي يستطيع أي شخص لديه صلاحية الكتابة تجاوز الحظر باختيار سبب، منها "I'll fix it later"، فيفتح ذلك تنبيهًا ويرسل بريدًا إلى المالكين. وإذا كانت وكلاؤك يرفعون commits نيابةً عنك، فاضبط التجاوز المفوَّض (delegated bypass) كي لا يستطيع تمرير سر إلا أشخاص محددون.

إعدادات صلاحيات الوكيل التي ينبغي تغييرها اليوم

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

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

الأمر الذي ينبغي أن ينفذه وكيلك يبدو هكذا psql "$DATABASE_URL"، فتخزّن قاعدة الموافقة اسم متغير لا غير. حمّل المتغير من مدير أسرار أو من ملف تعريف الـ shell، لا من ملف يستطيع الوكيل قراءته.

هناك تفصيلان في الوثائق يهمّان الفرق: قواعد allow في ملف .claude/settings.json المرفوع تنتظر حتى يثق كل زميل بالمجلد، بينما تُطبَّق قواعد deny وask فورًا، ولا تسري أوضاع auto وbypassPermissions من إعدادات المشروع أو الإعدادات المحلية. ويمكن للمؤسسات تقييد قواعد السماح عبر allowManagedPermissionRulesOnly. ويقول عضو فريق Claude Code المقتبس أعلاه إن وضع auto يغني عن قواعد الصلاحيات. ومع ذلك سنُبقي قواعد منع .env: سطران يُطبَّقان لحظة رفع الملف.

في الأدوات الأخرى تختلف أسماء الإعدادات، لكن السؤال واحد: أين تخزّن الأداة الموافقات أو السجل أو النصوص المحفوظة، وهل هذا المكان داخل مستودع؟ وبحسب الوثائق، وجدت Apiiro أن Claude Code هو الوحيد من بين 16 وكيل برمجة قارنتها الذي يُؤكَّد أنه يحفظ الأمر الموافَق عليه كاملًا في ملف مشروع افتراضيًا. أما الخمسة عشر الآخرون فقد تسرّب أيضًا عبر النصوص المحفوظة والمفاتيح الملصقة وملفات الذاكرة. ويغطي مقارنة وكلاء البرمجة في الطرفية ومقال Cursor مقابل Copilot مقابل Windsurf ما تخزّنه كل أداة.

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

المستخدم مسؤول عن التبديل، والمزوّد مسؤول عن الإعداد الافتراضي

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

الإعدادات الافتراضية سياسة، وهنا حسم الإعداد الافتراضي النتيجة. فلو كان Claude Code ينقّي الأسرار قبل حفظ القاعدة، أو يكتب سطر التجاهل في .gitignore الخاص بالمستودع نفسه، لأُغلقت الثغرة من المصدر. تقول Anthropic إنها تنظر في ذلك (ونريد موعدًا). وبلاغ خلل أغلقه بوت لعدم النشاط لا يبعث على الطمأنينة، وبيانات الـ commits لا تتفق مع "manually created".

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

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

قائمة تحقق للفريق كله

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

الأسئلة الشائعة

هل من الآمن رفع .claude/settings.local.json إلى المستودع؟

لا. فهو يحوي موافقاتك الشخصية وقد يحوي بيانات اعتماد. تقول وثائق Anthropic إن Claude Code يُبقيه خارج git عند إنشائه الملف، عبر استثناء عام، وإن النسخة المنشأة يدويًا تحتاج سطر تجاهل خاصًا بك. أضفه إلى .gitignore في كل مستودع، وأوقف تتبعه بـ git rm --cached إن كان قد رُفع يومًا.

هل أحتاج إلى تبديل المفاتيح إذا كان مستودعي خاصًا؟

نعم، إذا حوى الملف يومًا بيانات اعتماد. فالمستودعات الخاصة تُستنسخ على الحواسيب المحمولة وعلى أجهزة CI، وتُتفرّع إلى حسابات أخرى، وتتحول أحيانًا إلى عامة. وفحص الأسرار في GitHub للمستودعات الخاصة في المؤسسات يتطلب خطة مدفوعة، فربما لم يكن لديك أي فحص آلي.

هل يزيل حذف الملف من مستودعي السر؟

يزيله من آخر commit فقط ولا شيء غير ذلك. فالسجل التاريخي والنسخ المتفرعة والنسخ المخزنة مؤقتًا تحتفظ بالنسخة القديمة، وقد وجدت Apiiro 734 سرًّا لا يظهر إلا في الإصدارات الأقدم من الملف. بدّل بيانات الاعتماد أولًا، ولا تعِد كتابة السجل إلا إذا أردت مستودعًا مرتبًا.

هل تعاني GitHub Copilot وCursor وCodex من المشكلة نفسها؟

أكدت Apiiro هذا السلوك، وهو حفظ الأمر الموافَق عليه كاملًا في ملف مشروع افتراضيًا، لدى Claude Code وحده من بين 16 وكيلًا قارنتها. وهذا لا يبرّئ الآخرين. فأي وكيل يكتب نصوصًا محفوظة أو ذاكرة داخل مجلد عملك يحتاج إلى قواعد التجاهل نفسها.