الوكلاء ليسوا مستخدمين: أزمة الهوية خلف 88٪ من حوادث الذكاء الاصطناعي في المؤسسات

في فبراير 2026، نشرت Gravitee بيانات استطلاع لأكثر من 900 من المديرين التنفيذيين تُظهر أن 88٪ من المؤسسات شهدت حادثًا أمنيًا مؤكدًا أو مشتبهًا به يتعلق بوكلاء الذكاء الاصطناعي خلال العام الماضي (opens in new tab)، في حين أن 21.9٪ فقط من الفرق تعامل وكلاء الذكاء الاصطناعي ككيانات تحمل هويات مستقلة وتمتلك مبادئ أمنية مميزة. و45.6٪ ما زالوا يعتمدون على مفاتيح API مشتركة للمصادقة بين الوكلاء. أكثر من نصف الوكلاء يعملون دون أي إشراف أمني أو تسجيل أحداث على الإطلاق.

القصة ليست أن حقن الأوامر يفوز. القصة هي أن معظمنا ربط الوكلاء بأنظمة الإنتاج باستخدام نمطين لم يكن لهما أن يصمدا: إما بيانات اعتماد مستخدم بشري ("شغّل كأنك Jane") أو حساب خدمة صُمم نطاقه لمهمة دفعية من عام 2018. حين يسوء شيء ما، ينتهي تقرير الحادث دائمًا بالطريقة نفسها — كان للوكيل صلاحية فعل ما فعله، لم يستطع أحد أن يفسر السبب، ولم يستطع أحد إيقافه بشكل نظيف.

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

الحادث نادرًا ما يكون ما يُعلن عنه

اقرأ ما يكفي من تقارير ما بعد الحوادث، وسيظهر لك النمط. البيان الصحفي يقول "أدى حقن الأوامر إلى تسريب البيانات". تقرير الحادث الفعلي يقول: أُعطي الوكيل رمز وصول شخصي يخص مهندسًا أول، وورث الرمز صلاحية org-admin على عشرات المستودعات، وتسربت البيانات عبر مسار لم يفكر فيه أحد من خلال استدعاء أداة، وأن تدوير الرمز المشترك أوقف الإنتاج ست ساعات.

OWASP Top 10 for Agentic Applications 2026 (opens in new tab) تسمي هذا مباشرة: البند ASI03 هو "إساءة استخدام الهوية والصلاحيات" — استغلال الثقة المفوّضة، وبيانات الاعتماد الموروثة، وسلاسل الأدوار. مقال Microsoft عن معالجة هذه المخاطر (opens in new tab) يؤكد على النمط نفسه. حقن الأوامر قد يكون المحفّز أحيانًا. لكن نصف قطر الانفجار دائمًا ما يكون نموذج الهوية.

"شغّل كأنك Jane" التزام قانوني لا تصميم

إعطاء الوكيل بيانات اعتماد إنسان هو أسرع طريق لتجاوز جدار SSO المؤسسي. وهو أيضًا الخيار الذي يتقادم بأسوأ شكل، لثلاثة أسباب مُسقِطة.

الإبطال قرار يهدّد الوظائف. حين يسيء "وكيل Jane" التصرف الساعة الثانية صباحًا، الرافعة الوحيدة المتاحة لك هي حساب Jane. تعطيل جلستها يُسكت الوكيل — لكنه يوقف أيضًا VPN الخاص بها، ومزامنة حاسوبها، وتقويمها، وأي أتمتة أخرى تعمل تحت هويتها. مهندسو الاستجابة يرفضون سحب الرافعة حتى يعتمدها مسؤول كبير، وهذا التأخير هو بالضبط النافذة التي يستمر فيها الوكيل في استهلاك استدعاءات API.

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

تضخم النطاق حتمي. Jane تمتلك النطاقات التي تحتاجها لعملها، والتي لأي مشغّل أول تكون معظمها. يرث وكيلها كل ذلك — سطح هجوم كامن ينمو بهدوء كلما تولّت Jane مسؤوليات جديدة.

