أمان وكلاء الذكاء الاصطناعي: مفاتيح API وSandbox وحدود الإنفاق

يتلخّص أمان وكلاء الذكاء الاصطناعي في ثلاثة أمور: أن يرى الوكيل ما يحتاج إليه فقط، وألا تكون مفاتيح API في مكان يستطيع الوكيل (أو المهاجم) قراءتها منه، وأن يكون لكل مفتاح حدّ للإنفاق. في ما يلي خمس خطوات يمكن إنجازها في فترة بعد الظهر: الأذونات، وSandbox، وترتيب المفاتيح، والحدود، وفحص المستودعات.

لماذا أصبح أمان وكلاء الذكاء الاصطناعي أمرًا ملحًّا؟

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

وفي 21 أكتوبر ظهرت قضية أخرى: بحسب SafeDep نُشر الإصدار 1.107.0 من مكتبة LiteLLM الشهيرة على PyPI ومعه برنامج لسرقة البيانات جمع، من بين أمور أخرى، مفاتيح SSH وبيانات الدخول إلى السحابة وأسرار CI/CD ومفاتيح مزوّدي نماذج LLM، إضافة إلى باب خلفي. وكانت لدى المهاجمين بيانات دخول GitHub CLI لثلاثة مطورين. أزالت PyPI هذا الإصدار في اليوم نفسه، والإصدار 1.106.2 من بين الإصدارات السليمة.

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

1. حقن الأوامر (Prompt injection). بحسب OWASP يتلقى النموذج في الصيغة غير المباشرة تعليمات «from external sources, such as websites or files». يكفي ملف README أو صفحة فيها تعليمة مخفية ليفعل الوكيل شيئًا لم نطلبه منه.
2. الصلاحية المفرطة («excessive agency»). تذكر OWASP ثلاثة أسباب: وظائف أكثر من اللازم، وأذونات أكثر من اللازم، واستقلالية أكثر من اللازم. وفي الإعلان المسبق عن قائمة 2026 صعد هذا الخطر إلى المركز الثالث.

وتدير OWASP أيضًا قائمة Top 10 منفصلة للتطبيقات الوكيلية، يحتل المركز الأول فيها «Agent Goal Hijack»، أي الاستيلاء على هدف الوكيل.

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

الخطوة 1: كيف تضبط الأذونات في Claude Code؟

سأشرح ذلك على Claude Code (شرحته من الصفر في شرح Claude Code)، لكن المنطق نفسه ينطبق على بيئات تشغيل الوكلاء الأخرى.

نضبط الأذونات في settings.json على شكل قواعد allow وask وdeny. وبحسب التوثيق فالترتيب ثابت: «deny, then ask, then allow»، أي أن الرفض يفوز دائمًا. لنبدأ بحظر الوصول إلى الأسرار. هذا المثال مأخوذ مباشرة من مرجع الإعدادات:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

والمهم أن لقواعد deny حدودًا، والتوثيق يذكرها صراحة:

1. لا تنطبق على الأوامر التي تقرأ الملفات دون ذكر أسمائها، مثل grep -r pattern .، ولا على العمليات الفرعية العشوائية.
2. تطابق Bash(curl *) الأمر حرفيًا، لذلك لن توقف /usr/bin/curl ولا sh -c 'curl …'.
3. ملف .claudeignore ليس له أي أثر، ويجب نقل مدخلاته إلى قواعد Read ضمن deny.

لهذا فالقواعد هي الطبقة الأولى وليست الحماية كلها. ونتحقق من الأذونات الحالية بالأمر /permissions.

الأمر الثاني هو وضع العمل. يوفّر Claude Code الأوضاع default وacceptEdits وplan وauto وdontAsk وbypassPermissions. وعن الأخير يقول التوثيق: «Only use this mode in isolated environments like containers or VMs». وعلى حاسوب مشترك يمكن تعطيله تمامًا بضبط permissions.disableBypassPermissionsMode على "disable".

الخطوة 2: كيف تفعّل Sandbox؟

الـ Sandbox حدٌّ يحرسه نظام التشغيل نفسه، لذلك يعمل حيث لا تصل قواعد deny. وبحسب توثيق Sandbox فهو معطّل افتراضيًا. نفعّله بأمر داخل الجلسة:

/sandbox

أو بضبط sandbox.enabled على true في ~/.claude/settings.json. على macOS يعمل مباشرة، أما على Linux وWSL2 فيحتاج إلى حزمتين:

sudo apt-get install bubblewrap socat

وعلى Windows بدون WSL2 لا يوجد Sandbox، وتعمل الأوامر بلا عزل.

ما الذي يقدّمه Sandbox بعد تفعيله:

1. الأوامر تكتب فقط في مجلد العمل والملفات المؤقتة.
2. تمر حركة الشبكة عبر وكيل (proxy) محلي، وقائمة النطاقات المسموح بها (network.allowedDomains) فارغة في البداية.
3. لكنها تستطيع قراءة معظم القرص، بما في ذلك ~/.ssh و~/.aws/credentials. يجب حظر هذه المسارات بأنفسنا عبر filesystem.denyRead أو قسم credentials، لأنه كما نقرأ: «There is no built-in credential deny list».

