هوية وكيل الذكاء الاصطناعي والهوية الآلية: كيف تعرف من ينفذ الفعل وبأي صلاحية؟

لماذا أصبحت الهوية مسألة حوكمة للذكاء الاصطناعي؟

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

لهذا لم يعد السؤال الأمني والحوكمي مقتصرًا على: هل تم السماح بالوصول؟

بل أصبح من الضروري أن تعرف المؤسسة:

• من هو الوكيل الذي اتخذ القرار؟
• بأي هوية تقنية دخل إلى النظام؟
• ما الوسيلة التي استخدمها لإثبات تلك الهوية؟
• ما الصلاحيات المرتبطة بهذه الهوية؟
• هل هذه الصلاحيات تخص الوكيل نفسه أم أنها موروثة من حساب مشترك؟
• من فوّض الوكيل باستخدامها؟
• أي هوية ظهرت في سجل النظام الذي نُفذ فيه الفعل؟
• وهل يمكن ربط الفعل النهائي بالوكيل والمستخدم والسياق الذي بدأ العملية؟

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

Agent Identity: هوية الوكيل

Agent Identity هي الهوية التي تُمثل وكيل الذكاء الاصطناعي ككيان منطقي مستقل داخل المؤسسة.

هي الإجابة عن سؤال:

من هو هذا الوكيل؟

قد تحمل هذه الهوية معلومات مثل:

• الاسم المعتمد للوكيل.
• المعرّف الفريد.
• مالك الوكيل.
• الجهة التنظيمية المسؤولة عنه.
• الوظيفة التي صُمم لأدائها.
• البيئة التي يعمل فيها.
• إصدار الوكيل.
• الأدوات المرتبطة به.
• مستوى المخاطر.
• حالة التشغيل.
• نطاق السلطة.
• Machine Identities المرتبطة به.

الهدف من Agent Identity ليس فقط إعطاء الوكيل اسمًا، بل جعله كيانًا يمكن إدارته وحوكمته وتتبع أفعاله طوال دورة حياته.

Agent Identity ليست اسمًا تسويقيًا للوكيل

وجود اسم مثل:

Procurement Assistant

أو:

Finance Agent

لا يعني أن المؤسسة أنشأت Agent Identity فعلية.

الاسم وحده لا يضمن:

• التفرد.
• الملكية.
• إمكانية التتبع.
• الربط بالصلاحيات.
• الربط بالهوية التقنية.
• تاريخ التغييرات.
• إمكانية التعطيل.
• إثبات المسؤولية.

الهوية المؤسسية للوكيل يجب أن تكون قابلة للتمييز عن مجرد الاسم الظاهر في واجهة المستخدم.

الهوية المنطقية مقابل الهوية التقنية

أحد أهم الفروق في الأنظمة الوكيلية هو الفرق بين:

Logical Identity

و:

Technical Identity

قد يكون لدينا وكيل واحد معروف منطقيًا باسم:

AP-Invoice-Agent

لكن عندما يتصل بنظام ERP فإنه يستخدم Service Account، وعندما يدخل إلى مخزن سحابي يستخدم Managed Identity، وعندما يستدعي API خارجية يستخدم OAuth Client Credential.

كل هذه الهويات التقنية قد تمثل الوكيل نفسه في سياقات مختلفة.

لهذا لا يجوز افتراض أن:

Agent Identity = Machine Identity

بل قد تكون العلاقة:

Agent Identity → واحدة أو أكثر من Machine Identities.

Machine Identity: الهوية الآلية

Machine Identity هي الهوية التقنية غير البشرية التي تستخدمها البرمجيات أو الخدمات أو أعباء العمل أو الوكلاء للمصادقة والوصول إلى الموارد وتنفيذ الأفعال داخل الأنظمة.

هي الإجابة عن سؤال:

بأي هوية تقنية يعمل هذا الكيان؟

من أمثلتها:

• Service Account.
• Workload Identity.
• Managed Identity.
• Application Identity.
• Certificate-based Identity.
• Client Identity.
• API Client.
• حسابات تقنية مخصصة للتكامل.

Machine Identity لا تخبرنا بالضرورة من هو الوكيل من منظور الحوكمة، لكنها تخبر الأنظمة التقنية عن الكيان الذي يطلب الوصول.

Agent Identity لا تساوي Machine Identity

يمكن أن تكون Agent Identity واحدة، لكن وراءها أكثر من Machine Identity.

مثال:

وكيل لإدارة المشتريات قد يمتلك:

• Workload Identity في منصة الحوسبة.
• Service Account داخل ERP.
• OAuth Client في نظام الموردين.
• Certificate Identity عند الاتصال بخدمة توقيع.

من ناحية الأعمال، كلها تخص الوكيل نفسه.

لكن من ناحية IAM والأنظمة التقنية، قد تظهر كأربع هويات مختلفة.

هنا تبدأ مشكلة الربط بين الهوية المنطقية والتنفيذ الفعلي.

Machine Identity لا تساوي Credential

هناك فرق آخر أساسي بين:

Identity

و:

Credential

الهوية تمثل الكيان.

أما Credential فهي وسيلة إثبات أن الكيان هو من يدّعي أنه هو.

قد تشمل Credentials:

• API Key.
• Access Token.
• Client Secret.
• Certificate.
• Private Key.
• Signed Token.
• Temporary Credential.

لذلك:

Machine Identity ≠ Credential.

قد تتغير Credential أو تُدوّر أو تُلغى بينما تبقى Machine Identity نفسها.

لماذا يهم الفصل بين الهوية وCredential؟

إذا اعتبرت المؤسسة الـAPI Key هو الهوية نفسها، فإنها ستواجه مشكلة عند:

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

النموذج الأكثر نضجًا يفصل بين:

Identity → الكيان.

Credential → وسيلة إثبات الهوية.

Permission → ما يمكن للهوية الوصول إليه.

Authority → ما يحق للوكيل أن يفعله.

Credential Ownership

كل Credential مستخدمة من وكيل يجب أن يكون لها مالك معروف.

هذا لا يعني فقط مالكًا تقنيًا للمفتاح أو الشهادة، بل يجب أن يكون من الممكن تحديد:

• Machine Identity المرتبطة بها.
• Agent Identity التي تستخدمها.
• النظام الذي صُدرت من أجله.
• البيئة التي يسمح باستخدامها فيها.
• تاريخ الإصدار.
• تاريخ الانتهاء.
• آلية التدوير.
• آلية الإلغاء.
• مستوى حساسية Credential.

Credential بدون ملكية واضحة يمكن أن تتحول إلى مسار وصول يصعب نسبه أو تعطيله.

Shared Credentials

تزداد المخاطر عندما تستخدم عدة وكلاء Credential واحدة.

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

هذا يضعف:

• Attribution.
• Accountability.
• Incident Investigation.
• Access Review.
• Authority Enforcement.
• Revocation.

ولهذا يجب التعامل مع Shared Credentials باعتبارها استثناءً يحتاج إلى مبرر وضوابط إضافية، لا كنمط افتراضي.

Shared Machine Identity

قد تكون المشكلة أعمق من Credential مشتركة.

يمكن لعدة وكلاء أن يستخدموا Machine Identity واحدة حتى مع تغير Credential الخاصة بها.

مثال:

خمسة وكلاء يستخدمون Service Account واحدًا للوصول إلى ERP.

في سجل ERP سيظهر:

svc_ai_operations

لكن السجل وحده لن يخبرك أي Agent من الخمسة أصدر الفعل.

هذا يسمى هنا مشكلة Shared Machine Identity.

قراءة سيادة: Identity Ambiguity

تستخدم سيادة AI مصطلح Identity Ambiguity لوصف الحالة التي لا تستطيع فيها المؤسسة أن تربط فعلًا تقنيًا بصورة موثوقة بكيان وكيل محدد.

قد تنشأ هذه الحالة بسبب:

• حسابات مشتركة.
• Credentials مشتركة.
• غياب Agent ID في السجلات.
• عدم تمرير Context بين الأنظمة.
• استخدام Middleware يخفي الهوية الأصلية.
• Proxy ينفذ جميع الأفعال باسمه.
• إعادة استخدام Service Accounts بين تطبيقات متعددة.

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

Identity Binding

حتى إذا امتلكت المؤسسة Agent Identity وMachine Identity منفصلتين، فهي تحتاج إلى رابط موثوق بينهما.

هذا الرابط يمكن تسميته:

Identity Binding

وهو إثبات أن Machine Identity معينة مخولة بالعمل نيابة عن Agent Identity محددة ضمن سياق معلوم.

مثلًا:

agent: procurement-agent-01

مرتبط بـ:

workload: prod/procurement-agent

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

قراءة سيادة: Agent-to-Machine Identity Binding

تستخدم سيادة AI مفهوم Agent-to-Machine Identity Binding للتعبير عن العلاقة الموثقة بين الهوية المنطقية للوكيل والهوية التقنية التي يستخدمها للتنفيذ.

يمكن تمثيله بصورة مبسطة:

Agent Identity ↓ Machine Identity ↓ Credential ↓ Authenticated Session ↓ Resource Access ↓ Action

كلما انقطعت إحدى حلقات هذه السلسلة أصبحت عملية إسناد الفعل النهائي أكثر صعوبة.

Static Binding وDynamic Binding

ليس من الضروري أن يكون الربط بين Agent Identity وMachine Identity ثابتًا دائمًا.

قد يكون:

Static Binding

بحيث يستخدم الوكيل Machine Identity مخصصة له بصورة مستمرة.

أو:

Dynamic Binding

بحيث يتم إصدار هوية أو Credential قصيرة العمر للوكيل عند بدء مهمة معينة.

النموذج الديناميكي يمكن أن يوفر سياقًا أفضل، لكنه يتطلب بنية IAM قادرة على إصدار وربط الهويات بصورة موثوقة.

Ephemeral Identity

في البيئات الحديثة قد تُنشأ هوية مؤقتة للعملية أو المهمة ثم تنتهي بعد انتهاء التنفيذ.

هذه Ephemeral Identity يمكن أن تقلل من مخاطر الاعتماد على Credentials طويلة العمر، لكنها لا تلغي الحاجة إلى الربط.

بل يجب أن نعرف:

• لمن أُصدرت؟
• لأي Agent؟
• لأي مهمة؟
• لأي مدة؟
• بأي Authority؟
• ما الموارد المسموحة؟
• متى انتهت؟

الهوية المؤقتة غير المرتبطة بسياق موثق قد تكون قصيرة العمر لكنها ضعيفة من ناحية المساءلة.

Workload Identity

Workload Identity هي نمط مهم من Machine Identity، حيث تتم مصادقة عبء عمل برمجي بدل الاعتماد على مستخدم بشري أو Secret ثابت.

بالنسبة لوكلاء الذكاء الاصطناعي، يمكن استخدامها لمنح Runtime أو خدمة Agent هوية تقنية مستقلة.

لكن Workload Identity وحدها لا تحل كل مشكلة الهوية.

يبقى السؤال:

هل هذه Workload Identity مرتبطة بوكيل واحد أم بعدة وكلاء؟

وهل يمكن من السجل إثبات أي Agent كان وراء الفعل؟

Service Accounts

Service Accounts منتشرة في الأنظمة المؤسسية، لكنها قد تتحول إلى نقطة ضعف إذا استُخدمت كأساس وحيد لهوية الوكيل.

المشكلة ليست في Service Account نفسها.

المشكلة تظهر عندما تكون:

• مشتركة بين عدة وكلاء.
• واسعة الصلاحيات.
• طويلة العمر.
• Credentials الخاصة بها ثابتة.
• غير مرتبطة بمالك واضح.
• لا تحمل Context عن Agent الفعلي.
• لا تخضع للمراجعة الدورية.

لهذا يجب ألا تصبح عبارة "الوكيل يستخدم Service Account" نهاية تحليل الهوية، بل بدايته.

Non-Human Identity

وكلاء الذكاء الاصطناعي يدخلون ضمن عالم أوسع من Non-Human Identities.

هذا العالم قد يشمل:

• التطبيقات.
• الخدمات.
• الـBots.
• Workloads.
• CI/CD pipelines.
• Automation accounts.
• Integration services.
• AI Agents.

لكن Agent Identity تضيف تحديًا إضافيًا لأن الوكيل قد لا يكتفي بتنفيذ تعليمات ثابتة، بل قد يفسر السياق ويختار الأدوات ويقرر تسلسل الخطوات.

ولهذا فإن حوكمة هوية Agent تحتاج إلى ربط الهوية بالسلطة والسياق، لا مجرد المصادقة.

Authentication لا تكفي

Authentication تجيب عن سؤال:

هل تم إثبات هوية الكيان؟

لكنها لا تجيب وحدها عن:

• هل هذا Agent مخول باستخدام هذه الهوية؟
• هل الاستخدام مسموح في هذه المهمة؟
• هل الصلاحية مناسبة للسياق؟
• هل الفعل داخل Authority Envelope؟
• هل Credential مسموح باستخدامها في بيئة الإنتاج؟
• هل يمكن نسبة العملية إلى Agent معين؟

لذلك:

Authentication ≠ Governance.

Authorization لا تكفي أيضًا

Authorization تحدد ما تسمح به المنظومة التقنية للهوية.

لكن كما ظهر في مفهوم Effective Access، القدرة التقنية ليست مساوية دائمًا للسلطة المؤسسية.

قد تسمح Machine Identity بحذف سجل.

لكن Agent Authority قد تمنع الوكيل من الحذف.

وقد تسمح الهوية بتنفيذ تحويل مالي.

لكن Authority Envelope قد تتطلب موافقة بشرية قبل التنفيذ.