"شغّل كأنك Jane" مقبول لنموذج أولي مدته خمس دقائق. إنه اختصار يبقى في قاعدة شيفرتك ثمانية عشر شهرًا حتى يُجبرك خرق أمني على اقتلاعه.

حسابات الخدمة العامة تفشل بالاتجاه الآخر

النمط الأكثر شيوعًا بعده هو حساب خدمة مشترك — ai-agent@company.com أو ml-bot-prod — برمز واسع الصلاحيات يستخدمه كل وكيل. هذا ما يفعله 45.6٪ من المستجيبين في استطلاع Gravitee الآن. يحل مشكلة "طُرِدت Jane" ويصنع أربع مشاكل أسوأ.

الإسناد لكل وكيل يتلاشى بنيويًا. كل سطر سجل يقول ml-bot-prod. حين يسيء أحد الوكلاء الخمسة التصرف، تُدوِّر بيانات الاعتماد المشتركة فتكسر الأربعة الآخرين.

بيانات الاعتماد طويلة العمر وموزعة على نطاق واسع. المفاتيح المشتركة تنتهي في أسرار CI، وفي ملفات .env، وفي رسائل Slack الخاصة، وفي صفحات Notion قديمة. الكشف في يونيو 2026 عن 16 مليار بيان اعتماد استخدمها المهاجمون للوصول إلى بحيرات بيانات الشركات وأنظمة وكلاء الذكاء الاصطناعي (opens in new tab) وقع على منظومات كان هذا النمط فيها قياسيًا.

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

لا أحد يملكه. الحسابات البشرية تُجدَّد كل ربع سنة. أما ml-bot-prod فليس له أحد. الهويات غير البشرية باتت تفوق الهويات البشرية بنسبة 50 إلى 1 تقريبًا على شبكات المؤسسات (opens in new tab)، ومعظمها يعمل برموز طويلة العمر لم ترسمها الأدوات التقليدية.

ما تحتاجه هوية الوكيل فعلاً

انزع عروض الباعة، تجد المتطلبات ضيقة. معظم الفرق التي نعمل معها تفتقد ثلاثًا أو أربعًا من هذه الست.

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

2. بيانات اعتماد قصيرة العمر. دقائق إلى ساعة، لا شهور. SVIDs من SPIFFE تستخدم افتراضيًا عمرًا لمدة ساعة مع تجديد تلقائي عند 50٪ من الصلاحية (opens in new tab). بيانات اعتماد مخترقة صالحة لساعة واحدة تمنح نافذة انفجار مدتها 60 دقيقة؛ أما الصالحة لسنة فتمنح 8,760 ساعة.

3. نطاق ضيق وصريح. ليس "قراءة وكتابة على CRM" — بل "قراءة جهات الاتصال حيث owner_id = <initiating user>، وكتابة ملاحظات على جهات الاتصال التي قرأها، لا فرص ولا فوترة". إذا بدا هذا مُرهِقًا، فجيد. هو مرهق بقصد.

4. إسناد يعود إلى الإنسان المُبادر. الوكلاء المستقلون ما زالوا يتصرفون استجابةً لمحفّز بشري. الرمز يحتاج أن يحمل هذا النسب. ادّعاء act في RFC 8693 هو البنية القياسية: الرمز للمستخدم، و_الفاعل_ هو الوكيل، وتتداخل الادعاءات للتعبير عن سلاسل. شرح Christian Posta لـ on-behalf-of بالنسبة لوكلاء الذكاء الاصطناعي (opens in new tab) هو أوضح تفسير وجدناه.

5. سجل تدقيق يُضاف إليه فقط. كل استدعاء أداة، وكل ادعاء نطاق، مع معرّف الوكيل والإنسان المُبادر والطابع الزمني والنتيجة — على بنية تحتية لا يستطيع الوكلاء حذف سجلاتهم منها. تشير Kiteworks إلى أن 33٪ من المؤسسات تفتقر تمامًا إلى مسارات تدقيق الذكاء الاصطناعي و61٪ تعمل ببنية تحتية مجزّأة لا تستطيع إنتاج أدلة عملية (opens in new tab). فجوة سجل التدقيق هي أقوى مؤشر على فشل الحوكمة.

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

