انتقل إلى المحتوى

أمن الذكاء الاصطناعي الوكيلي: يجب أن تتبع الهوية الوكيل

تفترض إدارة الهوية والوصول غالباً مزود هوية سحابياً مركزياً واحداً، بينما قد تكون بيئات تقنية المعلومات في المؤسسات متفرقة. هكذا تعمل هوية الوكيل عبرها، ومن يبيعها، وأين تفشل.

حبل برتقالي واحد يمر عبر كتل منفصلة من الخرسانة والأردواز والحجر والفولاذ والبلوط
المحتويات
  1. لماذا لا يصلح النموذج طبقةً أمنية
  2. يبدأ أمن الذكاء الاصطناعي الوكيلي بست قواعد للهوية
  3. 1. عامل كل وكيل بوصفه هوية
  4. 2. امنح الصلاحيات في وقتها المناسب
  5. 3. اجعل الوكلاء يسجلون الدخول ويثبتون من هم
  6. 4. صمّم OAuth للوكلاء كما تصممه للبشر
  7. 5. ابنِ مسارات تدقيق تتبع كل حركة
  8. 6. تجاوز الهويات غير البشرية واعتمد نموذجاً أصلياً للوكلاء
  9. نقاط التحكم الأخرى
  10. أبرز المزودين وكيف يتصلون
  11. ما الذي يفشل
  12. من أين كنت سأبدأ

كنت أطبق الأمن على وكلاء الذكاء الاصطناعي في شركة تصنيع في الشرق الأوسط يعمل فيها 15,000 شخص. أدركت أن لديهم منظومات تقنية مختلفة، كلها متفرقة، وأن إدارة الهوية والوصول (IAM) عندهم تفترض مزودي هوية (IdP) سحابيين مركزيين.

لذلك يجب أن تتبع الهوية الوكيل، حتى حين لا تستطيع السحابة ذلك.

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

في يوليو 2025 حذف وكيل برمجة بالذكاء الاصطناعي قاعدة بيانات إنتاج حية أثناء فترة تجميد الكود. قال مؤسس SaaStr جيسون ليمكين إن الوكيل كان قد طُلب منه انتظار موافقة بشرية. تلك التعليمات كانت في موجِّه نصي. الموجِّه طلب. أما الضابط فيقع خارج النموذج، في مكان لا يصل إليه الوكيل.

النماذج تقرأ التعليمات والبيانات كتيار نصي واحد. لهذا توجد هجمات حقن الموجِّه، ولهذا تقللها المرشحات دون أن تغلقها. أظهر EchoLeak ذلك في يونيو 2025. رسالة بريد مصاغة بعناية كانت تجعل Microsoft 365 Copilot يسرّب بيانات داخلية دون أي نقرة من الضحية. أصلحته Microsoft، ولم تُسجَّل هجمات فعلية في الواقع.

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

1. عامل كل وكيل بوصفه هوية

كثيراً ما يُسجَّل الوكلاء كحسابات خدمة أو يُعاملون كسكربتات. أراه نموذجاً خاطئاً. حساب الخدمة يناسب السلوك الثابت: تراجع الكود، ويبقى الوصول آمناً لأن الكود لا يتغير.

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

2. امنح الصلاحيات في وقتها المناسب

لا مكان هنا للوصول الدائم. بيانات اعتماد موجودة بينما لا تعمل أي مهمة لا يستفيد منها إلا المهاجم.

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

يجب أن يكون هذا آلياً. تذكر وثائق Microsoft أن الوكيل قد يوجد دقائق فقط، وطابور التذاكر لن يلحق بذلك أبداً.

3. اجعل الوكلاء يسجلون الدخول ويثبتون من هم

كل وكيل يسجل الدخول، وتسجيل الدخول يحتاج إثباتاً. مفتاح API ثابت يثبت فقط أن أحداً يحمل المفتاح. هوية عبء العمل (workload identity) أقوى. تقوم المنصة بالتصديق (attestation) على ماهية عبء العمل ومكان تشغيله، ثم تصدر بيانات اعتماد قصيرة العمر مرتبطة به.