إذًا نحتاج إلى فصل واضح بين:

Identity Authentication Authorization Effective Access Authority Execution

النموذج المتكامل للهوية والوصول والسلطة

يمكن تمثيل العلاقة كالتالي:

Agent Identity

من هو الوكيل؟

↓

Machine Identity

بأي هوية تقنية يعمل؟

↓

Credential

كيف يثبت هذه الهوية؟

↓

Authentication

هل تم إثباتها؟

↓

Authorization

ما الصلاحيات الممنوحة للهوية؟

↓

Effective Access

ما الذي تستطيع الوصول إليه فعليًا بعد جمع كل المسارات والتكاملات؟

↓

Agent Authority

ما الذي يحق للوكيل أن يفعله مؤسسيًا؟

↓

Execution

ما الذي تم تنفيذه فعلًا؟

↓

Accountability

كيف نثبت من فعل ماذا ولماذا وبأي سلطة؟

Execution Identity

أحد أهم الأسئلة عند التحقيق في أي فعل هو:

أي هوية ظهرت عند نقطة التنفيذ النهائية؟

هذه الهوية يمكن تسميتها هنا Execution Identity.

قد تكون:

• Machine Identity الخاصة بالوكيل نفسه.
• Service Account وسيطة.
• هوية أداة.
• حساب مستخدم تم تفويضه.
• هوية منصة مشتركة.
• حساب Integration.

إذا كانت Execution Identity مختلفة عن Agent Identity، فيجب أن تكون العلاقة بينهما قابلة للإثبات.

قراءة سيادة: Execution Identity

تستخدم سيادة AI مصطلح Execution Identity للإشارة إلى الهوية التي يراها النظام الهدف باعتبارها منفذ الإجراء النهائي.

التمييز مهم لأن:

Agent Identity قد تكون معروفة في منصة الوكيل،

بينما Execution Identity الظاهرة في ERP أو CRM أو قاعدة البيانات قد تكون مختلفة تمامًا.

الفجوة بينهما هي ما يجب أن تعالجه سجلات الربط والسياق.

Identity Propagation

عندما تمر العملية عبر عدة أنظمة، يجب التفكير في كيفية انتقال معلومات الهوية.

مثال:

User → Agent → Orchestrator → Tool → API Gateway → ERP

إذا احتفظ ERP فقط بهوية API Gateway، فقد تضيع معرفة Agent الأصلي والمستخدم الذي بدأ العملية.

Identity Propagation تعني المحافظة على سياق هوية مناسب عبر سلسلة التنفيذ.

لا يعني Identity Propagation تمرير Credentials

نقل سياق الهوية لا يعني تمرير Password أو Token الأصلي من نظام إلى آخر بصورة عشوائية.

بل الهدف هو أن تستطيع الأنظمة اللاحقة معرفة السياق الموثوق للعملية، مثل:

• Agent ID.
• Request ID.
• Delegation ID.
• Session ID.
• Human Initiator.
• Authority Context.

مع الحفاظ على الفصل الأمني بين Credentials المستخدمة في كل طبقة.

Human Identity وAgent Identity

قد يبدأ الفعل من مستخدم بشري ثم يكمله Agent.

في هذه الحالة يجب عدم دمج الهويتين.

نحتاج إلى تمييز:

Human Initiator

من بدأ الطلب؟

و:

Agent Actor

من قرر أو نسق أو نفذ الخطوات؟

قد يكون المستخدم هو initiator، لكن الوكيل هو actor المسؤول عن سلسلة من القرارات الآلية.

On-Behalf-Of Execution

في بعض السيناريوهات يعمل الوكيل "نيابة عن" مستخدم.

هذا لا يعني تلقائيًا أن الوكيل يجب أن يرث كل صلاحيات المستخدم.

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

المطلوب هو تصميم Delegation مقيدة بالسياق والمهمة والمدة والموارد.

Delegated Identity

Delegated Identity تعني أن كيانًا يستخدم صلاحية أو سياق هوية مفوضًا من كيان آخر.

في سيناريو الوكلاء قد تكون السلسلة:

User → Agent → Tool → Resource

إذا كان الوكيل يعمل بصلاحيات مشتقة من المستخدم، فيجب أن يكون هذا التفويض:

• صريحًا.
• محدودًا.
• قابلًا للتتبع.
• محدد المدة.
• مرتبطًا بالمهمة.
• قابلًا للإلغاء.

قراءة سيادة: Identity Delegation Chain

تستخدم سيادة AI مفهوم Identity Delegation Chain لوصف سلسلة انتقال سياق الهوية أو التفويض عبر عدة كيانات قبل الوصول إلى النظام النهائي.

مثال:

Human Identity → Agent Identity → Machine Identity → Tool Identity → Execution Identity

كل انتقال يجب أن يكون قابلًا للتفسير.

إذا لم تستطع المؤسسة إعادة بناء هذه السلسلة بعد الحادث، فإن مستوى المساءلة ينخفض بصورة كبيرة.

Impersonation Risk

يظهر خطر Impersonation عندما يستطيع وكيل أو خدمة تنفيذ أفعال تبدو في الأنظمة وكأن مستخدمًا آخر قام بها.

هذا قد يحدث عندما:

• يستخدم Agent Session المستخدم نفسها.
• يرث Token واسع الصلاحيات.
• يستدعي نظامًا باسم المستخدم دون تسجيل Actor الحقيقي.
• يستخدم حسابًا مشتركًا.
• يتم إسقاط معلومات Agent من سجل التنفيذ.

النتيجة قد تكون سجلًا يقول:

"المستخدم أحمد نفذ العملية"

بينما الذي اختار الإجراء فعليًا كان Agent.

Actor وSubject

من المفيد في بعض السيناريوهات التمييز بين:

Actor

الكيان الذي قام بالفعل.

و:

Subject

الكيان الذي تم التنفيذ نيابة عنه أو في سياقه.

مثال:

Subject = موظف المشتريات.

Actor = Procurement Agent.

Execution Identity = workload-prod-purchasing.

هذه الطبقات الثلاث لا يجب دمجها في سجل واحد مبهم.

قراءة سيادة: Identity Triad

تستخدم سيادة AI نموذج Identity Triad لتمييز ثلاث هويات قد تجتمع في العملية الواحدة:

1. Initiator Identity — من بدأ الطلب.
2. Agent Identity — من اتخذ أو نسق القرار.
3. Execution Identity — من ظهر تقنيًا عند تنفيذ الفعل.

وجود هذه الثلاثية في سجل قابل للربط يرفع جودة المساءلة بدرجة كبيرة.

لماذا الحساب المشترك مشكلة حوكمة وليس IAM فقط؟

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

بل قد يصبح من الصعب تحديد:

• أي Agent أصدر الأمر.
• أي نموذج كان يعمل وقتها.
• أي Prompt أو Context أثر في القرار.
• أي Authority كانت مطبقة.
• من يجب أن يتحمل مسؤولية الحادث.
• أي وكيل يجب تعطيله.
• هل الحادث ناتج عن Agent واحد أم عن الحساب نفسه.

لذلك Shared Identity يمكن أن تكسر سلسلة المساءلة كاملة.

One Agent, One Identity؟

القاعدة البسيطة "هوية لكل وكيل" مفيدة كبداية، لكنها ليست كافية دائمًا.

فالوكيل الواحد قد يحتاج إلى عدة Machine Identities حسب:

• البيئة.
• النظام.
• مستوى المخاطر.
• نوع المهمة.
• Tenant.
• المنطقة الجغرافية.
• البيانات.
• المرحلة التشغيلية.

لذلك السؤال الأفضل ليس:

هل لكل Agent هوية واحدة؟

بل:

هل كل Machine Identity مرتبطة بوضوح بـAgent وبسياق استخدام محدد؟

One Identity, Multiple Agents

الحالة الأخطر عادة هي الاتجاه العكسي:

Machine Identity واحدة يستخدمها عدد كبير من الوكلاء.

كلما زاد عدد Agents خلف هوية واحدة، زادت صعوبة:

• Attribution.
• Revocation.
• Blast Radius Analysis.
• Authority Mapping.
• Forensics.

ولهذا تحتاج المؤسسة إلى معرفة نسبة مشاركة Machine Identities بين Agents.

قراءة سيادة: Identity Concentration

تستخدم سيادة AI مفهوم Identity Concentration لوصف مقدار تجمع عدة وكلاء أو وظائف خلف Machine Identity واحدة.

ارتفاع Identity Concentration يعني أن تعطيل أو اختراق أو إساءة استخدام هذه الهوية قد يؤثر في عدد أكبر من الوكلاء والعمليات.

وهو ليس مصطلحًا رسميًا منسوبًا إلى PCI SSC، بل مقياس تشغيلي مقترح من سيادة لتحليل مخاطر الهوية المشتركة.

Identity Blast Radius

إذا تم اختراق Machine Identity، فإن حجم الضرر المحتمل لا يعتمد فقط على صلاحياتها المباشرة، بل أيضًا على عدد Agents والأنظمة والمهام المرتبطة بها.

لهذا يجب تحليل:

• الموارد التي يمكن الوصول إليها.
• الأفعال الممكن تنفيذها.
• عدد الوكلاء الذين يستخدمون الهوية.
• الأنظمة المتصلة.
• إمكانية الوصول إلى Credentials أخرى.
• إمكانية الانتقال إلى أدوات إضافية.

Identity Blast Radius يرتبط مباشرة بمفاهيم Effective Access وLeast Agency.

Agent Identity وEffective Access

لا يمكن حساب Effective Access للوكيل بصورة دقيقة إذا لم تعرف جميع Machine Identities المرتبطة به.

قد تقول وثيقة التصميم إن Agent لديه وصول إلى نظامين فقط.

لكن إذا كان يستخدم Machine Identity مشتركة لها وصول إلى ستة أنظمة، فإن الوصول الفعلي أكبر من الوصول المعلن.

لذلك:

Agent Effective Access

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

Agent Identity وAgent Authority

الهوية والسلطة مفهومان مختلفان لكنهما مترابطان.

Agent Identity تقول:

من هو الوكيل؟

Agent Authority تقول:

ماذا يحق لهذا الوكيل أن يفعل؟

لكن تطبيق Authority بصورة قابلة للإنفاذ يتطلب معرفة موثوقة بمن هو الوكيل عند نقطة التنفيذ.

إذا لم تستطع منصة التحكم معرفة Agent الحقيقي خلف Machine Identity مشتركة، فإن تطبيق سياسة سلطة مختلفة لكل Agent يصبح أكثر صعوبة.

Identity قبل Authority Enforcement

قد تكتب المؤسسة سياسة تقول:

Agent A يستطيع اعتماد معاملات حتى 5,000.

Agent B يستطيع القراءة فقط.

لكن إذا كان A وB يستخدمان Machine Identity نفسها داخل النظام المالي، فإن النظام قد لا يستطيع التمييز بينهما عند Enforcement.

لهذا فإن جودة Authority Enforcement تعتمد جزئيًا على جودة Identity Binding.

قراءة سيادة: Identity-Authority Binding

تستخدم سيادة AI مفهوم Identity-Authority Binding لوصف الربط بين Agent Identity المعروفة وبين Authority الممنوحة لها بصورة قابلة للإنفاذ.

السلسلة المطلوبة هي:

Agent Identity → Authority Policy → Machine Identity → Enforcement Point

إذا كانت السياسة مرتبطة بالـAgent منطقيًا لكن نقطة التنفيذ ترى فقط هوية مشتركة، تظهر فجوة بين الحوكمة المكتوبة والتنفيذ التقني.

هوية الوكيل كأصل مؤسسي

يجب أن تعامل Agent Identity كأصل مؤسسي قابل للإدارة طوال دورة حياته.

أي أن لها:

• إنشاء.
• مالك.
• تسجيل.
• تصنيف.
• ربط بأنظمة.
• ربط بصلاحيات.
• مراجعة.
• تغيير.
• تعليق.
• إلغاء.
• تقاعد.

عدم وجود lifecycle للهوية يعني أن Agents قد تبقى لها Machine Identities أو Credentials حتى بعد انتهاء الحاجة إليها.

Birth Certificate للوكيل

عند إنشاء Agent جديد، يجب تسجيل حد أدنى من معلومات الهوية قبل منحه صلاحيات تشغيلية.

يمكن أن يشمل ذلك:

• Agent ID.
• الاسم.
• المالك.
• الغرض.
• البيئة.
• درجة المخاطر.
• النظام المضيف.
• النموذج أو العائلة المستخدمة.
• الأدوات.
• Machine Identities.
• Authority Owner.
• تاريخ الإنشاء.
• تاريخ المراجعة القادمة.

هذا السجل يصبح نقطة انطلاق لإدارة دورة حياة Agent.

Identity Lifecycle

دورة حياة هوية الوكيل يمكن تقسيمها إلى:

Create

إنشاء Agent Identity.

Bind

ربطها بـMachine Identities.

Authorize

إسناد الصلاحيات والسلطة.

Operate

الاستخدام التشغيلي.

Review

مراجعة الروابط والصلاحيات.

Change

تحديث الهوية أو السياق.

Suspend

تعليق التشغيل.

Revoke

إلغاء Credentials أو Machine Identities.

Retire

إغلاق الهوية بصورة نهائية.

Identity Orphans

قد تبقى Machine Identity موجودة بعد حذف Agent أو إيقافه.

هذه الحالة تؤدي إلى ما يمكن وصفه بـOrphan Identity.

المشكلة أن الهوية التقنية قد تظل:

• نشطة.
• قادرة على المصادقة.
• محتفظة بصلاحيات.
• مستخدمة في عمليات قديمة.
• غير مرتبطة بمالك حالي.