نمط ملموس يعمل

النموذج الذي نعتمده افتراضيًا يحتوي على ثلاثة مكونات متحركة وناقل أحداث واحد، بافتراض أن لديك بالفعل موفّر هوية OIDC (Keycloak أو Auth0 أو Entra ID أو Ory) ومحرك سياسات (OPA أو Cedar أو المكافئ الأصلي لمنصتك).

هوية أحمال عمل مُصدَرة عبر OIDC لكل نسخة وكيل. حين تبدأ عملية الوكيل، تقدّم شيئًا تستطيع بنيتك التحتية المصادقة عليه — JWT حساب خدمة Kubernetes، أو بيانات تعريف نسخة السحابة، أو SVID من SPIFFE — وتستبدله برمز OIDC قصير العمر مرتبط بمعرّف وكيل محدد مثل agent:summarizer:prod:7a2c91. يرفض موفّر الهوية إصدار رموز لأي معرّف غير مسجّل في قائمة السماح.

JWTs قصيرة العمر مخصّصة لكل تفاعل. حين يتصرف الوكيل بالنيابة عن مستخدم، يقوم بتبادل الرموز وفق RFC 8693 (opens in new tab)، مقدمًا رمزه ورمز المستخدم معًا. رمز الوصول الناتج يحمل ادعاء act يسمي الوكيل، وsub يسمي المستخدم، وaud مقيّد بـ API واحد، ونطاقات مُضيَّقة إلى تقاطع صلاحيات المستخدم والوكيل. TTL: من خمس إلى خمس عشرة دقيقة.

سياسات لكل وكيل مفروضة عند المورد. يحمل محرك السياسات قواعد مثل "الوكيل agent:summarizer:* يمكنه قراءة الرسائل حيث يطابق act.sub مالك صندوق البريد؛ لا يمكنه الإرسال؛ لا يمكنه الحذف". تصريحية، مُتحكَّم بها عبر الإصدارات، ومُراجَعة في طلبات السحب. تغيير سياسة لا يتطلب نشرًا.

ناقل أحداث يسجل كل قرار. كل تبادل رموز، وكل تقييم سياسة، وكل استدعاء أداة يُضاف إلى دفق غير قابل للتغيير يغذّي SIEM الخاص بك، وتحليلاتك، وخدمة "زر إيقاف". يمكنك الإجابة عن "ماذا فعل الوكيل X اليوم" باستعلام واحد.

هذا ليس ثوريًا. SPIFFE/SPIRE يمنحك هوية أحمال العمل. OAuth 2.1 مع RFC 8693 يمنحك التفويض. OPA أو Cedar يمنحك السياسات. ما يغيب في معظم التنفيذات هو الانضباط لربطها معًا للوكلاء خصيصًا.

تمرين الإبطال الميداني

كل فريق نعمل معه يحصل على التمرين نفسه في اليوم الأول: سمِّ وكيلًا واحدًا، أوقفه، تحقق من موته. ساعة التوقيت تعمل. الهدف: أقل من 60 ثانية. معظم الفرق في المحاولة الأولى تستغرق بين ست دقائق وأربع ساعات — التباين يرجع بالكامل تقريبًا إلى بنية بيانات الاعتماد.

تمرين يعمل: يفتح المشغّل لوحة الإدارة، يبحث عن معرّف الوكيل، ينقر إبطال. يَسِم موفّر الهوية المعرّف بوصفه معطَّلًا، فيرفض أي تبادل لاحق، وينشر حدث الإبطال. الـ APIs المستهدفة المشتركة في الدفق ترفض الرموز الحية. خلال 15 دقيقة كحدٍّ أقصى، لا يمتلك الوكيل أي بيانات اعتماد تعمل في أي مكان؛ قاعدة رفض في محرك السياسات تختصر ذلك إلى ثوانٍ.