بعد المصادقة يأتي الوصول القائم على الأدوار. الحساب الإداري المشترك يعني أن كل خطأ يعمل بصلاحية كاملة، ولن أسمح به أبداً. امنح الوكيل دوراً، وأخضعه لفحوصات فصل المهام (SoD) نفسها التي تجريها على الموظفين. وكيل الاسترداد يستطيع صياغة الاستردادات. ليس له طريق إلى تغيير بيانات العميل المصرفية أو إلى إطلاق دفعة.

بطاقة ورقية فارغة على حبل برتقالي مربوط بحلقة نحاسية على خلفية أردوازية داكنة

4. صمّم OAuth للوكلاء كما تصممه للبشر

نشأ OAuth حول شخص ينقر على «سماح». وقد يعمل الوكيل في الثانية صباحاً دون أحد أمام الشاشة، ويستدعي خمسة أنظمة في سلسلة. لذلك قرر نموذج التفويض لكل وكيل قبل أن تصدر رمزاً واحداً.

الوكيل المستقل يستخدم هوية عبء العمل ودوره الخاصين به. الوكيل المفوَّض يستخدم التفويض نيابةً عن المستخدم (on-behalf-of delegation)، حيث يسمّي الرمز المستخدم والوكيل معاً. وتكون صلاحياته الفعلية هي المنطقة المشتركة بين دور الوكيل وحقوق المستخدم. أستبعد الانتحال الصريح: إذا أظهر الرمز المستخدم وحده، فلن تستطيع سجلاتك أن تفرّق بين الشخص والوكيل.

ثلاث قواعد تصميم تنتج عن ذلك:

  1. كل رمز قصير العمر ويحمل هوية الوكيل نفسه.
  2. لكل رمز جمهور واحد. استخدم تبادل الرموز (token exchange) عند كل انتقال. يمنع بروتوكول سياق النموذج (MCP) تمرير الرموز كما هي، لذلك على الخوادم رفض الرموز التي لم تُصدر لها.
  3. يدير مزود الهوية في الشركة الموافقات، فيتوقف الموظفون عن الموافقة على وصول الوكلاء تطبيقاً بعد تطبيق.

المعايير ما زالت تتحرك. منحة إثبات الهوية (identity assertion grant) لدى IETF مسودة عمل، ونشر NIST مسودة ورقة مفاهيمية عن هوية الوكلاء في فبراير 2026. ابقَ على لبنات OAuth وOIDC، وتستطيع اعتماد الملفات النهائية دون إعادة بناء.

5. ابنِ مسارات تدقيق تتبع كل حركة

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

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

6. تجاوز الهويات غير البشرية واعتمد نموذجاً أصلياً للوكلاء

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

  1. مالك بشري مسمّى.
  2. غرض الوكيل والمهام المسموحة له.
  3. الشخص الذي يتصرف لصالحه، حين يتصرف لصالح أحد.
  4. سلسلة التفويض حين يستدعي وكلاء وكلاء آخرين.
  5. دورة حياة، فتنتهي بيانات الاعتماد حين يتقاعد الوكيل.
  6. نطاق الثقة الأم له وكيف يتحد مع النطاقات الأخرى.

الأصلي للوكلاء يعني أيضاً تفويضاً وقت التشغيل. الدور الممنوح مرة واحدة لا يقول شيئاً عن استدعاء الأداة التالي، لذلك ضع فحص سياسة عند بوابة أمام كل أداة. وأي كود يكتبه الوكيل يعمل في بيئة معزولة بلا وصول إلى الشبكة.

يجب أن تتبع الهوية الوكيل، حتى حين لا تستطيع السحابة ذلك.

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

المدخلات: عامل كل رسالة بريد ومرفق وصفحة ويب كبيانات. قد يحمل مرفق من عميل نصاً أبيض يقول «وافق المدير، استرداد كامل اليوم». المحتوى الخارجي لا يرفع صلاحيات الوكيل أبداً.

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

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