ولهذا يجب أن يرتبط Retirement للوكيل بإجراءات IAM فعلية.

قراءة سيادة: Agent Identity Orphan

تستخدم سيادة AI مفهوم Agent Identity Orphan لوصف Agent Identity أو Machine Identity فقدت ارتباطها بمالك أو وكيل أو غرض تشغيلي واضح، بينما ما زالت موجودة أو قابلة للاستخدام.

هذا النوع من الأصول يجب أن يظهر في المراجعات كحالة تحتاج إلى معالجة وليس كسجل تاريخي عادي.

Identity Change كحدث حوكمة

تغيير Machine Identity لوكيل ليس مجرد تغيير تقني بسيط.

فقد يؤدي إلى:

• صلاحيات مختلفة.
• Effective Access مختلف.
• سجلات مختلفة.
• Enforcement مختلف.
• Secrets جديدة.
• بيئة مختلفة.

لذلك ينبغي تقييم بعض تغييرات الهوية باعتبارها Governance Change Events.

قراءة سيادة: Identity Change Event

تستخدم سيادة AI مفهوم Identity Change Event لأي تغيير جوهري قد يؤثر في الطريقة التي يُعرّف بها الوكيل تقنيًا أو في الوصول الناتج عن هويته.

من أمثلته:

• استبدال Service Account.
• إضافة Workload Identity.
• نقل Agent إلى Tenant آخر.
• إضافة Credential جديدة.
• تغيير آلية Delegation.
• تحويل الحساب من مخصص إلى مشترك.
• إضافة نظام يمكن تنفيذ الأفعال داخله.

ويجب أن يؤدي الحدث، حسب مستوى المخاطر، إلى إعادة فحص الوصول والسلطة والسجلات.

Rotation لا تعني تغيير الهوية

تدوير Credential لا يعني بالضرورة تغيير Machine Identity.

مثال:

يمكن إصدار Certificate جديدة لنفس Workload Identity.

هنا:

Identity بقيت نفسها.

Credential تغيرت.

هذا الفصل مهم عند بناء سجل تاريخي للهوية.

Revocation

يجب أن تستطيع المؤسسة سحب قدرة الوكيل على استخدام Machine Identity أو Credential عند الحاجة.

قد تكون أسباب الإلغاء:

• حادث أمني.
• تغيير وظيفة Agent.
• انتهاء المشروع.
• تغيير مالك.
• الاشتباه بإساءة الاستخدام.
• توسع غير مبرر في الصلاحيات.
• انتهاء صلاحية التكامل.

Revocation الفعالة يجب أن تؤثر على القدرة التقنية الفعلية، لا أن تقتصر على تغيير حالة Agent في لوحة إدارية.

Identity Kill Path

إذا تم تعطيل Agent في منصة التشغيل لكن Machine Identity الخاصة به ما زالت تستطيع المصادقة، فإن Kill Switch غير مكتملة.

من هنا يجب التفكير في مسار تعطيل الهوية:

Agent Disable → Session Termination → Credential Revocation → Machine Identity Disable → Tool Access Removal → Verification

هذا المسار سيكون جزءًا مهمًا من العلاقة بين الهوية وآليات Kill Switch.

الهوية والـAI-BOM

يمكن لـAI-BOM أن تساعد المؤسسة في معرفة المكونات التي يعتمد عليها النظام، لكن إدارة الهوية تحتاج إلى إضافة سؤال:

ما الهويات المستخدمة بين هذه المكونات؟

يمكن أن يشمل سجل الهوية المرتبط بـAI-BOM:

• Agent Identity.
• Machine Identity.
• Credential Type.
• Resource.
• Environment.
• Owner.
• Permissions.
• Expiration.
• Rotation Policy.
• Revocation Method.

وهكذا لا يصبح سجل المكونات مجرد قائمة تقنية، بل مدخلًا لتحليل الوصول والمسؤولية.

الهوية وGovernance BOM

من منظور أوسع، يمكن ربط الهوية بسجل حوكمي يشمل:

• Agent Owner.
• Business Owner.
• Machine Identities.
• Access Owners.
• Authority Owner.
• Human Oversight Owner.
• Kill Switch Owner.
• Audit Evidence.

هذه الروابط تساعد المؤسسة على الإجابة عن سؤال المسؤولية بصورة أسرع عند وقوع حادث.

الهوية وMCP

عند استخدام Model Context Protocol أو بنية مشابهة لربط الوكلاء بالأدوات، تصبح مسألة الهوية أكثر تعقيدًا.

يجب معرفة:

• أي Agent اتصل بـMCP Server؟
• بأي Machine Identity؟
• هل MCP Server يعيد استخدام هوية مشتركة؟
• ما الهوية التي يستخدمها Server عند الاتصال بالأنظمة الخلفية؟
• هل ينتقل Agent Context عبر السلسلة؟
• هل يمكن ربط Tool Call بالـAgent الأصلي؟

وجود MCP Server بين Agent والنظام الهدف لا يجب أن يحجب سلسلة الهوية.

Proxy Identity Problem

قد يعمل MCP Server أو API Gateway أو Middleware كـProxy ينفذ جميع الطلبات باسم هويته.

هذا قد يؤدي إلى:

Agent A Agent B Agent C ↓ Proxy Identity ↓ Target System

النظام الهدف يرى Proxy فقط.

إذا لم تحتفظ الطبقات الوسيطة بسجلات موثوقة، تصبح Attribution معتمدة بالكامل على سجل الـProxy.

قراءة سيادة: Identity Collapse

تستخدم سيادة AI مفهوم Identity Collapse لوصف الحالة التي تبدأ فيها سلسلة التنفيذ بعدة هويات متميزة لكنها تنتهي في نظام الهدف بهوية مشتركة واحدة دون بقاء سياق موثوق يسمح بإعادة الفصل بينها.

Identity Collapse من أخطر أسباب فقدان المساءلة في البيئات الوكيلية متعددة الطبقات.

الحد الأدنى لهوية قابلة للمساءلة

قبل منح Agent قدرة تنفيذية مهمة، يجب أن تستطيع المؤسسة على الأقل معرفة:

1. Agent Identity.
2. Agent Owner.
3. Machine Identity.
4. Credential Type.
5. Environment.
6. Effective Access.
7. Agent Authority.
8. Execution Identity.
9. طريقة الإلغاء.
10. مكان السجل الذي يثبت العملية.

إذا لم تكن هذه العناصر معروفة، فإن قدرة المؤسسة على إثبات المسؤولية والسيطرة على الوكيل تصبح محدودة.

قاعدة عملية

لا تمنح Agent سلطة لا تستطيع ربط استخدامها بهوية قابلة للتتبع.

وإذا كان النظام الهدف لا يستطيع تمييز Agent نفسه، فيجب أن توجد طبقة موثوقة أخرى تستطيع إعادة بناء السلسلة:

Human Initiator → Agent Identity → Machine Identity → Credential → Tool → Execution Identity → Action

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

Identity Registry

حتى تستطيع المؤسسة إدارة هويات الوكلاء بصورة منهجية، تحتاج إلى سجل مركزي أو مرجعي يجيب عن سؤال:

ما الوكلاء والهويات غير البشرية الموجودة لدينا الآن؟

يمكن أن يحتوي Identity Registry على:

• Agent ID.
• Agent Name.
• Agent Owner.
• Business Owner.
• Technical Owner.
• Machine Identities.
• Credential Types.
• Environment.
• Tenant.
• Systems Accessed.
• Effective Access.
• Authority Profile.
• Status.
• Creation Date.
• Last Review Date.
• Retirement Date.

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

Unique Agent Identity

يجب أن يمتلك كل Agent معرّفًا فريدًا داخل النطاق المؤسسي المناسب.

الاسم البشري وحده غير كافٍ.

قد توجد عدة نسخ من:

Finance Agent

في:

• التطوير.
• الاختبار.
• الإنتاج.
• شركة فرعية.
• Tenant مختلف.
• إصدار مختلف.

ولهذا يجب أن يكون Agent ID قادرًا على التمييز بينها بوضوح.

Human-Readable Name وCanonical ID

يفضل الفصل بين:

Human-Readable Name

الاسم الذي يراه المستخدم أو المسؤول.

و:

Canonical Agent ID

المعرف الفريد الذي تعتمد عليه السجلات والسياسات والربط بين الأنظمة.

يمكن أن يتغير الاسم الظاهر دون أن تتغير هوية Agent الأساسية.

Environment Binding

يجب أن تكون هوية الوكيل مرتبطة بالبيئة التي تعمل فيها.

مثال:

agent-prod-001

ليست هي نفسها من منظور المخاطر:

agent-dev-001

حتى إذا كان الكود نفسه.

البيئات المختلفة قد تحتوي على:

• بيانات مختلفة.
• صلاحيات مختلفة.
• أدوات مختلفة.
• Credentials مختلفة.
• مستوى تدقيق مختلف.
• ضوابط مختلفة.

لهذا لا يجب أن تكون Environment مجرد Metadata ثانوية.

قراءة سيادة: Environment Identity Binding

تستخدم سيادة AI مفهوم Environment Identity Binding لوصف الربط بين Agent Identity والبيئة التشغيلية التي يُسمح لها بالعمل داخلها.

الهدف هو منع حالات مثل:

• Credential إنتاجية تُستخدم في التطوير.
• Agent تجريبي يدخل إلى نظام حي.
• Identity مخصصة للاختبار تعمل على بيانات حقيقية.
• انتقال Agent بين البيئات دون إعادة تقييم صلاحياته.

Tenant Binding

في الأنظمة متعددة المستأجرين، يجب أن يكون واضحًا لأي Tenant تنتمي الهوية.

قد يؤدي ضعف Tenant Binding إلى أخطر أنواع أخطاء الوصول، مثل استخدام Machine Identity تملك وصولًا إلى بيانات أكثر من مستأجر.

لذلك يجب أن تكون العلاقة:

Agent Identity → Tenant → Machine Identity → Resource Scope

واضحة وقابلة للإنفاذ.

Cross-Tenant Identity Risk

إذا استطاعت Machine Identity نفسها العمل عبر أكثر من Tenant، يجب أن تكون هناك مبررات وضوابط قوية.

الأسئلة الأساسية:

• هل هذا مطلوب فعلًا؟
• هل الوصول قابل للفصل؟
• هل Logs تحمل Tenant Context؟
• هل يمكن للوكيل نقل البيانات بين Tenants؟
• هل Authority مختلفة حسب Tenant؟
• هل يمكن تعطيل الوصول لمستأجر واحد دون تعطيل الجميع؟

قراءة سيادة: Identity Scope

تستخدم سيادة AI مفهوم Identity Scope للإشارة إلى النطاق الذي تكون فيه Agent Identity أو Machine Identity صالحة للاستخدام.

قد يشمل النطاق:

• Environment.
• Tenant.
• Organization.
• Region.
• Application.
• System.
• Data Domain.
• Time Window.

كلما كان Identity Scope أوسع من الحاجة الفعلية، ارتفع حجم المخاطر المحتملة.

Session Identity

بعد نجاح Authentication، غالبًا تنشأ Session أو Security Context تُستخدم خلال فترة التنفيذ.

هذه الجلسة قد تحمل:

• Machine Identity.
• User Context.
• Agent ID.
• Token Claims.
• Roles.
• Permissions.
• Tenant.
• Expiration.
• Delegation Information.

ولهذا يجب التفكير في Session Identity وليس فقط Identity الأصلية.

Long-Lived Sessions

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

إذا تم تغيير Authority أو تعطيل Agent بينما Session ما زالت فعالة، فقد يستمر الوصول.

لذلك يجب أن تدرس المؤسسة:

• Session Duration.
• Forced Reauthentication.
• Token Revocation.
• Session Termination.
• Policy Re-evaluation.
• Continuous Authorization.

قراءة سيادة: Identity Freshness

تستخدم سيادة AI مفهوم Identity Freshness لوصف مدى حداثة المعلومات الأمنية والحوكمية التي تعتمد عليها جلسة التنفيذ.

قد تصبح الجلسة قديمة إذا تغير:

• Agent Status.
• Owner.
• Authority.
• Permissions.
• Tenant.
• Risk Level.
• Machine Identity Binding.

لكن الجلسة تستمر باستخدام معلومات سابقة.

ولهذا كلما زادت حساسية العملية، زادت الحاجة إلى إعادة التحقق من السياق.

Credential Lifecycle

Credential المستخدمة من Machine Identity يجب أن تمر بدورة حياة واضحة:

Issue

إصدارها.

Store

حمايتها وتخزينها.

Use

استخدامها ضمن نطاق محدد.

Rotate

تدويرها دوريًا أو عند الحاجة.

Expire

انتهاء صلاحيتها.

Revoke

سحبها.

Destroy

إزالة النسخ غير المطلوبة.

إدارة Credential يجب ألا تكون منفصلة عن Agent Lifecycle.

Long-Lived Secrets

Credentials طويلة العمر مثل API Keys أو Client Secrets الثابتة قد تزيد المخاطر لأنها:

• قابلة للتسريب.
• قد تُنسخ إلى بيئات أخرى.
• قد تبقى بعد انتهاء الحاجة.
• يصعب معرفة من استخدمها.
• قد لا تحمل Context للمهمة.
• قد تُشارك بين عدة وكلاء.

كلما أمكن، يفضل تقليل الاعتماد على Secrets دائمة لصالح آليات قصيرة العمر أو Managed Identity أو Workload Identity مناسبة.

Secret Sprawl

يمكن أن ينتشر Secret نفسه عبر:

• ملفات إعداد.
• CI/CD.
• متغيرات بيئة.
• Scripts.
• Notebooks.
• حاويات.
• أجهزة مطورين.
• منصات أتمتة.
• Agent Tools.

كل نسخة إضافية تزيد صعوبة الإلغاء والتأكد من إزالة Credential بالكامل.

قراءة سيادة: Credential Footprint

تستخدم سيادة AI مفهوم Credential Footprint لوصف عدد الأماكن والأنظمة والنسخ التي توجد فيها Credential أو يمكن استخدامها منها.

كلما اتسع هذا الأثر، أصبحت عملية Rotation وRevocation والتحقيق أكثر تعقيدًا.

Credential Rotation

Rotation ليست عملية تجميلية.

يجب أن تتأكد المؤسسة بعد تدوير Credential من:

• تحديث Agent الصحيح.
• إلغاء النسخة السابقة.
• عدم بقاء نسخ قديمة في أدوات أخرى.
• عدم توقف الأنظمة نتيجة الRotation.
• استمرار Identity Binding.
• تسجيل التغيير.

Credential Rotation Failure

قد تفشل عملية Rotation بطريقة صامتة عندما:

• يتم إصدار Credential جديدة.
• يبدأ Agent باستخدامها.
• تبقى القديمة صالحة أيضًا.

هنا لم يحدث استبدال فعلي، بل تم توسيع عدد Credentials النشطة.

هذا قد يزيد مساحة الهجوم بدل تقليلها.

Credential Revocation

يجب اختبار Revocation، لا الاكتفاء بافتراض أنها تعمل.

بعد الإلغاء يجب أن نتحقق من أن:

• Authentication يفشل.
• Sessions النشطة أُغلقت إن لزم.
• Tokens المشتقة لم تعد صالحة.
• أدوات وسيطة لا تملك نسخة أخرى.
• Agent لم ينتقل تلقائيًا إلى Credential بديلة غير مسجلة.

قراءة سيادة: Revocation Completeness

تستخدم سيادة AI مفهوم Revocation Completeness لقياس ما إذا كانت عملية سحب الهوية أو Credential أوقفت جميع المسارات التي كانت تسمح للوكيل بالاستمرار في التنفيذ.

Revocation غير الكاملة قد تترك:

• Sessions.
• Cached Tokens.
• Secondary Credentials.
• Proxy Access.
• Tool Credentials.

نشطة بعد قرار التعطيل.

Agent-to-Agent Identity

في البيئات متعددة الوكلاء، قد يتعامل Agent مع Agent آخر كما يتعامل مع خدمة خارجية.

عندها يجب معرفة:

• هوية Agent الطالب.
• هوية Agent المستجيب.
• Authority لكل منهما.
• هل الطلب مسموح؟
• هل Agent الثاني يستطيع إعادة تفويض الطلب؟
• ما السياق الذي انتقل؟
• ما الهوية التي ستظهر عند التنفيذ النهائي؟

Agent-to-Agent Authentication

لا يجب أن يفترض Agent أن أي رسالة داخلية جاءت من Agent موثوق.

من المهم وجود آلية موثوقة للتحقق من هوية Agent الآخر، خصوصًا عندما يكون التواصل عبر:

• Message Bus.
• API.
• Agent Protocol.
• MCP.
• Event Queue.
• Workflow Engine.

Agent-to-Agent Authorization

حتى بعد معرفة هوية Agent آخر، يجب تحديد ما المسموح له بطلبه.

Agent المصادَق عليه لا يعني أنه مخول بكل شيء.

ينطبق هنا نفس الفصل:

Authentication ≠ Authorization ≠ Authority

Delegated Agent Execution

قد يطلب Agent A من Agent B تنفيذ مهمة.

في هذه الحالة يجب تحديد:

• من يملك Authority الأصلية؟
• هل A مسموح له بالتفويض؟
• هل B يملك Authority مستقلة؟
• هل يتم نقل Authority أم فقط Task Context؟
• من يظهر في سجل التنفيذ؟
• من يتحمل المسؤولية؟

قراءة سيادة: Agent Delegation Identity

تستخدم سيادة AI مفهوم Agent Delegation Identity لوصف هوية الوكيل الذي يعمل نتيجة تفويض صادر عن Agent آخر، مع الاحتفاظ بسلسلة تسمح بمعرفة المصدر الأصلي للتفويض.

السلسلة قد تكون:

Human → Agent A → Agent B → Tool → Resource

ويجب ألا تختزل كلها في هوية Agent B فقط.

Delegation Context

عند التفويض من Agent إلى Agent آخر، يجب أن ينتقل الحد الأدنى اللازم من السياق، مثل:

• Delegation ID.
• Origin Agent.
• Initiator.
• Task Purpose.
• Authority Limit.
• Expiration.
• Resource Scope.
• Approval Context.

غياب هذا السياق قد يجعل Agent المستلم يتصرف بسلطته الافتراضية بدل السلطة المرتبطة بالمهمة الأصلية.

Identity and Privilege Escalation

يمكن أن يحدث Privilege Escalation إذا انتقل Agent من هوية منخفضة الصلاحيات إلى Machine Identity أقوى.

قد يحدث ذلك عبر:

• Tool مختلف.
• Service Account أعلى صلاحية.
• Admin API.
• Credential موجودة في البيئة.
• Agent آخر.
• Workflow له امتيازات أوسع.

لذلك يجب مراقبة انتقالات الهوية، لا فقط الصلاحيات داخل هوية واحدة.

قراءة سيادة: Identity Pivot

تستخدم سيادة AI مفهوم Identity Pivot لوصف انتقال Agent أثناء التنفيذ من Machine Identity إلى أخرى تمنحه وصولًا أو قدرة مختلفة.

قد يكون Identity Pivot مشروعًا إذا كان مصممًا ومصرحًا.

وقد يكون خطيرًا إذا حدث نتيجة:

• Credential مكشوفة.
• Tool Misconfiguration.
• Shared Secret.
• Delegation غير مقيدة.
• Agent-to-Agent escalation.

Privileged Machine Identity

بعض Machine Identities تمتلك صلاحيات عالية جدًا.

مثل:

• Administrator.
• Root-equivalent.
• Database Owner.
• Cloud Subscription Owner.
• Security Administrator.
• Payment Executor.

ربط Agent بهذه الهوية يحتاج إلى مستوى أعلى من الضبط والمراقبة والموافقة.

Privileged Access Management للـAgents

يمكن تطبيق مبادئ Privileged Access Management على Agents عبر:

• Just-in-Time Access.
• Temporary Credentials.
• Approval Before Elevation.
• Time-bound Privileges.
• Session Recording.
• Strong Logging.
• Automatic Revocation.
• Break-glass Controls.

الهدف هو ألا يحتفظ Agent بامتيازات عالية طوال الوقت لمجرد أنه يحتاجها في حالات محدودة.

Just-in-Time Machine Identity

بدل منح Agent Machine Identity قوية بصورة دائمة، يمكن إصدار قدرة مؤقتة عند الحاجة.

مثلًا:

Agent يحتاج إلى تنفيذ إجراء مالي حساس.

يتم:

1. التحقق من الطلب.
2. التحقق من Authority.
3. الحصول على Approval.
4. إصدار Credential قصيرة العمر.
5. تنفيذ الإجراء.
6. انتهاء Credential.

هذا يقلل مدة التعرض.

قراءة سيادة: Identity Elevation Event

تستخدم سيادة AI مفهوم Identity Elevation Event لوصف اللحظة التي ينتقل فيها Agent إلى هوية أو Session أو Credential تمنحه مستوى وصول أعلى من حالته الأساسية.

يجب أن تُسجل هذه اللحظة كحدث مستقل لأنها قد تغير Effective Access بصورة جوهرية.

Identity Drift

حتى إذا كانت هوية Agent صحيحة عند البداية، قد يتغير وضعها بمرور الوقت.

يمكن أن يحدث Identity Drift عندما:

• تُضاف Machine Identity جديدة.
• تتوسع صلاحيات Service Account.
• تتغير Roles.
• يُضاف Tenant.
• تتغير Secrets.
• يصبح الحساب مشتركًا.
• يُضاف Integration جديد.
• تتغير Delegation Rules.

قراءة سيادة: Identity Drift

تستخدم سيادة AI مصطلح Identity Drift لوصف الانحراف التدريجي بين نموذج الهوية المعتمد وبين واقع التنفيذ الحالي.

قد يبدأ Agent بهوية مخصصة ومحدودة.

ثم بعد عدة أشهر يصبح مرتبطًا بثلاثة حسابات إضافية ومجموعة أوسع من الصلاحيات دون مراجعة شاملة.

Identity Baseline

لكشف Identity Drift، تحتاج المؤسسة إلى Baseline معتمد.

يمكن أن يشمل:

• Agent Identity.
• Machine Identities.
• Credential Types.
• Environments.
• Tenants.
• Roles.
• Permissions.
• Delegation Paths.
• Owners.
• Expiration Rules.

ثم تتم مقارنة الوضع الفعلي مع هذا الأساس.

قراءة سيادة: Identity Baseline

تستخدم سيادة AI مفهوم Identity Baseline للإشارة إلى الحالة المعتمدة لهويات Agent وروابطها وصلاحياتها عند نقطة زمنية محددة.

أي انحراف جوهري عن Baseline يجب أن يكون:

• مصرحًا.
• موثقًا.
• مراجعًا.
• أو مصنفًا كDrift.

Declared Identity vs Observed Identity

قد تقول الوثائق إن Agent يستخدم Machine Identity محددة.

لكن Logs قد تظهر أنه يستخدم هويات أخرى.

لذلك يجب التمييز بين:

Declared Identity

ما تقول الوثائق إنه مستخدم.

و:

Observed Identity

ما يظهر فعليًا في التشغيل.

قراءة سيادة: Identity Reality Gap

تستخدم سيادة AI مفهوم Identity Reality Gap لوصف الفجوة بين الهويات المعلنة في التوثيق والهويات التي تظهر فعليًا في التنفيذ.

Identity Reality Gap قد يكشف:

• حسابات غير مسجلة.
• Credentials موروثة.
• Tools وسيطة.
• Shared Identities.
• مسارات وصول غير معروفة.

Identity Discovery

لا يجب الاعتماد فقط على الإدخال اليدوي لبناء Inventory للهويات.

يمكن أن تستفيد المؤسسة من:

• IAM Logs.
• API Gateway Logs.
• Cloud Audit Logs.
• Database Logs.
• Token Issuance Records.
• Secrets Managers.
• Service Account Inventories.
• Workload Identity Providers.

للكشف عن الهويات التي تعمل فعليًا.

Unknown Machine Identities

يجب التعامل مع Machine Identity غير المعروفة التي تظهر في مسار Agent كإشارة تحتاج إلى تحقيق.

الأسئلة:

• من أنشأها؟
• لماذا يستخدمها Agent؟
• ما صلاحياتها؟
• منذ متى؟
• هل هي معتمدة؟
• هل يستخدمها Agents آخرون؟
• هل يمكن تعطيلها؟

Identity Ownership

كل Agent Identity وكل Machine Identity يجب أن يكون لها Owner معروف.

لكن Ownership قد تكون متعددة الطبقات:

• Business Owner.
• Technical Owner.
• Security Owner.
• IAM Owner.
• Application Owner.

المهم أن تكون المسؤوليات محددة لا أن تبقى الهوية بلا جهة accountable.

Owner Change

عند انتقال الموظف المسؤول أو تغيير الوحدة التنظيمية، يجب تحديث ملكية Agent Identity وMachine Identities المرتبطة بها.

عدم تحديث الملكية يؤدي إلى أصول "موجودة لكن بلا مسؤول فعلي".

Identity Review

المراجعة الدورية يجب ألا تسأل فقط:

هل نحتاج هذا الحساب؟

بل أيضًا:

• هل Agent ما زال موجودًا؟
• هل الغرض ما زال نفسه؟
• هل Machine Identities الحالية ضرورية؟
• هل جميع Credentials معروفة؟
• هل هناك Shared Identity؟
• هل الصلاحيات متناسبة؟
• هل Identity Binding ما زالت صحيحة؟
• هل Owner ما زال صحيحًا؟
• هل Revocation Path معروف؟

High-Risk Identity Review

يمكن زيادة تكرار المراجعة للهويات ذات المخاطر الأعلى، مثل:

• Agents مالية.
• Agents أمنية.
• Agents تملك External Communication Authority.
• Agents تصل إلى بيانات حساسة.
• Agents تملك Privileged Access.
• Agents متعددة الأدوات.
• Agents قادرة على اتخاذ إجراءات غير قابلة للعكس.

Identity Assurance

ليس كل ادعاء بالهوية متساويًا في القوة.

Identity Assurance تتعلق بدرجة الثقة في أن الكيان الذي ينفذ هو فعلًا الهوية المسجلة.

يمكن أن تتأثر بـ:

• قوة Authentication.
• حماية Credential.
• Workload Attestation.
• Certificate Validation.
• Runtime Integrity.
• Token Binding.
• Environment Validation.

Workload Attestation

في بعض البيئات يمكن ربط إصدار الهوية بإثبات أن Workload معينة تعمل في بيئة متوقعة.

هذا يقلل احتمال استخدام Credential نفسها من مكان غير معتمد.

الهدف هو الانتقال من:

"من يملك Secret يستطيع الدخول"

إلى:

"Workload محددة في بيئة محددة تستطيع الحصول على هوية قصيرة العمر".

Runtime Identity

Agent قد يعمل داخل:

• Container.
• VM.
• Function.
• Kubernetes Pod.
• SaaS Agent Runtime.
• Endpoint.
• Edge Device.

معرفة Runtime تساعد على ربط الهوية بالبيئة التي تعمل منها.