نسخة حساب الخدمة المشترك: تدوير المفتاح المشترك، انتشاره إلى مدير الأسرار، إعادة نشر أربعة وكلاء ومهمة cron ونظام CI. الأنظمة الشرعية تتعطّل. الوكيل المارق، إن كان قد خزّن بيانات الاعتماد القديمة، يواصل العمل حتى جلبه التالي.

تقارير عن حوكمة الوكلاء (opens in new tab) تلاحظ أن معظم المؤسسات تستطيع مراقبة وكلائها لكنها لا تستطيع إيقافهم. الاحتواء، لا الاكتشاف، هو الفجوة.

تضخم النطاق هو القاتل الصامت الثاني

الإبطال يجيب عن "هل يمكننا إيقاف وكيل يسيء التصرف اليوم". لا يجيب عن الفشل الأبطأ: وكيل نما نطاقه على مدى سنتين دون أن ينظر إليه أحد. مساعد بدأ بـ"اقرأ التقويم، اقترح أوقاتًا" ينتهي بـ"اقرأ البريد، اقرأ CRM، اكتب في CRM، شغّل webhooks، اعمل بالنيابة عن أي مستخدم". كل خطوة كانت مبرَّرة. لم يراجع أحد الصورة الكلية.

الإجراءات المضادة مملة وفعّالة.

راجع النطاقات بجدول منتظم. ربعيًا. قارن ما تمنحه السياسة بما استخدمه الوكيل فعلاً في آخر 90 يومًا. النطاقات غير المستخدمة تُحذف؛ إذا كسر الحذف شيئًا، تعلم أي مسار شيفرة كان يعتمد على نطاق لم يستطع أحد تبريره.

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

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

عامل "يستطيع إنشاء وكلاء" كنطاق ذي امتيازات. يلاحظ Gravitee أن 25.5٪ من الوكلاء المنشورين يستطيعون إنشاء وكلاء إضافيين وإسناد مهام لهم (opens in new tab). هذه القدرة تضاعف زحف النطاق أسيًا ويجب أن تكون خلف موافقة صريحة.

إلى أين تتجه المعايير

في يناير 2026، نشر NIST CAISI الأمريكي طلبًا للمعلومات في السجل الفيدرالي حول اعتبارات أمن وكلاء الذكاء الاصطناعي (opens in new tab)، مع استحقاق التعليقات في 9 مارس 2026. طلبت الردود من NIST توسيع SP 800-218 (SSDF) (opens in new tab) وSP 800-160 لتغطية الذكاء الاصطناعي الوكيلي عبر دورة الحياة كاملة. توقّع إرشادات رسمية خلال 2026 وبداية 2027.

للفرق في منطقة DACH، تميل إرشادات BaFin وBSI إلى التوافق مع أنماط NIST بعد ستة إلى اثني عشر شهرًا. ابنِ نموذج الهوية أعلاه الآن، وستكون متقدمًا على حيث سيحط الامتثال. ابقَ على "شغّل كأنك Jane"، وستكون في حالة ارتباك.

النسخة المختصرة

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

الأنماط — هوية أحمال عمل SPIFFE، وتبادل رموز OAuth 2.1 مع RFC 8693، ومحركات السياسات، والتدقيق القائم على مصادر الأحداث — صارت في درجة الإنتاج منذ سنوات. الجديد هو تطبيقها بشكل متعمّد على الوكلاء، بدلاً من وراثة أي هوية ملقاة في الجوار. معدل الحوادث 88٪ هو عرَض لتجاوز هذه الخطوة.

قراءات إضافية

• Gravitee — State of AI Agent Security 2026 Report (opens in new tab)
• OWASP Top 10 for Agentic Applications 2026 (opens in new tab)
• Microsoft — Addressing OWASP Top 10 Risks in Agentic AI with Copilot Studio (opens in new tab)
• NIST CAISI — RFI on Security Considerations for AI Agents (Federal Register, January 2026) (opens in new tab)
• RFC 8693 — OAuth 2.0 Token Exchange (opens in new tab)
• SPIFFE Concepts — Workload Identity and SVIDs (opens in new tab)
• Christian Posta — Explaining OAuth Delegation, On Behalf Of, and Agent Identity for AI Agents (opens in new tab)