ملاحظتان من التوثيق. أولًا، يشمل Sandbox أوامر الطرفية فقط: أدوات Read وEdit وWrite وWebFetch والـ hooks وخوادم MCP المحلية تعمل خارجه. ثانيًا، النطاقات الواسعة مثل github.com في قائمة السماح قد تفتح طريقًا لتسريب البيانات. ومن يريد عزل كل شيء دفعة واحدة فعليه تشغيل الوكيل كله داخل حاوية أو آلة افتراضية.

وفي Codex من OpenAI المقابل هو الأوضاع read-only وworkspace-write وdanger-full-access، والشبكة معطّلة افتراضيًا. والخيار --yolo (اسم بديل لـ --dangerously-bypass-approvals-and-sandbox) يعطّل الموافقات وSandbox معًا، فلنتركه للحاويات.

الخطوة 3: أين تحفظ مفاتيح API؟

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

عمليًا:

1. مفاتيح منفصلة للتطوير والاختبار والإنتاج (وهذا أيضًا من توصيات Anthropic). وهكذا لا يُسقط تسريب واحد كل شيء.
2. مفتاح الوكيل مفتاح مستقل بحدٍّ خاص به، لا مفتاحنا الرئيسي.
3. بعد التسريب نلغي المفتاح فورًا، ثم نبحث عن السبب.

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

الخطوة 4: كيف تضبط حدود الإنفاق؟

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

1. Anthropic. في Claude Console ندخل صفحة Billing (platform.claude.com/settings/billing)، وفي قسم Spend limits ننقر Adjust limit أو Set limit. ويمكن ضبط الحدود أيضًا على مستوى الـ workspace، باستثناء الافتراضي.
2. OpenAI. في إعدادات المشروع ندخل Limits، ونضبط Monthly spend limit، ونفعّل Enforce a hard limit. انتبه: تنبيهات الإنفاق («Spend alerts do not enforce a cap») لا تحظر شيئًا، والحدّ نفسه يعمل بتأخير، فقد يتجاوزه الإنفاق قليلًا.

من العادات الجيدة مشروع (أو workspace) لكل وكيل، لكلٍّ منها مفتاحه وحدّه.

الخطوة 5: كيف تلتقط الأسرار قبل أن تتسرّب؟

يكتب الوكلاء الكثير من الكود وينشئون الـ commits بسهولة، لذلك من المفيد وجود آلية تلقائية توقف المفتاح قبل الـ push.

1. Push protection في GitHub. بحسب التوثيق تحظر عمليات الـ push التي تحوي أسرارًا قبل وصولها إلى المستودع. لحسابات المستخدمين تكون مفعّلة افتراضيًا للمستودعات العامة، أما على مستوى المستودع فهي معطّلة افتراضيًا وتتطلب GitHub Secret Protection.
2. Gitleaks محليًا. نثبّته عبر brew install gitleaks ونفحص مجلدًا أو سجل git (README):

gitleaks dir -v .
gitleaks git -v .

3. TruffleHog يتحقق أيضًا مما إذا كان السر المكتشف لا يزال يعمل (README). وبهذه الأداة تحققت NorForge من أن بعض الأسرار على لوحات Cairn كانت فعّالة:

trufflehog filesystem path/to/dir

ما الذي يجب الانتباه إليه في خوادم MCP؟

خادم MCP كود يعمل بأذوناتنا. يوصي توثيق Claude Code بكتابة خوادمك الخاصة أو استخدام خوادم المزوّدين الموثوقين فقط، وينبّه إلى أن Anthropic لا تدقّق خوادم MCP.

وتضيف توصيات أمان MCP (نسخة مسودة من المواصفة) بعض التفاصيل:

1. يجب أن يعرض العميل الأمر الكامل الذي يشغّل الخادم المحلي، دون اختصار. ومثال الهجوم في المواصفة أمر npx يبدو بريئًا يختبئ خلفه curl يرسل ~/.ssh/id_rsa إلى خادم غريب.
2. الأفضل تشغيل الخوادم المحلية داخل Sandbox بأدنى الأذونات وعبر نقل stdio.
3. لا يجوز للخادم قبول رموز (tokens) لم تُصدر له (ما يسمى «token passthrough» ممنوع).
4. تُمنح أذونات OAuth تدريجيًا، دون نطاقات واسعة مثل * أو all أو full-access.

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

هل تكفي قواعد deny في Claude Code لحماية ملف .env؟

ليس تمامًا. فهي تحظر الأدوات المدمجة والأوامر المعروفة مثل cat، لكنها لا تحظر grep -r ولا العمليات الفرعية العشوائية. الحماية الكاملة على مستوى النظام لا تتحقق إلا بـ Sandbox مع filesystem.denyRead.

ماذا أفعل إذا تسرّب مفتاح API؟

ألغِه فورًا من لوحة المزوّد، وأنشئ مفتاحًا جديدًا، واستبدله في جميع التطبيقات، وراجع الاستهلاك الأخير في الحساب. المزيد في مقال تسريب OpenCode.

ما هو حقن الأوامر في وكلاء الذكاء الاصطناعي؟

تعليمات مخفية في المحتوى الذي يقرؤه الوكيل (صفحات، ملفات، رسائل بريد). وقد ينفّذها الوكيل كأنها صادرة منا. لهذا ينبغي أن تتطلب الأفعال الخطرة موافقتنا، وألا يكون للوكيل وصول إلى الأسرار.

هل يعمل Sandbox على Windows؟

في Claude Code عبر WSL2 فقط. على Windows الأصلي تعمل الأوامر بدون Sandbox.