قراءة سيادة: Runtime Identity Context

تستخدم سيادة AI مفهوم Runtime Identity Context لوصف المعلومات التي تربط Agent Identity ببيئة التشغيل الفعلية التي تستخدم Machine Identity.

قد تشمل:

• Runtime ID.
• Host.
• Container.
• Namespace.
• Region.
• Environment.
• Deployment Version.

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

Identity Spoofing

يمكن أن يحاول مهاجم أو مكون غير موثوق الظهور كأنه Agent شرعي.

قد يحدث ذلك عبر:

• سرقة Credential.
• نسخ Token.
• إساءة استخدام Service Account.
• Forged Headers.
• Fake Agent ID.
• Proxy غير موثوق.

لهذا يجب عدم الاعتماد على Agent ID المرسل كنص غير موثق.

Trusted Identity Claims

عند تمرير Agent ID أو Delegation Context بين الأنظمة، يجب أن تكون Claims قابلة للتحقق.

قد يتم ذلك عبر:

• Signed Tokens.
• Trusted Gateway.
• Mutual TLS.
• Attestation.
• Verified Metadata.
• Secure Session Context.

الهدف هو منع أي مكون من ادعاء أنه Agent آخر.

Identity Claim Provenance

من المهم معرفة مصدر Claim الهوية.

إذا وصل Header يقول:

X-Agent-ID: finance-agent

يجب أن نعرف:

• من أضافه؟
• هل يمكن للعميل تعديله؟
• هل Gateway تتحقق منه؟
• هل هو Signed؟
• هل المصدر موثوق؟

قراءة سيادة: Identity Claim Provenance

تستخدم سيادة AI مفهوم Identity Claim Provenance للإشارة إلى مصدر ادعاء الهوية وكيف تم إنشاؤه والتحقق منه عبر سلسلة التنفيذ.

Claim بدون Provenance موثوقة قد تكون مجرد نص قابل للتزوير.

Tool Identity

الأداة التي يستخدمها Agent قد تمتلك هويتها الخاصة.

مثلًا:

Agent → Tool Service → Database

قد يكون Tool Service هو الذي يملك Database Credential.

في هذه الحالة يجب التمييز بين:

Agent Identity وTool Identity وExecution Identity.

Tool-owned Credentials

إذا كانت Credentials مخزنة داخل Tool بدل Agent، فهذا قد يكون أفضل أمنيًا من إعطاء Agent السر مباشرة.

لكن ذلك لا يلغي الحاجة إلى معرفة:

• أي Agent استدعى Tool؟
• بأي Authority؟
• ماذا طلب منها؟
• بأي Machine Identity نفذت Tool؟
• ما النتيجة؟

قراءة سيادة: Identity Translation

تستخدم سيادة AI مفهوم Identity Translation لوصف انتقال الطلب من هوية إلى أخرى أثناء المرور بين مكونات النظام.

مثال:

Agent Identity → MCP Identity → ERP Service Account

كل Translation يجب أن تكون قابلة لإعادة البناء لاحقًا.

Identity Translation Risk

كلما زاد عدد عمليات Identity Translation، زادت احتمالات:

• فقدان السياق.
• توسع الصلاحيات.
• Identity Collapse.
• Attribution failure.
• Misconfigured delegation.

لهذا يجب تقليل التحويلات غير الضرورية وتسجيل الضرورية منها.

Separation of Duties في الهوية

الفصل بين المهام لا يخص البشر فقط.

يمكن تطبيقه على Agents بحيث لا يستطيع Agent واحد امتلاك كل الهويات اللازمة لدورة معاملة حساسة.

مثال:

Agent A ينشئ Payment Request.

Agent B يراجع.

Machine Identity C تنفذ بعد Approval.

هذا يقلل Authority Concentration.

Shared Administrator Identity

استخدام Administrator Service Account مشترك بين عدة Agents يمثل نمطًا عالي المخاطر.

لأنه يجمع:

• Shared Identity.
• High Privilege.
• Weak Attribution.
• Large Blast Radius.

ويجب أن يخضع لضوابط استثنائية أو يُلغى تدريجيًا.

Identity Segmentation

يمكن تقليل المخاطر عبر تقسيم Machine Identities حسب:

• Agent.
• Environment.
• Function.
• Tenant.
• Data Classification.
• Risk Level.
• Tool.
• Transaction Type.

التقسيم يجعل الإلغاء والمراجعة والتحقيق أكثر دقة.

Identity Segmentation وLeast Agency

Identity Segmentation تساعد أيضًا في تطبيق Least Agency.

بدل Machine Identity واحدة تملك كل شيء، يمكن توزيع الوصول على هويات محددة حسب المهمة.

وبهذا لا يحصل Agent تلقائيًا على كل القدرات في كل سياق.

Identity and Lethal Trifecta

تصبح مخاطر الهوية أعلى عندما يمتلك Agent:

• وصولًا إلى بيانات حساسة.
• قدرة على معالجة مدخلات غير موثوقة.
• وسيلة لتنفيذ أو إرسال مخرجات إلى أنظمة خارجية.

إذا كانت Machine Identity واسعة الصلاحيات، فإن Lethal Trifecta قد تصبح أكثر خطورة لأن Agent يمتلك قناة تقنية فعلية لتنفيذ أثر واسع.

Identity and Prompt Injection

Prompt Injection ليست مشكلة هوية في الأصل، لكنها قد تتحول إلى حادث هوية وصلاحيات إذا استطاعت تعليمات غير موثوقة دفع Agent إلى استخدام Machine Identity بصلاحياتها الكاملة.

السؤال عندها ليس فقط:

هل النموذج فهم التعليمات بصورة خاطئة؟

بل:

لماذا كانت الهوية المستخدمة قادرة على تنفيذ الأثر أصلًا؟

Identity and External Communication

Agents التي ترسل:

• بريدًا.
• رسائل.
• Posts.
• API Calls.
• Transactions.

يجب أن تكون هويتها الخارجية واضحة.

يجب معرفة:

هل الرسالة تظهر باسم موظف؟

باسم Agent؟

باسم حساب مؤسسي عام؟

هذا يؤثر في المساءلة والثقة والتدقيق.

Agent Identity in Logs

السجلات الفعالة يجب أن تحاول الاحتفاظ، حسب السياق، بعناصر مثل:

• Timestamp.
• Agent ID.
• Machine Identity.
• Execution Identity.
• Human Initiator.
• Session ID.
• Delegation ID.
• Tool.
• Resource.
• Action.
• Result.
• Authority Context.

Log Correlation

إذا كانت هذه البيانات موزعة بين عدة أنظمة، يجب وجود Correlation ID يسمح بربطها.

مثال:

Agent Log → Gateway Log → Tool Log → ERP Log

بدون Correlation يصبح التحقيق يدويًا وهشًا.

قراءة سيادة: Identity Correlation Chain

تستخدم سيادة AI مفهوم Identity Correlation Chain لوصف سلسلة السجلات التي تسمح بربط هوية Agent بالهوية التقنية وبالفعل النهائي عبر الأنظمة المختلفة.

السلسلة القوية تسمح بالإجابة:

من بدأ؟

من قرر؟

من صادق؟

من نفذ؟

بأي هوية؟

على أي مورد؟

Missing Identity Context

يجب أن تُعامل الأحداث الحساسة التي تفتقد Agent ID أو Delegation Context أو Execution Identity كأحداث ناقصة من ناحية الدليل.

قد يكون الفعل ناجحًا تقنيًا، لكن Evidence Quality ضعيفة.

Identity Evidence

أدلة الهوية قد تشمل:

• IAM Configuration.
• Identity Registry.
• Token Claims.
• Certificate Metadata.
• Service Account Mapping.
• Workload Identity Policies.
• Agent Registry.
• Audit Logs.
• Session Logs.
• Revocation Records.
• Access Reviews.

Identity Evidence Quality

قوة الدليل لا تعتمد فقط على وجود سجل، بل على:

• المصدر.
• عدم قابلية التعديل.
• التوقيت.
• اكتمال الحقول.
• Correlation.
• الاحتفاظ.
• الثقة في النظام المنتج للسجل.

Identity Testing

يجب اختبار هوية Agent بصورة عملية، مثل:

• هل يمكنه المصادقة بالهوية الصحيحة؟
• هل يفشل باستخدام Credential ملغاة؟
• هل يمكنه استخدام Identity تخص Agent آخر؟
• هل يمكنه العمل من Environment غير مسموحة؟
• هل Logs تسجل Agent ID؟
• هل Tenant Context صحيح؟
• هل Session تُلغى عند التعطيل؟

Negative Identity Testing

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

مثل:

• Agent A لا يستطيع استخدام Machine Identity الخاصة بـAgent B.
• Dev Agent لا يستطيع استخدام Production Credential.
• Credential منتهية لا تعمل.
• Agent متقاعد لا يستطيع الحصول على Session جديدة.
• Cross-Tenant token تُرفض.
• Shared Identity غير معتمدة تُكتشف.

قراءة سيادة: Identity Denial Evidence

تستخدم سيادة AI مفهوم Identity Denial Evidence لوصف الدليل الذي يثبت أن محاولة استخدام هوية أو Credential خارج السياسة قد تم رفضها فعليًا.

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

Identity Monitoring

المراقبة المستمرة يمكن أن تبحث عن:

• Machine Identity جديدة.
• Login من Runtime غير معتادة.
• Credential قديمة.
• Shared Identity Usage.
• Sudden Privilege Expansion.
• Cross-Tenant Access.
• Identity Pivot.
• Failed Revocation.
• Unknown Agent IDs.

Behavioral Identity Signals

يمكن أيضًا مراقبة أنماط الاستخدام.

مثلًا:

Machine Identity اعتادت قراءة البيانات فقط ثم بدأت تنفيذ حذف.

قد لا يكون هناك تغيير في IAM، لكن الاستخدام نفسه تغير.

هذا قد يشير إلى:

• Agent Behavior Change.
• Prompt Injection.
• Misconfiguration.
• Credential Misuse.
• New Tool Path.

Identity Change Monitoring

أي تغيير في:

• Roles.
• Credentials.
• Machine Identity.
• Owner.
• Tenant.
• Environment.
• Delegation.
• Privilege.

يجب أن يكون قابلًا للرصد وربطه بـChange Request أو Approval مناسب.

Identity Expiration

قد يكون من المفيد أن تحتوي بعض روابط الهوية على Expiration بدل أن تبقى بلا نهاية.

مثل:

• Temporary Integration.
• Pilot Agent.
• Vendor Agent.
• Project-based Agent.
• Elevated Access.

الوصول الذي لا يحتاج إلى استمرار دائم لا يجب أن يصبح دائمًا بالصدفة.

Dormant Identities

Machine Identity لم تُستخدم منذ فترة طويلة قد تكون:

• غير ضرورية.
• منسية.
• مرتبطة بـAgent متقاعد.
• احتياطية.
• خطيرة إذا بقيت نشطة.

يجب مراجعة Dormant Identities دوريًا.

Identity Retirement

عند تقاعد Agent يجب تنفيذ عملية منظمة تشمل:

• تغيير Status.
• تعطيل Agent Runtime.
• إنهاء Sessions.
• إلغاء Credentials.
• تعطيل Machine Identities غير المشتركة.
• إزالة Roles.
• فك Delegations.
• تحديث Registry.
• الاحتفاظ بالأدلة اللازمة.
• التحقق من عدم وجود Access Paths متبقية.

Retirement Verification

لا يكفي الضغط على Delete.

يجب إثبات أن Agent لم يعد قادرًا على:

• المصادقة.
• استخدام Tools.
• إصدار Requests.
• الوصول إلى البيانات.
• استخدام Credentials قديمة.
• العمل عبر Proxy أو Service Account.

قراءة سيادة: Identity Closure

تستخدم سيادة AI مفهوم Identity Closure لوصف الحالة التي تكون فيها دورة حياة هوية Agent قد أُغلقت فعليًا، وليس إداريًا فقط.

Identity Closure تعني عدم وجود مسارات هوية أو Credential أو Session متبقية تسمح باستمرار العمل بعد التقاعد.

الحد الأدنى لسجل Machine Identity

يمكن أن يحتوي سجل Machine Identity على:

• Machine Identity ID.
• Type.
• Provider.
• Agent Binding.
• Owner.
• Environment.
• Tenant.
• Authentication Method.
• Credential Type.
• Roles.
• Effective Access.
• Creation Date.
• Expiration.
• Rotation Policy.
• Last Rotation.
• Revocation Method.
• Status.

الحد الأدنى لسجل Agent Identity

أما Agent Identity Registry فيمكن أن يحتوي على:

• Agent ID.
• Name.
• Purpose.
• Owner.
• Business Unit.
• Risk Tier.
• Environment.
• Tenant.
• Model/System Version.
• Machine Identities.
• Tools.
• Effective Access.
• Agent Authority.
• Human Oversight.
• Kill Switch.
• Last Review.
• Status.

الأسئلة التي يجب أن يستطيع الفريق الإجابة عنها

قبل تشغيل Agent بصلاحيات مؤثرة، يجب أن يستطيع الفريق الإجابة بوضوح:

1. ما Agent ID؟
2. من المالك؟
3. ما Machine Identities المرتبطة به؟
4. ما Credentials المستخدمة؟
5. هل هناك Shared Identity؟
6. ما Environment وTenant؟
7. ما Effective Access؟
8. ما Agent Authority؟
9. هل توجد Privileged Identity؟
10. هل هناك Agent-to-Agent delegation؟
11. كيف يتم Rotation؟
12. كيف يتم Revocation؟
13. ما Execution Identity؟
14. أين توجد Logs؟
15. كيف نغلق الهوية عند Retirement؟

