كيف تُبقي أسرارك بعيدة عن الشيفرة المُولَّدة بالذكاء الاصطناعي وعن إيداعات Git

وكلاء البرمجة بالذكاء الاصطناعي سريعون، لكن لديهم نقطة عمياء: فهم يلصقون مفتاح واجهة برمجة (API) في ملف، أو يطبعون رمزًا مميّزًا (token) في سجلّ، أو يُودِعون ملف .env كنت تنوي إبقاءه محليًا، دون أدنى تردّد. وأي وكيل لديه وصول إلى الطرفية — Claude Code وCursor وGemini CLI وCodex — يستطيع أيضًا قراءة إعدادات الصدفة (shell) وملفات مشروعك، وهو بالضبط المكان الذي تميل بيانات الاعتماد إلى الاختباء فيه. يأخذك هذا الدليل عبر إعداد عملي ومتعدّد الطبقات لتبقى أسرارك بعيدة عن الشيفرة المُولَّدة بالذكاء الاصطناعي وعن سجلّ Git لديك.

لماذا صار هذا أكثر أهميةً مع الذكاء الاصطناعي

تسريب مفتاح هو من أكثر الأخطاء شيوعًا وأعلاها كلفةً في البرمجيات، ومساعدو الذكاء الاصطناعي يرفعون المخاطر بطريقتين. أولًا، يُولِّدون الشيفرة بسرعة، فقد يصل مفتاح مُضمَّن بشكل ثابت (hardcoded) إلى عشرات الملفات قبل أن تلاحظ. ثانيًا، يَلتهم الوكلاء السياق بشراهة — وكما تُعبِّر مقالة عن إدارة الأسرار، ينبغي أن تُشير إعدادات الصدفة لديك إلى المفاتيح، لا أن تحتويها، لأنّ الوكيل قادر على قراءة كل ما تكشفه ملفات الإعداد (dotfiles). الحل ليس في عدم الوثوق بالأداة؛ بل في الحرص على ألّا توجد أسرار بنصّ صريح لكي يجدها أصلًا.

الخطوة 1: احفظ الأسرار في متغيّرات البيئة، لا في الشيفرة أبدًا

القاعدة الأساسية: يجب ألّا يظهر أي مفتاح واجهة برمجة أو كلمة مرور أو رمز مميّز كسلسلة نصّية صريحة في الشيفرة المصدرية. ضَعها في ملف .env في جذر مشروعك واقرأها في وقت التشغيل.

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

بهذه الطريقة لا تحتوي الشيفرة التي تُحرِّرها أنت (ووكيل الذكاء الاصطناعي لديك) سوى اسم السرّ، لا قيمته أبدًا.

الخطوة 2: تأكَّد من أنّ .env لا يمكن إيداعه أبدًا

أضِفه إلى .gitignore قبل أن تكتب سرًّا واحدًا:

.env
.env.local
*.env

بدلًا من ذلك، أودِع ملف .env.example بقيم نائبة فارغة، حتى يعرف المتعاونون أي المتغيّرات عليهم ضبطها:

ANTHROPIC_API_KEY=
DATABASE_URL=

إن كنت قد أودعت بالفعل ملف .env حقيقيًا، فإنّ إزالته في إيداع جديد ليست كافية — فهو يبقى في السجلّ. بدِّل المفتاح المكشوف فورًا وتعامَل معه على أنه مُخترَق.

الخطوة 3: فعِّل حماية الدفع في GitHub

تقوم حماية الدفع (push protection) في GitHub بفحص الإيداعات أثناء دفعها وتحظر الدفع إذا رصدت سرًّا، موقفةً التسريب قبل أن يصل إلى المستودع البعيد. وهي تتعرّف على أكثر من 200 نمط سرّي من مزوّدين مثل AWS وOpenAI وStripe وغيرهم الكثير، كما وسّعت تحديثات 2026 الأنماط المحظورة افتراضيًا. وهي مجانية للمستودعات العامة — فعِّلها من إعدادات مستودعك ضمن Settings ← Code security. اعتبِرها حزام أمان للحظة التي يَزِلّ فيها الوكيل (أو أنت).

الخطوة 4: لا تَدَع الوكلاء يجمعون إعدادات الصدفة لديك

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

الخطوة 5: حدِّد النطاق وبدِّل المفاتيح

عادتان تحدّان من الضرر إذا تسرّب شيء بالفعل، وهي نصيحة يردّدها أيضًا دليل OpenAI لأمان مفاتيح واجهة البرمجة:

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

قائمة تحقّق سريعة

قبل أن تُطلِق وكيلًا على مستودع:

1. الأسرار موجودة في .env، وتُقرأ عبر process.env — لا مُضمَّنة بشكل ثابت أبدًا.
2. .env مُدرَج في .gitignore؛ ولا يُودَع سوى .env.example.
3. حماية الدفع مُفعَّلة على المستودع البعيد.
4. لا مفاتيح بنصّ صريح في ملفات إعداد الصدفة.
5. المفاتيح محدودة النطاق ويتمّ تبديلها وفق جدول زمني.

لا شيء من هذا سيُبطئك بمجرّد إعداده — بل يتيح لك تسليم مزيد من العمل إلى وكيل الذكاء الاصطناعي لديك مع قلق أقل بكثير.