وكيلك الذكي لديه حساب دخول. هل تستطيع إثبات ما لمسه؟
اسأل فريق الأمن لديك سؤالًا بسيطًا هذا الصباح: أي وكلاء ذكاء اصطناعي يستطيعون الوصول إلى نظامك المالي؟ سيجيب معظمهم في ثوانٍ. ثم اطلب منهم إثبات ما لمسه هؤلاء الوكلاء يوم الثلاثاء الماضي في الساعة 14:07 تحديدًا. ذلك الصمت هو القصة.
تقرير JumpCloud الفصلي Q4 2026، المبني على استبيان شمل 250 مسؤول تقنية معلومات في الولايات المتحدة وبريطانيا، يضع رقمًا لذلك الصمت: 72% يرون فجوة متوسطة إلى كبيرة بين ما يستطيع الذكاء الاصطناعي الوصول إليه وما يستطيعون إثبات أنه وصل إليه. و4% فقط يقولون إنه لا توجد فجوة ذات معنى. و99% من القادة المستطلعين أكدوا ثقتهم بقدرتهم على تدقيق نشاط الذكاء الاصطناعي، في حين أن 37% فقط كانوا مستعدين فعلًا لذلك.
الثقة ليست دليلًا. نرى ذلك كل يوم في عملنا مع العملاء.
الفجوات الثلاث التي لا تضع لها ميزانية
يؤطر التقرير المشكلة كثلاث ثغرات متداخلة، وهذا التأطير يستحق مكانًا في عرضك القادم أمام الإدارة.
فجوة الهوية. 55% من المؤسسات تستخدم أو تختبر وكلاء قادرين على تغيير الأنظمة والصلاحيات والسجلات وسياقات العمل. ومن بينها، 41% فقط أدمجت وكلاءها بالكامل في سياسات إدارة الهوية والوصول نفسها التي تحكم الموظفين. أما الـ59% الأخرى فتدير وكلاءها جزئيًا أو عبر سياسات وأدوات منفصلة. و63% من بيئات الوكلاء ما زالت تخلط بين حسابات خدمة مشتركة ومفاتيح API طويلة الأمد، وهذا بالضبط ما يجعل تتبع أي إجراء مستحيلًا بعد ستة أسابيع.
فجوة الإثبات. 72% لا يستطيعون إعادة بناء ما لمسه الذكاء الاصطناعي بشكل كامل. و34% فقط يستطيعون إثبات كيفية تعامل الذكاء الاصطناعي مع البيانات الحساسة. وخلال الأشهر الاثني عشر الماضية، سجلت 92% حادثة أو تعرضًا واحدًا على الأقل مرتبطًا بالذكاء الاصطناعي، و36% حققوا في شأن ما دون أن يعرفوا أبدًا ما الذي وصل إليه الذكاء الاصطناعي.
فجوة الجهوزية. 20% فقط من المؤسسات في أعلى مستوى من نضج قابلية التدقيق. و64% في المستوى المتوسط: الضوابط موجودة، لكن التغطية متفاوتة والثقوب لا تظهر إلا في تدقيق أو بعد حادثة. و30% يذكرون ذكاءً اصطناعيًا خفيًا لا يستطيعون مراقبته كاملًا، و14% فقط يراجعون صلاحيات الذكاء الاصطناعي باستمرار أو تلقائيًا.
اقرأ الثلاث معًا فتكون الخلاصة غير مريحة. الضوابط موجودة عادةً. ما ينقص هو التغطية: ضوابط تتوقف عند الأداة المعتمدة ولا تصل إلى النظام المتصل أبدًا، وتغطي الموظفين وتتجاوز الوكلاء.
لماذا هذا أصعب من إدارة الهوية التقليدية
الوكيل مستخدم سيّئ السلوك بالتصميم. يعمل نيابة عن شخص، ويحمل بيانات اعتماد تعيش أطول من المهمة، ويمتد عبر أنظمة التذاكر وإدارة العملاء والمالية وإدارة الأجهزة والهوية، ويغيّر سلوكه عندما يتغير الـprompt أو النموذج. أما أدلة ما فعله فهي موزعة في ثلاثة أماكن في الوقت نفسه: لوحة أداة الذكاء الاصطناعي، والنظام الذي لمسه، والدليل الذي يحمل الهوية. وإعادة بناء إجراء واحد تتطلب ربط الثلاثة، ومعظم المؤسسات لم تقم بهذا الربط ولو مرة واحدة.
ووجد التقرير أيضًا أن المؤسسات تشغل في المتوسط 2.7 أداة ذكاء اصطناعي، كل واحدة تصل إلى نحو ثلاث فئات من أنظمة الشركة، وأن واحدة من كل ثلاث تقول إن الذكاء الاصطناعي يستطيع الوصول إلى طبقة إدارة الهوية نفسها. هذا الرقم يجب أن يوقف النقاش. وكيل يصل إلى نظام إدارة الهوية ليس أداة إنتاجية، بل هو حساب إداري بامتيازات ونافذة محادثة.
سؤال الاستقلالية له رقم
46% من المؤسسات تسمح بالإجراءات عالية الخطورة للوكلاء تلقائيًا. و18% فقط تشترط موافقة بشرية قبل تصرف الوكيل. إذا كان وكيلك يستطيع دفع فاتورة أو تدوير مفتاح أو إعادة تعيين كلمة مرور دون إنسان في المسار، فأنت قد أتمتت تحديدًا الجزء من العملية الذي كان يوجد فيه التقدير.
نحن لا نطالب بإرهاق الموافقات عند كل نقرة. نطالب بأن يكون لمصطلح عالي الخطورة تعريف مكتوب، وأن يُرمّز هذا التعريف حيث يحدث الإجراء، لا في ملف سياسات PDF لا يقرأه أحد أثناء الحادثة.
ما تفعله الفرق الناضجة فعلًا
ينتهي التقرير بدورة حياة IAM للوكلاء من أربع مراحل: اكتشاف كل وكيل، بمن فيهم الذين لم يُبلَّغ عنهم قسم تقنية المعلومات؛ وتسجيل كل وكيل بهدف ونطاق ومالك بشري مسمّى؛ وضبط الوصول بحيث ينتهي مع انتهاء العمل؛ والحكم باستمرار، لأن صلاحيات الوكلاء تنزلق أسرع مما تلحق به المراجعات الربع سنوية.
معظم الفرق تتوقف عند المرحلة الأولى، وأحيانًا الثانية. هذه هي النسخة التي نطبقها مع عملائنا، بالترتيب الذي ينتج أدلة أسرع.
- احصر الوكلاء كما تحصر أنظمة SaaS. اجمع كل تصريح OAuth ومفتاح API وservice principal، واربط كل وكيل بالشخص المسؤول عنه. لا مالك، لا وصول.
- تخلّص من الحسابات المشتركة. الوكيل على حساب خدمة مشترك لا يمكن نسب أي شيء إليه. أعطِ كل وكيل هويته الخاصة وبيانات اعتماد قصيرة الأجل، وستبدأ فجوة الإثبات في الانغلاق في الأسبوع نفسه.
- عرّف عالي الخطورة في الكود. المدفوعات وتغييرات الصلاحيات وتصدير البيانات والكتابة في بيئة الإنتاج. كل ما في هذه القائمة يمر عبر بوابة حتمية، لا عبر رأي نموذج حول ما إذا كان الأمر يبدو مقبولًا.
- أرسل نشاط الوكلاء إلى نظام SIEM الذي تملكه أصلًا. لوحة مزود الذكاء الاصطناعي ليست سجل تدقيقك. احتفظ بالأدلة حيث ينظر محققوك بالفعل.
- راجع باستمرار، لا كل ربع سنة. أتمت مراجعة الصلاحيات، وتعامل مع تغيير صلاحية وكيل كما تتعامل مع تغيير جدار حماية: مسجّل ومراجع وقابل للتراجع.
لا شيء من هذا يتطلب شراء منصة جديدة في اليوم الأول. يتطلب التعامل مع الوكلاء كمجموعة هويات ثانية بنفس الانضباط الذي طبقته على البشر، وأن يحدث ذلك قبل الحادثة لا خلال التحقيق.
الخلاصة لفريقك
الرقم غير المريح في هذا التقرير ليس 72%، بل 99% مقابل 37%: المسافة بين ثقة القادة وجهوزيتهم الفعلية. الثقة غير المدعومة بسجلات ونطاقات وملّاك مسمّين هي مخاطرة، لأنها ما يبقي المشكلة خارج خطة العمل حتى يجدها مدقق أو مهاجم.
ابدأ هذا الأسبوع بسؤال واحد ملموس: اختر أكثر وكلائك امتيازًا، وقل اسم مالكه بصوت مسموع، وحاول إعادة بناء آخر عشرة إجراءات له من سجلاتك أنت. إن نجحت فأنت متقدم على معظم السوق. وإن لم تنجح، فأنت تعرف الآن بدقة أين يذهب ربع السنة القادم من عمل الأمن، ولديك رقم تبرر به ذلك.
وهذا أفضل بكثير من اكتشافه في منتصف اختراق.