إذا كانت عدة إجابات "غير معروف"، فمشكلة الهوية ليست تقنية صغيرة؛ بل فجوة مباشرة في الحوكمة والمساءلة.

كيف تبدو Identity Architecture ناضجة لوكلاء الذكاء الاصطناعي؟

العمارة الناضجة لا تعتمد على حساب تقني واحد ثم تفترض أن بقية عناصر الحوكمة ستُفهم تلقائيًا.

بل تربط بين عدة طبقات:

Agent Registry → Agent Identity → Machine Identity → Credential → Authentication → Authorization → Effective Access → Agent Authority → Tool Invocation → Execution Identity → Audit Evidence

كل طبقة تجيب عن سؤال مختلف.

وأي محاولة لاختزال هذه الطبقات في مفهوم واحد قد تخلق فجوة في التحكم أو المساءلة.

طبقة Agent Registry

Agent Registry هي الطبقة التي تعرف المؤسسة من خلالها الوكلاء الموجودين أصلًا.

يجب أن تسمح على الأقل بمعرفة:

• Agent ID.
• الاسم.
• الغرض.
• المالك.
• Business Unit.
• Environment.
• Tenant.
• Risk Tier.
• Status.
• Machine Identities.
• Tools.
• Authority Profile.
• Last Review.

بدون Registry موثوقة، قد يصبح السؤال "كم Agent لدينا؟" نفسه صعب الإجابة.

طبقة IAM

IAM تدير الهويات التقنية وعلاقات الوصول.

لكن IAM وحدها قد تعرف:

svc-agent-prod-04

دون أن تعرف أن هذه الهوية تخص:

procurement-agent-01

ومن هنا تظهر أهمية ربط IAM بالـAgent Registry.

طبقة PAM

إذا كان Agent يحتاج إلى Privileged Access، يجب ألا تتحول الصلاحية العالية إلى حالة افتراضية دائمة.

يمكن استخدام ضوابط مثل:

• Just-in-Time privilege.
• Approval.
• Time-bound elevation.
• Credential brokering.
• Session monitoring.
• Automatic expiration.
• Emergency revocation.

الهدف هو تقليل الزمن الذي تكون فيه الهوية ذات امتياز مرتفع.

طبقة Secrets Management

Credentials الحساسة يجب ألا تكون مبعثرة في:

• Source Code.
• Prompt Templates.
• Environment Files.
• Notebooks.
• Scripts.
• Shared Documents.

يفضل استخدام آليات مخصصة لإدارة Secrets مع:

• Access Policies.
• Rotation.
• Versioning.
• Audit Logs.
• Expiration.
• Revocation.

طبقة Policy Enforcement

حتى إذا عرفت المؤسسة Agent Identity وMachine Identity، فهي تحتاج إلى نقطة يمكن عندها تطبيق السياسة فعليًا.

مثلًا:

• API Gateway.
• IAM Policy Engine.
• Tool Gateway.
• Transaction Service.
• MCP Gateway.
• Workflow Engine.

هذه النقطة يجب أن تكون قادرة على اتخاذ قرار اعتمادًا على هوية موثوقة وليس على اسم يرسله Agent بنفسه.

Zero Trust وAgent Identity

يناسب نموذج Zero Trust بيئات الوكلاء لأن مجرد وجود Agent داخل شبكة المؤسسة لا يعني أنه يجب أن يكون موثوقًا تلقائيًا.

المبدأ العملي هو:

لا تعتمد على موقع Agent وحده.

تحقق من:

• Identity.
• Device أو Runtime Context.
• Environment.
• Tenant.
• Requested Resource.
• Requested Action.
• Authority.
• Risk.
• Session Freshness.

ثم امنح الحد الأدنى المطلوب.

Never Trust, Always Verify لا تعني إعادة تسجيل الدخول فقط

في الأنظمة الوكيلية، التحقق المستمر يمكن أن يشمل إعادة تقييم:

• هل Agent ما زال Active؟
• هل Machine Identity ما زالت مرتبطة به؟
• هل Authority ما زالت صالحة؟
• هل Session قديمة؟
• هل Risk Level تغير؟
• هل العملية الحالية أعلى حساسية من العمليات السابقة؟

إعادة التحقق هنا تتجاوز Authentication الأولية.

قراءة سيادة: Identity Context Verification

تستخدم سيادة AI مفهوم Identity Context Verification لوصف التحقق من أن هوية Agent لا تزال صالحة ضمن السياق التشغيلي الحالي، وليس فقط أنها اجتازت Authentication في وقت سابق.

يمكن أن يتضمن ذلك:

Agent + Environment + Tenant + Runtime + Authority + Session + Resource + Risk

قبل السماح بالفعل.

Identity-aware Policy

السياسة الجيدة لا تقول فقط:

"هذه API مسموحة."

بل يمكن أن تقول:

"يسمح لـAgent معين، باستخدام Machine Identity محددة، داخل Production Tenant محدد، بتنفيذ Action معينة ضمن Authority معينة."

كلما كانت السياسة أقرب إلى السياق الحقيقي، قل الاعتماد على صلاحيات عامة واسعة.

Policy Decision وPolicy Enforcement

من المفيد الفصل بين:

Policy Decision Point

الذي يقرر هل الطلب مسموح.

و:

Policy Enforcement Point

الذي يمنع أو يسمح بالفعل تقنيًا.

يمكن أن يوجد القرار في Policy Engine بينما التنفيذ في API Gateway أو Tool Gateway.

قراءة سيادة: Identity Decision Point

تستخدم سيادة AI مفهوم Identity Decision Point للإشارة إلى النقطة التي يتم عندها تقييم هوية Agent وسياقها قبل منح مسار التنفيذ.

قد يشمل القرار:

• صحة Agent Identity.
• صحة Machine Identity.
• صحة Binding.
• Tenant.
• Environment.
• Session.
• Delegation.
• Risk.

قراءة سيادة: Identity Enforcement Point

تستخدم سيادة AI مفهوم Identity Enforcement Point للإشارة إلى النقطة التقنية التي تمنع استخدام الهوية أو الوصول عندما تفشل شروط الهوية أو السياق.

وجود قرار حوكمي بدون Enforcement فعلي لا يكفي.

Agent Identity وLeast Agency

Least Agency لا يتعلق فقط بعدد الأدوات التي يمتلكها Agent.

بل أيضًا بعدد الهويات والصلاحيات التي يستطيع استخدامها.

Agent لديه:

• خمس Machine Identities.
• ثلاث Credentials مميزة.
• Admin Tool.
• Production Session.

يمتلك سطح قدرة أكبر من Agent يعمل بهوية واحدة محدودة.

لذلك تقليل الهوية الزائدة جزء من تقليل Agency.

قراءة سيادة: Minimum Identity Surface

تستخدم سيادة AI مفهوم Minimum Identity Surface لوصف أقل مجموعة من الهويات التقنية وCredentials والروابط التي يحتاجها Agent لأداء مهمته بكفاءة.

الهدف ليس تقليل الهويات إلى رقم اعتباطي، بل إزالة المسارات غير اللازمة.

Identity Surface

يمكن تعريف Identity Surface عمليًا بأنها مجموعة الهويات وCredentials والجلسات ومسارات Delegation التي يستطيع Agent استخدامها أثناء التشغيل.

كل عنصر إضافي قد يمثل:

• Access Path.
• Escalation Path.
• Persistence Path.
• Audit Complexity.

Agent Identity وAuthority Envelope

يمكن استخدام Identity كجزء من Authority Envelope.

مثال:

قد تكون عملية مالية مسموحة فقط عندما:

• Agent ID = finance-agent-prod.
• Machine Identity = workload-finance-prod.
• Environment = production.
• Tenant = company-a.
• Transaction Value < threshold.
• Human Approval موجود.

إذا تغيرت الهوية المستخدمة، يجب أن يفشل التنفيذ حتى لو كان Action نفسه مسموحًا في ظروف أخرى.

قراءة سيادة: Identity-bound Authority

تستخدم سيادة AI مفهوم Identity-bound Authority لوصف Authority لا تكون صالحة بصورة مجردة، بل تكون مرتبطة بهوية Agent أو Machine Identity أو سياق هوية محدد.

وهذا يقلل احتمال انتقال Authority تلقائيًا إلى هوية أخرى لمجرد أنها تمتلك Permissions مشابهة.

Identity وTransaction Authority

في المعاملات الحساسة، يجب معرفة من أنشأ ومن وافق ومن نفذ.

قد تكون الطبقات:

Creator Agent Identity → Reviewer Identity → Approver Identity → Execution Identity

وجود هذه الهويات منفصلة يساعد على تطبيق Separation of Duties.

Identity وHuman Oversight

الموافقة البشرية لا تكون مفيدة إذا لم نعرف:

• من طلب الموافقة؟
• لأي Agent؟
• لأي Action؟
• بأي Machine Identity سيتم التنفيذ؟
• هل الهوية تغيرت بعد الموافقة؟

لذلك يجب ربط Approval بسياق هوية محدد.

قراءة سيادة: Approval-to-Identity Binding

تستخدم سيادة AI مفهوم Approval-to-Identity Binding لوصف ربط موافقة بشرية بهوية Agent والسياق التنفيذي الذي تم اعتماده.

إذا تغيرت Machine Identity أو Resource أو Authority بعد الموافقة، فقد يلزم إعادة التقييم بدل استخدام Approval قديمة لسياق جديد.

Identity وKill Switch

Kill Switch الفعالة يجب أن تعرف ماذا ستعطل.

قد يكون تعطيل Agent Runtime وحده غير كافٍ.

يمكن أن تحتاج الاستجابة إلى:

• Suspend Agent Identity.
• Disable Machine Identity.
• Revoke Credentials.
• Terminate Sessions.
• Remove Tool Access.
• Disable Delegations.
• Block API Client.
• Verify denial.

قراءة سيادة: Identity Kill Chain

تستخدم سيادة AI مفهوم Identity Kill Chain لوصف تسلسل إيقاف قدرة Agent على العمل من زاوية الهوية.

مثل:

Agent Disable → Machine Identity Disable → Credential Revoke → Session Terminate → Delegation Revoke → Access Verification

المقصود هنا "سلسلة إيقاف الهوية" وليس استخدام المصطلح بمعناه الهجومي في سياقات أخرى.

هل يمكن إيقاف Agent واحد دون إيقاف البقية؟

هذا سؤال معماري مهم.

إذا كانت خمسة Agents تستخدم Service Account نفسها، فقد يصبح من الصعب تعطيل Agent واحد على مستوى النظام الهدف دون التأثير على الآخرين.

هذه إحدى تكاليف Shared Identity التي لا تظهر عند التصميم الأولي.

قراءة سيادة: Selective Revocability

تستخدم سيادة AI مفهوم Selective Revocability لوصف قدرة المؤسسة على سحب هوية أو وصول Agent معين دون تعطيل وكلاء أو خدمات غير مرتبطة بالحادث.

كلما زادت مشاركة الهوية، قلت القدرة على الإلغاء الانتقائي.

Identity Incident Response

عند وقوع حادث يتعلق بـAgent، يجب أن يكون لدى فريق الاستجابة مسار سريع للإجابة عن:

• ما Agent Identity؟
• ما Machine Identities؟
• ما Credentials؟
• ما Sessions النشطة؟
• ما Systems التي تم الوصول إليها؟
• ما Actions التي نُفذت؟
• هل حصل Identity Pivot؟
• هل توجد Delegations؟
• ما Effective Access الحالي؟
• كيف نوقفه؟

أول دقائق الحادث

في حادث هوية، قد تكون الإجراءات الأولى:

1. تحديد Agent المتأثر.
2. حفظ الأدلة.
3. إيقاف Session أو Agent عند الحاجة.
4. سحب Credential المشتبه بها.
5. منع إعادة إصدار Tokens.
6. فحص Machine Identities المرتبطة.
7. التحقق من Agents أخرى تستخدم الهوية نفسها.
8. تحديد آخر أفعال منفذة.

لا تسحب Credential قبل حفظ الأدلة دون تفكير

قد تحتاج بعض الحوادث إلى إجراء فوري، لكن من منظور التحقيق يجب الانتباه إلى أن التغييرات نفسها قد تمحو أو تغير معلومات مهمة.

لهذا يجب أن تكون Incident Playbooks مصممة مسبقًا لتحقيق توازن بين:

Containment وEvidence Preservation.

Identity Forensics

التحقيق الجنائي في حادث Agent قد يحتاج إلى جمع:

• Authentication Logs.
• Token Issuance Logs.
• Session Records.
• Agent Logs.
• Tool Calls.
• Gateway Logs.
• Target System Logs.
• Credential Rotation History.
• IAM Change History.
• Deployment History.
• Approval Records.

قراءة سيادة: Identity Evidence Chain

تستخدم سيادة AI مفهوم Identity Evidence Chain لوصف مجموعة الأدلة المترابطة التي تسمح بإثبات انتقال العملية من Agent إلى Machine Identity ثم إلى النظام الهدف.

السلسلة الجيدة لا تعتمد على Log واحدة فقط.

Attribution بعد الحادث

الهدف من الهوية ليس فقط منع الهجوم.

بل أيضًا أن تستطيع المؤسسة لاحقًا تحديد:

• من بدأ العملية.
• أي Agent كان يعمل.
• بأي إصدار.
• بأي Machine Identity.
• بأي Credential.
• ما Authority.
• ما Tool.
• ما Action.
• ما Result.

عندما لا تستطيع المؤسسة Attribution

إذا انتهى التحقيق إلى:

"نعرف أن الحساب المشترك نفذ العملية، لكن لا نعرف أي Agent استخدمه"

