مع التوسع الهائل في عام 2026 في اعتماد وكلاء الذكاء الاصطناعي المستقلين (Autonomous AI Agents) وأدوات البرمجة الوكيلة مثل Claude Code و Cursor و OpenHands و LangGraph، أصبح الوكيل يتفاعل مباشرة مع بيئات الإنتاج — ينفذ استعلامات SQL، ويطلق عمليات النشر السحابي، ويعدّل مستودعات GitHub ذاتياً.
لكن تمكين النماذج غير القطعية (Non-Deterministic LLMs) من استدعاء الأدوات كشف عن ثغرة أمنية حرجة: الافتقار شبه التام لإدارة الهوية والوصول (IAM) المخصصة للوكلاء.
فالغالبية العظمى من المشاريع اليوم لا تزال تحقن مفاتيح API ثابتة ذات صلاحيات كاملة (God-Mode Keys) في متغيرات بيئة الحاويات. وفي حال تعرض الوكيل لهجوم حقن غير مباشر (Indirect Prompt Injection) عبر تذكرة دعم أو صفحة ويب خبيثة، يمكن خداع النموذج لطباعة تلك المفاتيح وتسريب قواعد البيانات!
1. المتجهات الثلاثة الأخطر للهجوم على وكلاء الـ AI
- هجوم المفوّض المضلل (Confused Deputy Vulnerability): استغلال صلاحيات الوكيل الواسعة لتنفيذ أوامر عدائية مخفية في بيانات خارجية دون علم المطور.
- تسريب بيانات الاعتماد من السياق (Context Exfiltration): عند تمرير الرموز السرية داخل نافذة البرومبت، يمكن للمهاجم استدراج النموذج لطباعتها في الرد أو إرسالها لروابط خارجية.
- الحركة الجانبية عبر تسلسل الأدوات (Lateral Movement): التدرج من قراءة ملف محلي إلى تسريب محتواه عبر أداة مراسلة (مثل Slack / Webhook).
2. المعمارية الموصى بها: تبادل الرموز عبر OAuth 2.0 (RFC 8693)
لإلغاء المفاتيح الثابتة الخطيرة، تنتقل الفرق الهندسية المتقدمة إلى OAuth 2.0 Token Exchange (RFC 8693):
- تبادل الرمز الأساسي برمز مؤقت: يتم استبدال رمز المستخدم برمز تفويض خاضع لتقليص النطاق (Downscoped Token) لفترة قصيرة جداً (TTL < 15 دقيقة).
- صلاحية بالحد الأدنى: لا يمتلك الوكيل صلاحية كاملة على المنظومة، بل يُمنح حق قراءة جدول محدد أو مشروع بعينه فقط.
3. تأمين بروتوكول MCP عبر وسيط أدوات معزول (Tool Broker Gateway)
عند استخدام بروتوكول سياق النموذج (Model Context Protocol - MCP)، يجب عزل بيانات الاعتماد تماماً عن الـ LLM:
- حجب الرموز الحقيقية: يتعامل النموذج مع معرّفات وهمية (Opaque Handle IDs).
- الحقن خارج نافذة السياق (Out-of-Band Injection): تقوم بوابة الوسيط (Broker Gateway) بحقن الرمز الحقيقي في ترويسة الطلب أثناء مروره دون إدخاله في الـ Context Window.
4. السياسة ككود برمجي (Policy-as-Code) مع AWS Cedar أو OPA
الاعتماد على التعليمات النصية للبرومبت (مثل: “لا تقم بحذف الجداول”) أثبت فشله الأمني المتكرر. المعمارية الآمنة تفرض تمرير كل استدعاء أداة عبر محرك سياسة قطعي (AWS Cedar أو Open Policy Agent) خارج النموذج للتحقق من أذونات الاستدعاء قبل التنفيذ.
5. خلاصة ومصادر للمطورين
المعادلة واضحة لعام 2026: لا مفاتيح API ثابتة في الحاويات، ولا رموز سرية داخل نافذة البرومبت، وتطبيق مبدأ الصلاحيات الدنيا الصارم (Zero-Trust Least Privilege).
للاطلاع على الشرح المعماري التفصيلي، والرسوم البيانية الهندسية، ونموذج البوابة البرمجية بلغة بايثون، يمكنكم مراجعة الدليل التخصصي الكامل عبر منصة AgDex.ai (دليل تأمين وإدارة صلاحيات AI Agents).
سؤال للنقاش مع الزملاء مهندسي الأنظمة والأمن:
كيف تديرون صلاحيات ومفاتيح الـ API لوكلاء الذكاء الاصطناعي في بيئاتكم الحالية؟ هل تطبقون مبدأ الرموز المؤقتة أم ما زلتم تعتمدون على مفاتيح ثابتة في .env؟ شاركونا آراءكم وتجاربكم!