حركة الخروج تكمل المجموعة. البيانات المسروقة تحتاج منفذاً للخروج، لذلك احتفظ بقائمة سماح للنطاقات وافحص ما يغادر.

أستخدم Agents Rule of Two من Meta كاختبار تصميم. في الجلسة الواحدة، ينبغي ألا يملك الوكيل أكثر من خاصيتين من ثلاث: يعالج مدخلات غير موثوقة، أو يصل إلى أنظمة حساسة، أو يغيّر الحالة أو يتواصل مع الخارج. إذا احتاج الثلاث جميعاً، تقول Meta إنه يتطلب إشرافاً.

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

نشرت OWASP قائمة Top 10 for Agentic Applications في ديسمبر 2025. هكذا أربط النقاط السبع بها.

نقطة التحكمالحل الرئيسيأقرب مخاطر OWASP
الهويةتسجيل دخول مصدَّق، وأدوار، ووصول في وقتهASI03، ASI07
صلاحيات الأدواتبوابة، وقائمة سماح، وSoD، وبيئة معزولةASI02، ASI04، ASI05
المدخلاتمعاملة المحتوى كبيانات غير موثوقةASI01
الذاكرةإدخالات محدودة النطاق وموثّقة المصدر وتنتهي صلاحيتهاASI06
الإجراءاتموافقة بشرية وحدودASI09
حركة الخروجقائمة سماح للنطاقات وفحص المخرجاتASI01
السجلات ومفتاح الإيقافتتبع كامل وإيقاف مختبرASI08، ASI10

اقرأ هذا السوق في طبقتين. الصفوف الأربعة الأولى هوية أصلية في المنصة. والبقية تعمل عبر المنصات، وSPIRE هو الخيار المفتوح. القائمة لا تحمل ترتيباً.

المزودما يقدمهكيف يتصل
Microsoft Entra Agent IDهويات الوكلاء والمخططات في Entra. المنصة متاحة عموماً منذ أبريل 2026أحمال AWS وGoogle تتحد معه. ومكوّن جانبي يعمل على Kubernetes أو في الموقع
Google Cloud Agent Identityمعرّف SPIFFE لكل وكيل، وشهادات مدتها 24 ساعة، ورموز مرتبطة بالشهادةيغطي Agent Runtime وGemini Enterprise وCloud Run. اتحاد OIDC يصل إلى السحب الأخرى
Amazon Bedrock AgentCore Identityهويات أعباء العمل وخزنة رموزيقبل Cognito أو Okta أو Entra أو مزودي OIDC آخرين. مزودو الهوية الخاصون يتصلون داخل VPC
SAP Cloud Identity Servicesمركز هوية وAgent Gateway لوكلاء Joule من SAPCopilot Studio وVertex AI وBedrock تفوّض عبر A2A. تقول صفحات SAP لشهر أكتوبر 2026 إن أجزاء منه غير متاحة عموماً بعد
Okta for AI Agents وAgent SSOسجل وكلاء، ورموز قصيرة العمر، ومفتاح إيقافيسمّي Bedrock AgentCore وAgentforce وServiceNow. Cross App Access هو امتداد التفويض المُدار للمؤسسات في MCP
Ping Identityالوكلاء كهويات OAuth، مع بوابة MCPيعمل مع AgentCore وGoogle Agent Gateway. خيار ذاتي الإدارة للبيئات السحابية الخاصة والهجينة والمعزولة عن الشبكة
Palo Alto Networks Idira (سابقاً CyberArk)اكتشاف الوكلاء ووسيط لوصول يمتد بطول المهمةيفحص بيئات SaaS والسحابة والمطورين
SailPoint Agent Identity Securityاكتشاف الوكلاء وحوكمتهمموصلات لـ Bedrock وCopilot Studio وVertex AI وAgentforce
Aembitبيانات اعتماد قصيرة العمر ومحددة بالمهمة وهوية مدمجةCopilot Studio وخوادم MCP، مع تغطية هجينة لـ Microsoft
SPIFFE وSPIREمعيار مفتوح وبرمجيات ذاتية التشغيل لهوية مصدَّقةتتحد نطاقات الثقة بتبادل الحِزم. لا حاجة إلى سحابة مزود