فهذه ليست فقط مشكلة Logging.

إنها مؤشر على ضعف في Identity Architecture نفسها.

Audit of Agent Identity

التدقيق على هوية Agents يجب ألا يقتصر على البحث عن قائمة الحسابات.

يمكن للمراجع فحص:

• Completeness of Agent Registry.
• Unique IDs.
• Owner Assignment.
• Machine Identity Mapping.
• Shared Identity Exceptions.
• Credential Lifecycle.
• Privileged Identities.
• Delegation.
• Revocation.
• Logging.
• Retirement.

أسئلة تدقيق عملية

يمكن للمراجع أن يسأل:

• أعطني قائمة Agents النشطة.
• أعطني Machine Identities لكل Agent.
• أين يتم تسجيل Binding؟
• ما الحسابات المشتركة؟
• ما الاستثناءات المعتمدة؟
• متى كانت آخر Access Review؟
• ما Credentials طويلة العمر؟
• كيف يتم Rotation؟
• هل يمكن تعطيل Agent واحد؟
• أرني دليلًا على Revocation ناجحة.
• أرني عملية فعلية واربط Agent بالExecution Identity.

Evidence وليس Policy فقط

وجود وثيقة تقول:

"لكل Agent هوية منفصلة"

ليس دليلًا كافيًا.

يجب أن يستطيع الفريق تقديم Evidence مثل:

• Registry export.
• IAM configuration.
• Authentication logs.
• Workload identity mapping.
• Token claims.
• Test results.

Configuration Evidence

Configuration Evidence توضح كيف يفترض أن يعمل النظام.

مثل:

• IAM Policy.
• Service Account Mapping.
• Workload Binding.
• Token Configuration.

لكنها لا تثبت وحدها ما حدث فعليًا.

Operational Evidence

Operational Evidence تأتي من التشغيل الحقيقي.

مثل:

• Authentication event.
• Tool call.
• API request.
• Execution log.
• Denied request.
• Session termination.

ويفضل الجمع بين Configuration Evidence وOperational Evidence.

قراءة سيادة: Identity Assurance Evidence

تستخدم سيادة AI مفهوم Identity Assurance Evidence لوصف الأدلة التي تثبت أن هوية Agent ليست مسجلة فقط، بل يتم التحقق منها وربطها وتنفيذ سياساتها في التشغيل الفعلي.

اختبار End-to-End للهوية

اختبار الهوية الناضج يمكن أن يبدأ بطلب بشري ثم يتتبع السلسلة كاملة:

Human → Agent → Machine Identity → Credential → Tool → Execution Identity → Resource → Audit Record

ويجب التأكد من أن Correlation تسمح بربط المراحل.

اختبار Shared Identity

إذا كانت هناك Shared Identity مستثناة، يجب اختبار:

• هل Agent ID محفوظ؟
• هل يمكن فصل أفعال Agents؟
• هل Revocation ممكنة؟
• هل Logs موثوقة؟
• هل Permissions أقل ما يمكن؟
• هل هناك خطة لإزالة المشاركة؟

اختبار Identity Pivot

يجب اختبار ما إذا كان Agent يستطيع الوصول إلى Machine Identity أخرى غير المسموح بها.

مثل:

• قراءة Secret خاص بخدمة أخرى.
• استدعاء Tool بامتياز أعلى.
• استخدام Token من Agent آخر.
• الوصول إلى Cloud Metadata غير المقصودة.

اختبار Impersonation

يمكن اختبار ما إذا كان Agent يستطيع:

• إرسال Agent ID مزيفة.
• تعديل Delegation ID.
• ادعاء Tenant مختلف.
• استخدام User Context لا يخصه.
• إعادة استخدام Token خارج سياقه.

الهدف هو إثبات أن الهوية ليست مجرد Metadata قابلة للتغيير.

اختبار Revocation

الاختبار يجب أن يثبت:

قبل الإلغاء → Access تعمل.

بعد الإلغاء → Access تفشل.

وإذا بقيت Session قديمة تعمل، فهناك فجوة يجب معالجتها.

اختبار Retirement

بعد Retirement يجب التحقق من:

• Agent لا يعمل.
• Machine Identity معطلة أو مفصولة.
• Credentials غير صالحة.
• Sessions منتهية.
• Delegations ملغاة.
• Roles أزيلت.
• لا توجد Access Paths بديلة.

Control Matrix لهوية الوكلاء

يمكن للمؤسسة بناء Control Matrix مبسطة مثل:

مستويات نضج هوية الوكلاء

يمكن للمؤسسة النظر إلى النضج على خمس درجات تشغيلية.

المستوى 0: Unknown

في هذا المستوى:

• لا يوجد Agent Registry موثوق.
• Machine Identities غير معروفة بالكامل.
• Shared Credentials شائعة.
• Attribution ضعيفة.

السؤال "أي Agent نفذ؟" قد لا تكون له إجابة موثوقة.

المستوى 1: Registered

توجد قائمة Agents أساسية.

تم تحديد:

• Agent ID.
• Owner.
• بعض Machine Identities.

لكن الربط والتدقيق ما زالا يدويين.

المستوى 2: Bound

أصبحت العلاقة بين Agent Identity وMachine Identity موثقة.

وتوجد:

• Credential ownership.
• Environment binding.
• Tenant context.
• Access reviews.

لكن Enforcement قد لا يكون ديناميكيًا.

المستوى 3: Enforced

أصبحت سياسات الهوية تطبق تقنيًا عبر:

• IAM.
• Gateways.
• Short-lived credentials.
• Privileged controls.
• Delegation policies.
• Revocation.

وتصبح Shared Identity استثناءً لا قاعدة.

المستوى 4: Assured

توجد مراقبة واختبارات وأدلة مستمرة تشمل:

• Identity Drift.
• Observed identities.
• Denial Evidence.
• End-to-end correlation.
• Revocation tests.
• Retirement verification.

هنا تتحول الهوية من Configuration إلى Control قابل للإثبات.

قراءة سيادة: Agent Identity Maturity

تستخدم سيادة AI هذا التسلسل التشغيلي:

Unknown → Registered → Bound → Enforced → Assured

كنموذج مبسط لتقييم نضج إدارة هوية Agents داخل المؤسسة.

ليس هذا تصنيفًا رسميًا من PCI SSC، بل صياغة تشغيلية تستخدمها سيادة لتنظيم التقييم.

حالة عملية: وكيل المشتريات

لنفترض وجود:

procurement-agent-prod

وله:

Agent Identity مستقلة.

Machine Identity:

wl-procurement-prod

ويستخدم Tool للوصول إلى ERP.

المطلوب أن نعرف:

• هل Workload Identity مخصصة له؟
• هل Tool تنفذ بهوية أخرى؟
• ما Effective Access؟
• هل يستطيع إنشاء Purchase Order؟
• هل يستطيع اعتمادها؟
• هل Approval مرتبطة بالAgent؟
• هل Logs في ERP يمكن ربطها بالAgent؟

سيناريو جيد في المشتريات

يمكن أن تكون السلسلة:

Employee → Procurement Agent → Dedicated Workload Identity → Procurement Tool → ERP Restricted Identity → Purchase Draft

ثم إذا تجاوزت العملية حدًا معينًا:

Human Approval → Temporary Execution Authority → Transaction

كل مرحلة تحمل Correlation واضحًا.

سيناريو ضعيف في المشتريات

Agent يستخدم:

erp_admin_shared

وهو الحساب نفسه الذي تستخدمه عدة Automations.

في هذه الحالة قد يستطيع Agent:

• القراءة.
• التعديل.
• الاعتماد.
• الحذف.

بينما سجل ERP يعرض نفس الحساب لكل شيء.

هنا تتجمع:

Shared Identity + Excessive Privilege + Weak Attribution + Large Blast Radius.

حالة عملية: وكيل مالي

وكيل مالي يجهز دفعات لكنه لا يجب أن ينفذ التحويل منفردًا.

Identity Architecture يمكن أن تدعم الفصل بحيث:

Agent Identity تملك Authority لإعداد المعاملة.

Machine Identity الأساسية لا تملك Payment Execution.

بعد Human Approval، يتم إنشاء قدرة تنفيذ قصيرة العمر لمسار محدد.

حالة عملية: وكيل الأمن السيبراني

Security Agent قد يحتاج إلى:

• قراءة Logs.
• عزل Endpoint.
• تعطيل Account.
• تعديل Firewall Rule.

هذه صلاحيات شديدة الحساسية.

لذلك قد يكون من غير المقبول ربطه بـAdministrator Identity دائمة.

الأفضل فصل:

Read Identity وResponse Identity

ورفع الامتياز فقط عندما تكون شروط الاستجابة مستوفاة.

حالة عملية: وكيل الموارد البشرية

HR Agent قد يتعامل مع بيانات شديدة الحساسية.

حتى إذا كانت Machine Identity مخصصة له، يجب التحقق من:

• Scope.
• Tenant.
• Data Classification.
• Purpose.
• Logging.
• External Communication.
• Human Oversight.

الهوية وحدها لا تجعل الاستخدام مشروعًا.

حالة عملية: وكيل قانوني

Legal Agent قد يصل إلى مستندات سرية ثم يستخدم Tool خارجية لتحليلها.

هنا يجب فهم أي Identity تستخدمها Tool الخارجية، وما إذا كان Agent يرسل البيانات تحت سياق أو Account مشترك.

Identity Governance يجب أن تمتد إلى سلسلة الأدوات، لا أن تتوقف عند أول Agent.

حالة عملية: Agent يعمل عبر MCP

السلسلة قد تكون:

User → Agent → MCP Client → MCP Server → SaaS API

الأسئلة المهمة:

• ما Agent ID؟
• كيف يثبت نفسه للـMCP Server؟
• هل Server يميز Agents؟
• بأي Identity يتصل SaaS؟
• هل User Context محفوظ؟
• ما Correlation ID؟
• أين يتم Enforcement؟

حالة عملية: Agent-to-Agent Workflow

Agent A يقوم بتحليل طلب.

Agent B ينفذ عملية.

Agent C يرسل نتيجة إلى طرف خارجي.

هنا نحتاج إلى سلسلة:

Initiator → Agent A → Delegation → Agent B → Delegation → Agent C → External Action

يجب ألا يتحول Workflow كله في النهاية إلى حساب مشترك واحد.

أخطاء شائعة: اعتبار Agent Name هو الهوية

اسم ظاهر في UI لا يكفي كهوية مؤسسية.

يجب أن يوجد ID ثابت وقابل للتتبع.

أخطاء شائعة: مساواة Service Account بالAgent

Service Account قد تكون Machine Identity، لكنها لا تمثل بالضرورة Agent Identity نفسها.

أخطاء شائعة: مساواة Credential بالهوية

API Key أو Token هي وسيلة إثبات، وليست الكيان ذاته.

أخطاء شائعة: استخدام حساب واحد لكل Agents

هذا يقلل العمل الإداري في البداية لكنه يضعف:

• Attribution.
• Revocation.
• Least Agency.
• Incident Response.

أخطاء شائعة: تجاهل Identity Translation

إذا انتقلت العملية من Agent إلى Tool ثم إلى Proxy ثم إلى نظام هدف، يجب معرفة كيف تغيرت الهوية في كل مرحلة.

أخطاء شائعة: الاحتفاظ بCredentials طويلة العمر

Credential ثابتة قد تستمر سنوات حتى بعد تغير وظيفة Agent.

أخطاء شائعة: عدم ربط الهوية بالبيئة

Credential إنتاجية لا يجب أن تصبح قابلة للاستخدام من Agent تجريبي.

أخطاء شائعة: عدم ربط الهوية بالTenant

هذا قد يؤدي إلى وصول عابر للمستأجرين.

أخطاء شائعة: الاعتماد على Header غير موثوق

Agent ID داخل Header لا يكفي ما لم يكن مصدره موثوقًا أو قابلًا للتحقق.

أخطاء شائعة: إغلاق Agent من التطبيق فقط

تعطيل Agent UI أو Runtime لا يعني أن Machine Identities وSessions وCredentials أُلغيت.

أخطاء شائعة: عدم اختبار الفشل

نجاح Authentication ليس الاختبار الوحيد.

يجب اختبار:

• Credential منتهية.
• Identity غير مصرح بها.
• Tenant خاطئ.
• Environment خاطئة.
• Agent متقاعد.
• Delegation غير صالحة.

أخطاء شائعة: تسجيل Machine Identity دون Agent Context

Log تقول:

svc-prod-agent executed transaction

قد تكون غير كافية إذا كان الحساب يستخدمه عدة Agents.

أخطاء شائعة: منح Agent كامل صلاحيات المستخدم

On-Behalf-Of لا تعني نسخ كل صلاحيات المستخدم إلى Agent.

أخطاء شائعة: عدم إعادة تقييم الهوية بعد التغيير

إضافة Machine Identity جديدة قد تغير Effective Access بصورة كبيرة حتى لو لم يتغير Agent نفسه.

أخطاء شائعة: عدم ربط Approval بالهوية

موافقة لAgent A لا ينبغي أن تُستخدم تلقائيًا لتنفيذ العملية عبر Agent B أو Machine Identity مختلفة.

أخطاء شائعة: ترك Orphan Identities

إيقاف Agent دون تنظيف الهويات المرتبطة به يترك مسارات وصول غير ضرورية.

Checklist قبل تشغيل Agent

قبل التشغيل، تحقق من:

• Agent ID فريدة.
• Owner معروف.
• Purpose واضح.
• Environment محددة.
• Tenant محدد.
• Machine Identities مسجلة.
• Identity Binding موثقة.
• Credentials معروفة.
• Shared Identity مبررة أو غير موجودة.
• Effective Access معروف.
• Authority موثقة.
• Revocation Path معروف.
• Logging مفعّل.
• Correlation موجودة.
• Retirement Process محددة.

Checklist للهويات ذات الامتياز

إذا كانت Machine Identity عالية الامتياز، أضف:

• PAM.
• Just-in-Time Access.
• Short-lived Credential.
• Approval.
• Session Monitoring.
• Automatic Expiration.
• Strong Audit.
• Emergency Revocation.
• Negative Testing.

Checklist لمراجعة دورية

اسأل دوريًا:

• هل Agent ما زال مطلوبًا؟
• هل Owner ما زال صحيحًا؟
• هل Machine Identities تغيرت؟
• هل ظهرت Observed Identities غير مسجلة؟
• هل Permissions توسعت؟
• هل توجد Credentials قديمة؟
• هل توجد Dormant Identities؟
• هل ظهرت Shared Identity؟
• هل تغير Tenant أو Environment؟
• هل Revocation ما زالت تعمل؟
• هل Logs قابلة للربط؟

Checklist عند تغيير Agent

أي تغيير مهم يجب أن يعيد فحص الهوية إذا شمل:

• Runtime.
• Tool.
• Model Hosting.
• Environment.
• Tenant.
• Machine Identity.
• Credential.
• Delegation.
• Access.
• Authority.

Checklist عند التقاعد

لا تعتبر Agent متقاعدًا حتى يتم:

• Suspend Agent.
• Terminate Sessions.
• Revoke Credentials.
• Disable or detach Machine Identities.
• Remove Roles.
• Remove Delegations.
• Update Registry.
• Retain required evidence.
• Verify failed access.

ما الذي يجب قياسه؟

يمكن للمؤسسة بناء مؤشرات مثل:

• نسبة Agents ذات هوية فريدة.
• نسبة Agents ذات Owner معروف.
• نسبة Machine Identities المربوطة بـAgent معروف.
• عدد Shared Machine Identities.
• عدد Long-Lived Credentials.
• عدد Orphan Identities.
• عدد Unknown Identities المكتشفة.
• نسبة Revocation Tests الناجحة.
• نسبة Agents ذات End-to-End Correlation.
• عدد Identity Drift findings.

قراءة سيادة: Identity Coverage

تستخدم سيادة AI مفهوم Identity Coverage لوصف نسبة Agents التشغيلية التي يمكن للمؤسسة ربطها بصورة موثوقة بهوية منطقية وهوية تقنية ومالك ومسار تنفيذ.

الهدف ليس مجرد الوصول إلى 100% في قاعدة بيانات، بل إلى تغطية حقيقية يمكن إثباتها تشغيليًا.

قراءة سيادة: Identity Traceability

تستخدم سيادة AI مفهوم Identity Traceability لوصف قدرة المؤسسة على تتبع الفعل من النظام الهدف إلى Execution Identity ثم Machine Identity ثم Agent Identity والسياق الذي بدأ العملية.

يمكن النظر إليها عكسيًا:

Action → Execution Identity → Machine Identity → Agent Identity → Initiator

قراءة سيادة: Identity Control Plane

تستخدم سيادة AI مفهوم Identity Control Plane لوصف مجموعة الأنظمة والسياسات والسجلات التي تتحكم في هويات Agents وتربطها بالتنفيذ.

قد يشمل:

• Agent Registry.
• IAM.
• PAM.
• Secrets Manager.
• Policy Engine.
• Gateway.
• Audit Logs.
• Revocation Service.

هو ليس منتجًا واحدًا بالضرورة، بل طبقة تحكم مؤسسية مترابطة.

من يملك Identity Control Plane؟

قد تشترك عدة جهات في المسؤولية:

• IAM Team.
• Cybersecurity.
• AI Platform Team.
• Application Owners.
• AI Governance.
• Risk.
• Internal Audit.

لكن تعدد الفرق لا يجب أن يؤدي إلى غياب Accountability.

Agent Owner ليس IAM Owner

مالك Agent مسؤول عن الغرض والاستخدام.

IAM Owner مسؤول عن البنية التقنية للهوية.

Security قد تضع الضوابط.

Governance قد تحدد Authority.

Audit يتحقق من Evidence.

هذه مسؤوليات مترابطة لكنها ليست متطابقة.

RACI لهوية الوكيل

يمكن للمؤسسة تعريف RACI تغطي:

• إنشاء Agent Identity.
• إنشاء Machine Identity.
• إصدار Credential.
• تحديد Permissions.
• اعتماد Authority.
• مراجعة Access.
• Rotation.
• Revocation.
• Incident Response.
• Retirement.

الهدف هو منع الحالة التي يعرف فيها الجميع أن Agent موجود لكن لا أحد يملك قرار تعطيله.

الهوية والمورد الخارجي

إذا كان Agent يستخدم SaaS أو Vendor Platform، يجب السؤال:

• هل Vendor يوفر Machine Identity مخصصة؟
• أم Account مشتركة؟
• هل يدعم SSO أو OAuth؟
• هل Logs متاحة؟
• هل يمكن إلغاء Token؟
• هل يمكن معرفة Agent الأصلي؟
• هل يوجد Tenant Isolation؟

Vendor-managed Identity

قد تكون بعض Machine Identities تحت سيطرة Vendor.

هذا لا يلغي مسؤولية المؤسسة عن معرفة:

• من أصدرها.
• لمن تخص.
• ما صلاحياتها.
• كيف تُلغى.
• ما Logs المتاحة.
• ما يحدث عند إنهاء العقد.

Third-party Agent Identity

إذا كان Vendor يشغل Agent نيابة عن المؤسسة، يجب ألا يختفي Agent خلف اسم Vendor العام فقط.

يفضل معرفة:

• Agent أو Service Identity.
• Tenant.
• Scope.
• Data Access.
• Authority.
• Logging.
• Revocation Path.

Identity Portability

عند نقل Agent بين منصات أو Vendors، قد تتغير Machine Identity بينما تبقى Agent Identity المؤسسية نفسها.

هذا سبب إضافي للفصل بين الهوية المنطقية والهوية التقنية.

Identity Migration

عند Migration يجب التأكد من:

• إنشاء Machine Identity الجديدة.
• نقل أقل صلاحيات لازمة.
• اختبارها.
• تحديث Binding.
• تحديث Registry.
• إلغاء الهوية القديمة.
• إغلاق Sessions القديمة.
• الاحتفاظ بالأدلة.

Model Change هل يغير الهوية؟

تغيير Model لا يعني بالضرورة تغيير Agent Identity.

إذا بقي:

• Purpose.
• Owner.
• Authority.
• Runtime role.

قد تبقى الهوية نفسها.

لكن Model Change قد يكون Governance Event يحتاج إلى إعادة تقييم المخاطر والقدرات.

Agent Versioning

يمكن أن تحتفظ المؤسسة بنفس Agent Identity مع Version مختلفة، أو تنشئ هوية جديدة حسب طبيعة التغيير.

المهم أن تستطيع Logs تحديد أي Version كانت تعمل عند الفعل.

قراءة سيادة: Identity Continuity

تستخدم سيادة AI مفهوم Identity Continuity لوصف استمرار الهوية المؤسسية للAgent عبر التحديثات مع المحافظة على تاريخ قابل للتتبع يوضح الإصدارات وتغيرات Machine Identity وAuthority.

متى تحتاج هوية Agent جديدة؟

قد تحتاج المؤسسة إلى Agent Identity جديدة عندما يتغير بصورة جوهرية:

• Purpose.
• Owner.
• Business Function.
• Risk Boundary.
• Tenant.
• Authority Model.

أما التحديث التقني المحدود فقد لا يحتاج بالضرورة إلى هوية جديدة.

لا تجعل الهوية ثابتة لدرجة تخفي التحول الجوهري

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

Identity Governance كجزء من AI Governance

حوكمة هوية Agent ليست مجالًا منفصلًا عن AI Governance.

بل ترتبط مباشرة بـ:

• Accountability.
• Human Oversight.
• Risk Management.
• Access Governance.
• Security.
• Auditability.
• Incident Response.
• Third-party Risk.
• Change Management.

ما الذي تضيفه Agent Identity فوق IAM التقليدي؟

IAM التقليدي قد يخبرك:

أي حساب دخل إلى أي نظام.

Agent Identity Governance تضيف أسئلة مثل:

• أي Agent كان وراء الحساب؟
• ما Purpose؟
• من Owner؟
• ما Authority؟
• هل القرار ذاتي؟
• ما Delegation؟
• ما Tool Chain؟
• هل Agent تغير؟
• هل العملية كانت داخل Authority Envelope؟

الهوية كجسر بين التقنية والمساءلة

من دون هوية موثوقة، تصبح مفاهيم مثل Authority وOversight وAudit نظرية أكثر من كونها قابلة للتطبيق.

لأن المؤسسة لا تستطيع فرض سياسة مختلفة على كيان لا تستطيع تمييزه.

لهذا تمثل الهوية الجسر بين:

السياسة والنظام والفعل والمساءلة.

نموذج سيادة المتكامل

يمكن تلخيص النموذج بهذا التسلسل:

Agent Identity من هو الوكيل؟

↓

Machine Identity بأي هوية تقنية يعمل؟

↓

Credential كيف يثبت هويته؟

↓

Identity Binding كيف نثبت أن الهوية التقنية تخص الوكيل؟

↓

Effective Access ماذا يستطيع الوصول إليه فعليًا؟

↓

Agent Authority ماذا يحق له أن يفعل؟

↓

Execution Identity من ظهر تقنيًا عند التنفيذ؟

↓

Identity Traceability هل يمكن إعادة بناء السلسلة؟

↓

Accountability هل تستطيع المؤسسة إثبات المسؤولية واتخاذ إجراء؟

Minimum Viable Agent Identity Governance

إذا كانت المؤسسة في بداية الطريق، يمكن البدء بحد أدنى عملي:

1. سجل لكل Agent.
2. Agent ID فريدة.
3. Owner واضح.
4. حصر Machine Identities.
5. منع الحسابات المشتركة غير الضرورية.
6. توثيق Credentials.
7. معرفة Effective Access.
8. ربط Authority بالAgent.
9. Correlation في Logs.
10. Revocation Process.
11. مراجعة دورية.
12. Retirement Checklist.

ثم يتم رفع مستوى النضج تدريجيًا.

السؤال الحاسم

السؤال الذي يجب أن تستطيع المؤسسة الإجابة عنه في أي لحظة هو:

إذا نفذ Agent فعلًا مؤثرًا الآن، هل نستطيع أن نثبت بصورة موثوقة من هو، وبأي هوية تقنية عمل، وما الذي كان مخولًا به، وما الذي نفذه فعلًا؟

إذا كانت الإجابة غير واضحة، فالمؤسسة لا تعاني فقط من نقص في Logging.

بل لديها فجوة في Identity Governance.

خلاصة عملية

حوكمة هوية وكلاء الذكاء الاصطناعي تبدأ بالفصل بين مفاهيم كثيرًا ما يتم خلطها:

Agent Identity ليست Machine Identity.

Machine Identity ليست Credential.

Authentication ليست Authorization.

Authorization ليست Effective Access.

Effective Access ليست Agent Authority.

Agent Authority ليست Execution.

والهدف النهائي ليس إنشاء مزيد من المصطلحات، بل بناء سلسلة يمكن للمؤسسة الوثوق بها:

Identity → Access → Authority → Execution → Evidence → Accountability.

حدود الإسناد إلى PCI SSC وصياغات سيادة

يستند هذا المقال إلى مبادئ أمنية وحوكمية واردة في وثيقة Security Considerations for AI Systems — Information Supplement, Version 1.0, September 2026 الصادرة عن PCI Security Standards Council، ومنها الحاجة إلى تقليل الوصول والوكالة والصلاحيات والأدوات، حماية Credentials والبيانات الحساسة، المحافظة على Logging وMonitoring، وجود Human Oversight، القدرة على الحد من الأنظمة أو تعطيلها، وإعادة التحقق المستمر من الضوابط مع تغير الأنظمة والبيئات.

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

صياغات تشغيلية تستخدمها سيادة AI

تستخدم سيادة AI في هذا المقال مجموعة من الصياغات التشغيلية لتنظيم تحليل الهوية والحوكمة، ومنها:

• Identity Ambiguity.
• Agent-to-Machine Identity Binding.
• Execution Identity.
• Identity Delegation Chain.
• Identity Triad.
• Identity Concentration.
• Identity-Authority Binding.
• Agent Identity Orphan.
• Identity Change Event.
• Identity Collapse.
• Environment Identity Binding.
• Identity Scope.
• Identity Freshness.
• Credential Footprint.
• Revocation Completeness.
• Agent Delegation Identity.
• Identity Pivot.
• Identity Elevation Event.
• Identity Drift.
• Identity Baseline.
• Identity Reality Gap.
• Runtime Identity Context.
• Identity Claim Provenance.
• Identity Translation.
• Identity Correlation Chain.
• Identity Denial Evidence.
• Identity Closure.
• Identity Context Verification.
• Identity Decision Point.
• Identity Enforcement Point.
• Minimum Identity Surface.
• Identity-bound Authority.
• Approval-to-Identity Binding.
• Identity Kill Chain.
• Selective Revocability.
• Identity Evidence Chain.
• Identity Assurance Evidence.
• Agent Identity Maturity.
• Identity Coverage.
• Identity Traceability.
• Identity Control Plane.
• Identity Continuity.

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

المرجع الأساسي

PCI Security Standards Council — Security Considerations for AI Systems, Version 1.0, September 2026.

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