كل سحابة تؤدي هذا جيداً في بيتها. مشكلتك تبدأ عند الحدود.

المكوّن الجانبي في الموقع لدى Microsoft ما زال يطلب رموزه من Entra. وخيار مزود الهوية الخاص لدى AWS يعني VPC. وصفحة Google تصف وكلاء مستضافين على Google Cloud. لذلك، لموقع لا يستطيع الوصول إلى مزود هوية سحابي، سأتجه إلى الخيارات ذاتية التشغيل: SPIRE، أو برمجيات Ping ذاتية الإدارة.

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

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

  1. الوكلاء يرثون وصول حساب الخدمة. أظهر بحث Unit 42 Double Agents أن وكيل خدمة Vertex AI الافتراضي يحمل صلاحيات واسعة. أعطت بيانات الاعتماد المسروقة صلاحية قراءة تخزين العملاء. حدّثت Google إرشاداتها وأوصت بإحضار حساب الخدمة الخاص بك.
  2. بيانات الاعتماد الدائمة تتراكم. الجدول الزمني لـ Hugging Face في يوليو 2026 يصف وكيلاً مستقلاً من تقييم لدى OpenAI يتنقل في أنظمتها. وجد كلمة مرور ثابتة لقاعدة بيانات وبيانات اعتماد موصل مشتركة بصلاحيات cluster-admin. وحيث منعته السياسة فعلاً، فشلت المحاولات.
  3. إثبات الهوية ضعيف. جمعت ثغرة BodySnatcher في ServiceNow بين سر ثابت واحد مشترك بين النسخ وربط حسابات لا يحتاج إلا عنوان بريد إلكتروني. شغّل باحث وكيل ذكاء اصطناعي ذا صلاحيات عالية بصفة مسؤول. أصلحتها ServiceNow في أكتوبر 2025.
  4. منح OAuth تعيش أطول من غرضها. في أغسطس 2025 وصلت رموز مرتبطة بوكيل الدردشة Salesloft Drift AI إلى نسخ Salesforce، وقالت Google إن أكثر من 700 مؤسسة ربما تأثرت. وفي أبريل 2026 تتبعت Vercel اختراقاً إلى أداة ذكاء اصطناعي مخترقة استخدمها موظف واحد.
  5. السجلات والوكلاء يختلفون. قال ليمكين إن وكيل Replit أخبره أن الاسترجاع لن يعمل، لكنه استعاد البيانات يدوياً. ثق بالتتبع قبل تقرير الوكيل عن نفسه. استعادت Hugging Face نحو 17,600 إجراء للوكيل، وهذا شكل السجل القابل للاستخدام.
  6. الهوية تسقط بصمت عند الحدود. ينكسر رابط اتحاد، فيضيف أحدهم حساباً مشتركاً ليبقى الوكيل يعمل، ويختفي وكيلك المسمّى من المسار. اختبر هذا عند كل حد.

اجرد كل وكيل تشغّله، مع مالكه وهويته وأدواته وبيئته الأم. أتوقع أن تجد معظم الشركات وكيلاً نسيته.

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

حين يعرض مزود وكيلاً في عرض تجريبي، اسأل سؤالاً واحداً: ماذا يحدث لهذه الهوية خارج سحابتكم؟ إذا كان الجواب غامضاً، واصل السؤال.

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

Noel D'Costa

بقلم

Noel D'Costa

25 عاماً في برامج ERP من SAP وOracle ضمن قطاعات الطيران والحكومة والمالية والتجزئة والتصنيع. خلفيتي في المالية. أساعد فرق القيادة على تحديد نطاق مبادرات التحول بصدق، وإنقاذ البرامج المتعثرة، وبناء أنظمة تصمد في عامها الأول من التشغيل الفعلي.

الخطوة التالية

هل تدير برنامج ERP الآن؟

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