سلطة وكيل الذكاء الاصطناعي ونطاقها: كيف تحدد ما يحق للوكيل فعله وتحت أي حدود وشروط؟

ما هي Agent Authority؟

Agent Authority هي السلطة المؤسسية المفوضة لوكيل ذكاء اصطناعي لاتخاذ قرار أو تنفيذ فعل نيابة عن المؤسسة ضمن هدف وحدود وشروط معتمدة.

السؤال هنا ليس:

ما الذي يستطيع النظام الوصول إليه؟

بل:

ما الذي يحق له أن يفعله باستخدام هذا الوصول؟

قد يمتلك Agent صلاحية تقنية لتنفيذ فعل معين، لكن المؤسسة لم تفوضه أصلًا لاستخدام هذه الصلاحية في ذلك السياق.

وهنا يظهر الفرق بين القدرة التقنية والسلطة المؤسسية.

لماذا يجب فصل Access عن Authority؟

Access يجيب:

ما الذي يستطيع Agent الوصول إليه تقنيًا؟

Authority تجيب:

ما الذي فوضته المؤسسة للوكيل أن يفعله؟

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

وقد لا يكونان كذلك.

مثال:

Agent يملك:

• Read.
• Write.
• Delete.

لكن السلطة المعتمدة هي:

• Read only.
• Draft recommendation.
• No execution.

في هذه الحالة، Effective Access أوسع من Agent Authority.

Effective Access لا يساوي Agent Authority

وجود Permission لا يعني وجود تفويض مؤسسي.

قد يستطيع Agent الوصول إلى:

• Customer records.
• Payment systems.
• Production APIs.
• Internal email.
• Cloud resources.

لكن ذلك لا يعني أن المؤسسة سمحت له باستخدام هذه القدرات لكل غرض.

السلطة يجب أن تكون محددة وفق المهمة والسياق والأثر.

القراءة الثلاثية: Access وAuthority وExecution

يمكن فصل النظام إلى ثلاث طبقات:

1. Access.
2. Authority.
3. Execution.

Access → ما يستطيع النظام الوصول إليه.

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

Execution → ما يستطيع تنفيذه فعليًا في البيئة.

هذه الطبقات قد تتباعد.

مثال على الفصل الثلاثي

Agent مالي:

Access → يستطيع قراءة الفواتير وبيانات الموردين.

Authority → مخول بمراجعة الفاتورة وتقديم توصية.

Execution → النظام التقني يسمح له أيضًا باعتماد الدفع.

هنا توجد فجوة خطرة.

التنفيذ الفعلي يتجاوز السلطة المؤسسية.

قراءة سيادة: Authority Gap

يمكن تعريف Authority Gap بأنه الفرق بين:

Approved Authority و Exercisable Authority

Approved Authority هي السلطة التي اعتمدتها المؤسسة رسميًا.

Exercisable Authority هي السلطة التي يستطيع Agent ممارستها فعليًا عبر قدراته التقنية الحالية.

كلما اتسعت الفجوة، زادت احتمالية ممارسة فعل غير مخول به.

Agent Authority ليست Permission فقط

Agent Authority قد تشمل:

• حق اتخاذ القرار.
• حق إنشاء معاملة.
• حق تعديل بيانات.
• حق التواصل الخارجي.
• حق النشر.
• حق التوقيع أو الاعتماد.
• حق التصعيد.
• حق تشغيل نظام آخر.
• حق استدعاء Agent آخر.
• حق تنفيذ إجراء نهائي.

لذلك لا يجب اختزالها في IAM Role فقط.

من أين تأتي Agent Authority؟

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

• Policy.
• Delegation.
• Workflow.
• Role definition.
• Contract.
• Operating procedure.
• Approval matrix.
• System design.
• Business rule.

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

Delegated Authority

في المؤسسات، السلطة لا تظهر من فراغ.

هناك جهة بشرية أو مؤسسية تفوضها.

قد يكون:

• Process Owner.
• Business Owner.
• Department Head.
• Risk Owner.
• System Owner.
• Executive Authority.

السؤال الأساسي هو:

من فوض Agent بهذه السلطة؟

قراءة سيادة: Delegated Authority

Delegated Authority هي السلطة التي تنتقل من جهة بشرية أو مؤسسية إلى Agent ضمن نطاق محدد ومثبت.

يجب أن يكون التفويض:

• محدد الغرض.
• محدود النطاق.
• قابلًا للإلغاء.
• مرتبطًا بمالك مسؤول.
• قابلًا للتدقيق.
• غير قابل للتوسع الذاتي.

لا تفويض بلا مالك

كل Agent Authority يجب أن يكون لها Owner.

إذا لم تستطع المؤسسة تحديد:

من منح هذه السلطة؟

ومن يملك سحبها؟

فإن السلطة غير منضبطة حوكميًا.

Authority Envelope

Authority Envelope هو النطاق الذي يحدد الحدود التي يجب أن تعمل داخلها سلطة الوكيل.

هو لا يحدد فقط:

ماذا يستطيع أن يفعل؟

بل أيضًا:

• على أي بيانات؟
• على أي أنظمة؟
• لأي مستخدمين؟
• ضمن أي مبلغ؟
• خلال أي مدة؟
• في أي منطقة؟
• في أي Workflow؟
• تحت أي مستوى موافقة؟
• ضمن أي نوع من المعاملات؟

Authority Envelope كغلاف حوكمي

يمكن تصور Authority Envelope كغلاف يحيط بالسلطة المسموحة.

داخل الغلاف:

الأفعال المصرح بها.

خارج الغلاف:

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

مكونات Authority Envelope

يمكن أن يتكون الغلاف من:

• Purpose Boundary.
• Data Boundary.
• System Boundary.
• Action Boundary.
• Financial Boundary.
• Transaction Boundary.
• Time Boundary.
• Geographic Boundary.
• User Boundary.
• Approval Boundary.
• Risk Boundary.
• Escalation Boundary.

كل بُعد يضيق السلطة.

Purpose Boundary

يحدد:

لأي غرض يستطيع Agent استخدام سلطته؟

مثال:

Agent خدمة عملاء قد يستطيع الوصول إلى بيانات العميل.

لكن فقط لغرض:

حل طلب الدعم الحالي.

ليس لغرض:

• التسويق.
• التحليل العام.
• بناء ملف شخصي.
• تدريب نموذج آخر.

Data Boundary

يحدد:

أي بيانات يمكن استخدامها أثناء ممارسة السلطة؟

مثال:

Customer Support Agent → Current customer record only.

ليس:

Entire customer database.

System Boundary

يحدد الأنظمة التي يمكن ممارسة السلطة داخلها.

مثل:

• CRM.
• Ticketing.
• HR system.
• ERP.
• Email.
• Production environment.

وجود Access إلى نظام لا يعني تلقائيًا أن النظام داخل Authority Envelope.

Action Boundary

يحدد أنواع الأفعال المسموحة.

مثل:

• Read.
• Recommend.
• Draft.
• Create.
• Modify.
• Approve.
• Execute.
• Delete.
• Publish.
• Transfer.

كل Action تحمل مستوى أثر مختلفًا.

Recommendation ليست Execution

هناك فرق بين:

Agent recommends و Agent executes

التوصية قد تكون ذات أثر منخفض نسبيًا.

أما التنفيذ فقد يخلق:

• أثرًا ماليًا.
• أثرًا قانونيًا.
• أثرًا تشغيليًا.
• أثرًا أمنيًا.
• أثرًا على العملاء.

لذلك يجب تحديد Authority عند مستوى الفعل نفسه.

Approval Boundary

يحدد متى يجب أن يتوقف Agent ويطلب موافقة.

مثلًا:

• Any payment above 500 SAR.
• Any external publication.
• Any account deletion.
• Any permission change.
• Any contract commitment.
• Any production modification.

Financial Boundary

يمكن أن تحتوي Authority Envelope على حد مالي.

مثال:

Agent يستطيع:

• Approve refunds up to 100 SAR.

لكن فوق ذلك:

• Human approval required.

Transaction Authority

Transaction Authority هي السلطة الممنوحة للوكيل لإنشاء أو اعتماد أو تنفيذ معاملة مالية أو تعاقدية أو تشغيلية.

يجب فصل ثلاث مراحل:

• Create.
• Approve.
• Execute.

قد يمتلك Agent واحدة دون الأخرى.

Create لا يعني Approve

Agent قد يستطيع إنشاء طلب شراء.

لكن لا يملك سلطة اعتماده.

وقد يستطيع اعتماده ضمن حد معين.

لكن لا يملك سلطة تنفيذه.

هذا الفصل مهم في تصميم المعاملات.

قراءة سيادة: Transaction Authority Chain

يمكن تمثيل المعاملة كسلسلة سلطة:

Initiate → Validate → Recommend → Approve → Execute → Verify

ليس من الضروري أن يملك Agent كل المراحل.

بل الأفضل في الأفعال الحساسة فصلها.

Agentic Segregation of Duties

في Agentic AI، يمكن توزيع الوظائف بين عدة Agents أو بين Agent وإنسان وخدمة تنفيذ.

مثال:

Agent A → يستقبل الطلب.

Agent B → يحلل.

Human → يعتمد.

Execution Service → ينفذ.

هذا يقلل تركيز السلطة في كيان واحد.

Authority Concentration

كلما جمعت المؤسسة في Agent واحد:

• Access واسع.
• Decision authority.
• Approval authority.
• Execution authority.
• External communication.

زاد أثر الخطأ أو التلاعب.

قراءة سيادة: Authority Concentration Risk

Authority Concentration Risk هي المخاطر الناتجة عن تجميع عدة أنواع من السلطة الحرجة في Agent واحد.

المبدأ ليس منع التجميع دائمًا.

بل التأكد من أنه مبرر ومراقب ومحدود.

Time Boundary

السلطة قد تكون مؤقتة.

مثل:

• خلال Session واحدة.
• خلال Workflow محدد.
• لمدة ساعة.
• أثناء Incident.
• حتى اكتمال مهمة.

السلطة الدائمة ليست دائمًا ضرورية.

Geographic Boundary

بعض السلطات قد تعتمد على:

• الدولة.
• الإقليم.
• موقع العميل.
• موقع البيانات.
• البيئة القانونية.

Agent قد يكون مخولًا لفعل في دولة وغير مخول به في دولة أخرى.

User Boundary

قد تكون السلطة محدودة بنوع المستخدم.

مثل:

• Employees only.
• Customers only.
• Internal admins only.
• Specific tenant.
• Specific department.

Risk Boundary

يمكن ربط Authority بمستوى المخاطر.

مثال:

Low-risk action → autonomous.

Medium-risk action → execute with policy checks.

High-risk action → human approval.

Critical action → prohibited for autonomous execution.

قراءة سيادة: Impact-based Authority

Impact-based Authority تعني أن مستوى السلطة يجب أن يرتبط بأثر الفعل المحتمل، لا بقدرة Agent وحدها.

كلما زاد الأثر:

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

Escalation Boundary

ليس كل ما لا يستطيع Agent فعله يجب أن يفشل.

قد يصعد الحالة.

مثال:

Agent لا يملك سلطة اعتماد استثناء.

لكن يستطيع:

• Detect exception.
• Prepare evidence.
• Recommend action.
• Escalate to authorized human.

Authority Envelope يجب أن يكون قابلًا للفرض

وجود Policy مكتوبة لا يكفي.

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

• IAM.
• API policy.
• Workflow rules.
• Approval gates.
• Transaction limits.
• Tool restrictions.
• MCP policies.
• Execution services.

إذا كانت Authority Envelope موجودة في الوثائق فقط، فهي ليست Control فعليًا.

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

Authority Enforcement Point هو المكان الذي تُفرض فيه حدود السلطة قبل تنفيذ الفعل.

يمكن أن يكون:

• API Gateway.
• Tool Broker.
• Workflow Engine.
• Transaction Service.
• MCP Gateway.
• Approval Service.
• Policy Engine.

الهدف هو منع الفعل غير المخول قبل حدوثه.

Prompt ليس Authority Enforcement Point

يمكن للـPrompt أن يقول:

"لا تنفذ معاملة فوق 1000."

لكن إذا كانت Tool تسمح بذلك دون تحقق خارجي، فالحماية تعتمد على امتثال النموذج.

الأفضل أن يكون الحد مفروضًا في طبقة خارجية.

Authority وLeast Agency

Least Agency يطلب منح Agent أقل قدر من السلطة والاستقلالية والأدوات اللازمة للمهمة.

Agent Authority تحدد السلطة المعتمدة.

Authority Envelope تحدد حدودها.

Effective Access يوضح ما تسمح به التقنية فعليًا.

الهدف هو جعل هذه الطبقات متقاربة قدر الإمكان.

العلاقة بين Effective Access وAuthority

الوضع المثالي ليس أن تكون Authority مساوية دائمًا لكل Access.

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

يمكن أن يمتلك Agent Access تقنيًا لسبب معماري.

لكن يجب أن توجد Controls تمنع استخدامه خارج Authority Envelope.

قراءة سيادة: Access-Authority Alignment

Access-Authority Alignment يعني أن القدرات التقنية ومسارات التنفيذ لا تسمح للوكيل بممارسة سلطة أوسع من التفويض المعتمد.

الهدف ليس التطابق الحسابي.

الهدف هو منع الفجوة القابلة للاستغلال.

Maximum Exercisable Authority

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

ما أقصى سلطة يستطيع Agent ممارستها فعليًا إذا استخدم كل ما هو متاح له؟

هذا أوسع من سؤال:

ما السلطة المكتوبة في Policy؟

قراءة سيادة: Maximum Exercisable Authority

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

هذه القراءة تساعد على قياس Blast Radius الحقيقي للسلطة.

مثال

Policy تقول:

Agent → Draft refund recommendation only.

لكن النظام يسمح له:

• Create refund.
• Approve refund.
• Execute refund.
• Send customer confirmation.

هنا Maximum Exercisable Authority أكبر بكثير من Approved Authority.

Authority Gap وBlast Radius

كلما اتسعت Authority Gap، زاد الأثر المحتمل عند:

• Prompt Injection.
• Model error.
• Tool misuse.
• Credential compromise.
• Workflow failure.
• Malicious input.

لذلك Authority Design جزء من Security Design أيضًا.

Authority Chain

في الأنظمة المعقدة، السلطة قد تنتقل عبر أكثر من طرف.

مثال:

Business Owner → يفوض Process Owner

Process Owner → يفوض Agent

Agent → يستدعي Agent آخر

Agent الآخر → يستخدم Tool

Tool → تنفذ الفعل على النظام

هذه السلسلة يجب أن تكون واضحة.

قراءة سيادة: Authority Chain

Authority Chain هي سلسلة التفويض والتنفيذ التي توضّح:

• من يملك السلطة الأصلية؟
• من فوضها؟
• لمن انتقلت؟
• ما حدود كل مرحلة؟
• من نفذ الفعل فعليًا؟
• من يستطيع إيقاف السلسلة؟

وجود Chain واضحة مهم للمساءلة.

Transitive Authority

قد لا يمتلك Agent سلطة مباشرة على نظام معين.

لكنه يستطيع استدعاء Agent آخر يمتلكها.

مثال:

Agent A → لا يستطيع تنفيذ Refund.

لكن:

Agent A → يستطيع استدعاء Agent B.

Agent B → يستطيع تنفيذ Refund.

هنا قد تظهر سلطة غير مباشرة.

قراءة سيادة: Transitive Authority

Transitive Authority هي السلطة التي يصبح Agent قادرًا على ممارستها عبر وكيل أو خدمة أو Tool أخرى، رغم أنه لا يملكها مباشرة.

السؤال المهم هو:

ما الذي يستطيع Agent أن يجعل غيره ينفذه نيابة عنه؟

Agent-to-Agent Delegation

في Multi-Agent Systems، قد يقوم Agent بتفويض Agent آخر.

يجب أن نعرف:

• هل التفويض مسموح أصلًا؟
• ما السلطة التي تنتقل؟
• هل تنتقل كلها أم جزء منها؟
• هل هناك Expiry؟
• هل يمكن للـAgent الثاني إعادة التفويض؟
• هل هناك Approval؟

لا تسمح بإعادة التفويض بلا حدود

إذا كان Agent A يستطيع تفويض Agent B، وB يستطيع تفويض C، فقد تتوسع السلطة تدريجيًا.

هذه السلسلة يجب أن تكون محدودة.

قراءة سيادة: Delegation Depth

Delegation Depth هو عدد مستويات التفويض التي يمكن أن تنتقل عبرها السلطة.

كلما زاد العمق، زادت صعوبة تتبع المسؤولية.

يمكن أن تضع المؤسسة حدودًا مثل:

• No redelegation.
• One-level delegation.
• Explicit approval required.

Delegated Authority يجب أن تكون Subset

كقاعدة حوكمة:

السلطة المفوضة لا يجب أن تتجاوز سلطة المفوض الأصلية.

إذا كان Agent A لا يملك صلاحية Approve، فلا يجب أن يستطيع تفويض Agent B ليعتمد.

Authority Escalation

Authority Escalation يحدث عندما يحصل Agent على سلطة أوسع من السلطة المعتمدة له.

قد يحدث بسبب:

• Misconfiguration.
• New tool.
• New workflow.
• Shared credential.
• Delegation.
• Role inheritance.
• MCP exposure.
• Agent chaining.

قراءة سيادة: Authority Escalation Path

Authority Escalation Path هو المسار الذي يسمح للوكيل بالانتقال من سلطة محدودة إلى سلطة أوسع.

قد يكون:

Agent → Tool → Privileged Service

أو:

Agent A → Agent B → Execution Service

أو:

Agent → Shared Admin Credential

الفرق بين Authority Escalation وAccess Escalation

Access Escalation → توسيع ما يستطيع الوصول إليه.

Authority Escalation → توسيع ما يستطيع تنفيذه أو اعتماده أو تقريره.

قد يحدث أحدهما دون الآخر.

Human Oversight

Human Oversight يجب أن ترتبط بنقاط السلطة الحساسة.

ليس كل فعل يحتاج موافقة بشرية.

لكن الأفعال عالية الأثر قد تحتاجها.

مثل:

• Financial approval.
• External publication.
• Account deletion.
• Contract commitment.
• Production change.
• Security policy change.
• Employee decision.

Approval يجب أن يسبق التنفيذ

إذا جاء Human Approval بعد التنفيذ، فهو Review وليس Control وقائي.

لذلك يجب وضع Approval Gate قبل الفعل الحرج.

قراءة سيادة: Pre-Execution Authority Check

Pre-Execution Authority Check هو تحقق يتم قبل التنفيذ للتأكد من أن:

• Agent يملك السلطة.
• الفعل داخل Authority Envelope.
• الحدود المالية والزمنية مستوفاة.
• الموافقة المطلوبة موجودة.
• السياق يسمح بالتنفيذ.

Human Oversight لا تعني Full Manual Control

الهدف ليس تحويل كل Agent إلى نظام يدوي.

يمكن استخدام:

• Thresholds.
• Risk tiers.
• Conditional approvals.
• Dual approvals.
• Exception handling.

السلطة يمكن أن تكون ديناميكية.

Kill Switch

Kill Switch في سياق السلطة ليس مجرد إيقاف النموذج.

يجب أن يستطيع سحب القدرة على التنفيذ.

قد يشمل:

• Disable identity.
• Revoke token.
• Disable tool.
• Disconnect MCP.
• Block workflow.
• Remove transaction permission.
• Block network route.

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

Authority Revocation هي القدرة على سحب السلطة الممنوحة للوكيل بصورة فعالة وسريعة.

يجب أن تكون:

• قابلة للتنفيذ.
• مستقلة عن Prompt.
• مستقلة عن تعاون Agent.
• قابلة للتدقيق.
• قابلة للتجزئة.

Revocation يجب أن تكون دقيقة

قد تحتاج المؤسسة إلى:

• إلغاء سلطة الدفع فقط.
• إبقاء القراءة.
• تعطيل Tool واحدة.
• منع External Communication.
• إيقاف Write.

ليس دائمًا من الضروري إيقاف Agent بالكامل.

Reversibility

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

مثلًا:

Draft → سهل التراجع.

Email sent → أصعب.

Data modified → قد يمكن استعادتها.

Data deleted → قد تكون غير قابلة للاستعادة.

Payment executed → قد يتطلب إجراء عكسي منفصل.

Authority يجب أن ترتبط بـReversibility

كلما قلّت قابلية التراجع، يجب أن تصبح Authority أضيق.

وقد تحتاج:

• Human approval.
• Dual control.
• Independent validation.
• Strong authentication.
• Temporary authority.

قراءة سيادة: Irreversible Authority Boundary

Irreversible Authority Boundary هي النقطة التي ينتقل فيها Agent من فعل قابل للتراجع بسهولة إلى فعل قد يسبب أثرًا دائمًا أو عالي الكلفة.

عند هذه النقطة يجب تشديد الضوابط.

أمثلة على Irreversible Actions

• Delete production data.
• Publish externally.
• Transfer funds.
• Sign contract.
• Change ownership.
• Revoke employee access.
• Deploy to production.
• Modify security policy.

هذه الأفعال تحتاج Authority Design خاصة.

Authority وTransaction Limits

Transaction Authority يجب أن تقترن بحدود واضحة.

مثل:

• Amount.
• Currency.
• Vendor.
• Customer.
• Transaction type.
• Frequency.
• Daily limit.
• Geographic scope.

قراءة سيادة: Transaction Envelope

Transaction Envelope هو الجزء من Authority Envelope الذي يحدد شروط تنفيذ المعاملات.

مثال:

Refund → حتى 100 SAR → مرة واحدة لكل Ticket → داخل السعودية → للعميل نفسه → مع Log كامل

Authority Frequency Limits

قد يكون Agent مخولًا بفعل معين، لكن ليس بلا حدود.

مثال:

• Maximum 10 refunds per hour.
• Maximum 100 emails per day.
• Maximum 5 production changes per window.

Frequency جزء من السلطة.

Rate Limit ليس Performance فقط

Rate Limits قد تكون Control حوكميًا.

هي لا تحمي فقط الأداء.

بل تحد من Blast Radius.

Context-bound Authority

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

مثل:

Agent يمكنه:

Approve refund

لكن فقط إذا:

• Ticket is open.
• Customer identity verified.
• Amount below threshold.
• No fraud flag.
• No previous refund.

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

Context-bound Authority هي سلطة لا تصبح قابلة للممارسة إلا إذا تحققت شروط سياقية محددة.

هذا أقوى من Permission دائمة وغير مشروطة.

Authority Drift

مع الزمن، قد تتوسع السلطة دون اعتماد واضح.

أسباب ذلك:

• New role.
• New tool.
• New API.
• New workflow.
• New delegation.
• Expanded transaction limit.
• Removed approval.
• Extended expiry.
• Added agent chain.

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

Authority Drift هو الاختلاف الذي ينشأ مع الزمن بين السلطة المعتمدة والسلطة التي يستطيع Agent ممارستها فعليًا.

هذا قد يحدث تدريجيًا.

Authority Drift قد يحدث دون تغيير Prompt

قد يبقى Prompt كما هو.

لكن:

• IAM تتغير.
• Tool تتغير.
• Workflow تتغير.
• MCP تتغير.
• Approval gate يزال.

فتتوسع السلطة.

Authority Baseline

يجب أن يكون لكل Agent Baseline معتمد للسلطة.

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

• Purpose.
• Owner.
• Allowed decisions.
• Allowed actions.
• Transaction rights.
• Financial limits.
• Data boundaries.
• System boundaries.
• Approval thresholds.
• Time limits.
• Delegation rules.
• Revocation path.
• Escalation path.

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

Authority Baseline هو السجل المعتمد للسلطة التي يحق للوكيل ممارستها والحدود التي تقيدها.

يستخدم لمقارنة الواقع مع التصميم.

Declared Authority vs Exercisable Authority

Declared Authority هي السلطة المكتوبة في:

• Policy.
• Design.
• Approval matrix.
• Operating procedure.

Exercisable Authority هي ما يستطيع Agent تنفيذه فعليًا.

الفرق بينهما مهم.

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

Authority Reality Gap هي الفجوة بين السلطة المعلنة والسلطة القابلة للممارسة فعليًا.

قد تكون هناك Policy مثالية بينما البيئة تسمح بأكثر.

Monitoring Authority

المراقبة يجب أن تركز على أفعال السلطة.

مثل:

• Approvals.
• Transactions.
• Deletes.
• Publishes.
• Permission changes.
• External communications.
• Production actions.
• Agent delegations.

لا يكفي مراقبة Tool Calls فقط

Tool Call قد يكون مجرد وسيط.

يجب معرفة:

ما الأثر المؤسسي للفعل؟

مثال:

Tool = update_record

لكن الأثر قد يكون:

• تغيير بيانات عميل.
• تغيير حالة عقد.
• تغيير حد ائتماني.

قراءة سيادة: Authority Event

Authority Event هو أي فعل يمارس فيه Agent سلطة مؤسسية ذات أثر.

يمكن أن يسجل:

• Agent identity.
• Action.
• Target.
• Authority basis.
• Approval.
• Limits.
• Timestamp.
• Result.
• Reversibility.
• Evidence.

Authority Logging

كل Authority Event مهم يجب أن يكون قابلًا للتتبع.

السجل يجب أن يساعد على الإجابة:

• من نفذ؟
• تحت أي سلطة؟
• ما الشرط الذي سمح بالفعل؟
• هل كانت هناك موافقة؟
• هل تجاوز حدًا؟
• هل يمكن التراجع؟

Authority وAI-BOM

AI-BOM يمكن أن يسجل مكونات السلطة أيضًا.

مثل:

• Agent Identity.
• Tools.
• APIs.
• Execution services.
• Approval services.
• Policy engines.
• Transaction systems.
• Delegation dependencies.

قراءة سيادة: Governance BOM for Authority

من منظور سيادة، يمكن توسيع AI-BOM ليشمل ليس فقط مكونات النظام، بل أيضًا عناصر السلطة:

• Who can authorize.
• What can execute.
• Where authority is enforced.
• How it is revoked.
• Which actions are irreversible.

Authority وMCP

MCP قد يمنح Agent أدوات تنفيذية.

مثل:

• Email.
• Git.
• Database.
• Cloud.
• Files.
• SaaS.

لذلك Tool Exposure يجب أن يقارن بـAuthority Envelope.

MCP Tool متاحة لا تعني أنها Authorized

قد تكون Tool متاحة تقنيًا.

لكن Authority لا تسمح باستخدامها إلا في سياقات معينة.

لذلك يجب أن يفرض Gateway أو Policy Layer الحدود.

Authority وLethal Trifecta

إذا اجتمع:

• Sensitive Data.
• Untrusted Input.
• External Communication.

ومعها Agent Authority واسعة، يصبح الأثر أعلى.

Authority تحدد ما يستطيع Agent فعله بالبيانات بعد الوصول إليها.

مثال

Agent يقرأ بيانات حساسة.

ويستقبل Prompt غير موثوق.

ويملك سلطة:

• Send external email.
• Upload file.
• Execute webhook.

هنا ليس الخطر Access فقط.

بل Authority أيضًا.

Authority وLeast Agency

Least Agency يطلب:

أقل سلطة لازمة للمهمة.

إذا كان Agent يحتاج:

Recommend

فلا تمنحه:

Approve + Execute

إذا كان يحتاج:

Read

فلا تمنحه:

Modify + Delete

Authority Minimization

Authority Minimization تعني تقليص:

• Decision rights.
• Execution rights.
• Transaction rights.
• Delegation rights.
• External communication rights.

إلى الحد المطلوب.

قراءة سيادة: Minimum Effective Authority

Minimum Effective Authority هي أقل سلطة مؤسسية تكفي لكي يحقق Agent هدفه المعتمد بصورة موثوقة.

هذا هو المقابل السلطوي لفكرة Minimum Effective Agency.

بناء Authority Matrix

يمكن تحويل Agent Authority إلى Matrix عملية بدل بقائها مفهومًا نظريًا.

لكل Agent، وثق:

• Purpose.
• Authority Owner.
• Allowed Decisions.
• Allowed Actions.
• Prohibited Actions.
• Transaction Rights.
• Financial Limits.
• Data Boundary.
• System Boundary.
• User Boundary.
• Geographic Boundary.
• Time Boundary.
• Approval Requirements.
• Delegation Rights.
• Escalation Path.
• Revocation Path.
• Reversibility Level.

الهدف هو معرفة ما يحق للوكيل فعله بدقة.

Authority Matrix ليست IAM Matrix

IAM Matrix تركز على:

• Roles.
• Permissions.
• Resources.

Authority Matrix تركز على:

• Decision rights.
• Action rights.
• Transaction rights.
• Approval rights.
• Delegation rights.
• Execution rights.

قد تتقاطع المصفوفتان، لكنهما ليستا الشيء نفسه.

مقارنة Authority Matrix مع Effective Access

بعد بناء Authority Matrix، قارنها بـEffective Access.

اسأل:

• هل الوصول التقني أوسع من السلطة؟
• هل توجد Actions يستطيع Agent تنفيذها دون تفويض؟
• هل توجد Tools تكشف وظائف خارج Authority Envelope؟
• هل توجد APIs تسمح بتنفيذ أكثر من السياسة؟
• هل توجد Credentials تسمح بتجاوز Approval؟

هذه المقارنة تكشف Misalignment.

قراءة سيادة: Authority Control Matrix

Authority Control Matrix تربط كل نوع من السلطة بالضابط الذي يفرضه.

مثال:

Decision Authority → Policy Engine

Transaction Limit → Transaction Service

Approval Boundary → Workflow Gate

Tool Scope → Tool Broker

MCP Scope → MCP Gateway

Revocation → IAM / Credential Control

الفكرة هي تحويل كل حد حوكمي إلى Control قابل للتنفيذ.

Policy Enforcement

Authority Envelope يجب أن تتحول إلى Rules قابلة للتنفيذ.

مثلًا:

إذا كان:

Amount > 1000

فالمطلوب:

Human Approval = Required

أو:

External Publish = true

فالمطلوب:

Executive Approval = Required

أو:

Environment = Production

فالمطلوب:

Dual Control = Required

Policy يجب أن تكون خارج النموذج عند الإمكان

لا تجعل Model نفسه يقرر دائمًا:

هل يملك Authority؟

الأفضل أن تسأل طبقة خارجية.

مثل:

Agent → requests action

Policy Engine → evaluates authority

Approval Service → checks approvals

Execution Service → executes if authorized

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

Authority Decision Point هو المكان الذي يتم فيه تقرير ما إذا كان الفعل داخل السلطة المعتمدة قبل التنفيذ.

قد يكون:

• Policy Engine.
• Workflow Engine.
• API Gateway.
• Transaction Service.
• Approval Service.

ويجب ألا يعتمد على Prompt وحده.

Authority Decision Point وAuthority Enforcement Point

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

Authority Decision Point → يقرر هل الفعل مسموح.

Authority Enforcement Point → يمنع أو يسمح بالتنفيذ فعليًا.

قد يكونان في نفس النظام أو نظامين مختلفين.

الفصل بين القرار والتنفيذ

التصميم الأقوى غالبًا يفصل:

Agent decides/recommends

عن:

Execution Service executes

بهذا لا يمتلك Agent بالضرورة كل صلاحيات التنفيذ المباشر.

القراءة مقابل الكتابة

من أبسط طرق تقليل السلطة:

Read بدل Write

Draft بدل Publish

Recommend بدل Approve

Approve بدل Execute

كل انتقال يرفع مستوى السلطة.

قراءة سيادة: Authority Ladder

يمكن تصور Authority Ladder مثل:

Observe → Analyze → Recommend → Draft → Initiate → Approve → Execute → Override

ليس كل Agent بحاجة للوصول إلى أعلى السلم.

Progressive Authority

يمكن رفع السلطة تدريجيًا.

Phase 1 → Recommend only

Phase 2 → Draft

Phase 3 → Execute with approval

Phase 4 → Execute within narrow envelope

Phase 5 → Higher autonomy under monitoring

هذا أفضل من Full Authority منذ البداية.

Authority يجب أن تُمنح حسب الأداء والأثر

رفع Authority يجب أن يعتمد على:

• Use case maturity.
• Control maturity.
• Incident history.
• Monitoring quality.
• Reversibility.
• Human oversight.
• Risk appetite.

وليس فقط على أن Model أصبح أقوى.

Authority وModel Capability

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

لذلك قد تتغير المخاطر حتى لو لم تتغير Permissions.

مثال:

Model قديم → لا يستطيع تنفيذ workflow معقد.

Model جديد → يستطيع تخطيط سلسلة Tools وتنفيذها.

نفس الوصول، لكن Exercisable Authority الفعلية قد تصبح أعلى.

قراءة سيادة: Capability-Authority Interaction

Capability-Authority Interaction هو أثر قدرات النموذج على السلطة التي يستطيع النظام ممارستها فعليًا.

إذا ارتفعت قدرات التخطيط والتنفيذ واستخدام الأدوات، يجب إعادة تقييم Authority Envelope.

Change Triggers

يجب إعادة تقييم Agent Authority عند:

• Model change.
• New tool.
• New MCP Server.
• New API.
• New execution service.
• New data source.
• IAM expansion.
• New delegation.
• New agent-to-agent link.
• Approval removal.
• Threshold increase.
• Transaction limit increase.
• New geography.
• New user segment.
• New workflow.
• New environment.
• New autonomous capability.

Authority Change as Governance Event

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

مثل:

Draft → Publish

Read → Write

Recommend → Approve

Approve → Execute

Internal → External

كل واحدة منها تغير ملف المخاطر.

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

Authority Change Event هو أي تغيير يوسع أو يغير السلطة التي يستطيع Agent ممارستها.

يجب أن ينتج عنه:

• Review.
• Approval.
• Baseline update.
• Control validation.
• Evidence.
• Revalidation.

Authority Drift Detection

يمكن اكتشاف Authority Drift بمقارنة:

Approved Authority Baseline

مع:

Actual Configuration

و:

Observed Authority Events

إذا ظهرت أفعال غير موجودة في Baseline، يجب التحقيق.

Observed Authority

Observed Authority هي السلطة التي ثبت أن Agent مارسها فعليًا من خلال Logs وTransactions وActions.

لا تعني أنها أقصى سلطة ممكنة.

بل ما تمت ممارسته.

الفرق بين Observed Authority وMaximum Exercisable Authority

Observed Authority → ما حدث فعليًا.

Maximum Exercisable Authority → ما كان يمكن أن يحدث تقنيًا.

الاثنان مهمان.

Logs تظهر الأول.

Architecture وConfiguration تساعد على تحديد الثاني.

Authority Testing

يمكن اختبار السلطة عمليًا في بيئة آمنة.

مثلًا:

• هل Agent يستطيع Execute دون Approval؟
• هل يستطيع تجاوز Financial Limit؟
• هل يستطيع استخدام Tool خارج Envelope؟
• هل يستطيع Re-delegate؟
• هل يستطيع استدعاء Agent أعلى سلطة؟
• هل يستطيع تغيير Approval Route؟
• هل يستطيع تنفيذ فعل غير قابل للتراجع؟

هذه الاختبارات يجب أن تكون مصرحًا بها وآمنة.

Negative Authority Testing

لا تختبر فقط ما يجب أن ينجح.

اختبر ما يجب أن يفشل.

مثل:

Refund above limit → يجب أن يفشل أو يصعد.

Delete without approval → يجب أن يفشل.

External publish without approval → يجب أن يفشل.

Unauthorized delegation → يجب أن يفشل.

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

Authority Denial Evidence هو دليل يثبت أن النظام منع فعلًا يقع خارج Authority Envelope.

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

السيناريو المالي

Agent مالي يستطيع:

• Analyze invoice.
• Detect anomaly.
• Recommend payment.

Authority Envelope:

• No approval.
• No execution.
• No bank detail modification.

إذا توسعت سلطته لاحقًا:

Approve up to 500 SAR

يجب إضافة:

• Transaction limit.
• Supplier validation.
• Approval logging.
• Revocation.
• Fraud checks.

السيناريو المالي المتقدم

إذا كان Agent يستطيع:

Create payment + Approve payment + Execute payment

فهذا تركيز عالٍ جدًا للسلطة.

يمكن الفصل:

Agent A → validates invoice.

Agent B → recommends payment.

Human → approves.

Payment Service → executes.

السيناريو الأمني

Security Agent قد يستطيع:

• Read alerts.
• Correlate events.
• Recommend response.

Authority Envelope قد تمنعه من:

• Disable account.
• Block network.
• Delete data.
• Change firewall.
• Isolate production host.

إلا بعد Approval.

السيناريو التشغيلي

Operations Agent:

Authority:

• Restart noncritical service.
• Open ticket.
• Collect diagnostics.

Outside envelope:

• Deploy code.
• Modify production configuration.
• Delete infrastructure.
• Rotate privileged secrets.

السيناريو البشري HR

HR Agent قد يستطيع:

• Answer policy questions.
• Draft job description.
• Summarize candidate data.

لكن لا يملك بالضرورة Authority لـ:

• Reject candidate.
• Approve termination.
• Change salary.
• Modify employee record.

هذه قرارات ذات أثر مؤسسي وبشري مرتفع.

السيناريو القانوني

Legal Agent قد:

• Draft clause.
• Compare contracts.
• Identify risk.

لكن Authority Envelope قد تمنعه من:

• Accept contractual obligation.
• Sign agreement.
• Waive rights.
• Commit organization externally.

Authority وExternal Communication

إرسال رسالة خارجية قد يكون ممارسة للسلطة.

خصوصًا إذا كانت الرسالة:

• Contractual.
• Financial.
• Regulatory.
• Customer commitment.
• Public statement.

لذلك Email Tool ليست دائمًا مجرد Communication Tool.

قد تكون Execution Channel.

قراءة سيادة: Communication Authority

Communication Authority هي السلطة الممنوحة للوكيل لإرسال أو نشر محتوى يمثل المؤسسة أو ينشئ التزامًا أو أثرًا خارجيًا.

يمكن تقييدها حسب:

• Audience.
• Domain.
• Channel.
• Content type.
• Approval.
• Classification.

Authority وData Classification

قد تكون Authority مختلفة حسب تصنيف البيانات.

مثال:

Public Data → autonomous.

Internal Data → limited.

Confidential → restricted.

Restricted → human approval or prohibited.

Authority وEnvironment

يمكن أن تختلف السلطة حسب البيئة.

Development → أوسع للتجربة.

Staging → محدودة.

Production → أشد تقييدًا.

لذلك Environment جزء من Authority Envelope.

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

Environment-bound Authority تعني أن التفويض صالح فقط داخل Environment محددة.

Agent لا يجب أن يرث تلقائيًا نفس السلطة من Development إلى Production.

Authority وTenant Isolation

في الأنظمة متعددة العملاء، يجب أن تكون Authority مرتبطة بالـTenant.

Agent قد يملك:

Read customer data

لكن:

Tenant A فقط.

إذا استطاع العمل على Tenant B، هناك تجاوز للغلاف.

Authority وIdentity

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

بدون Agent Identity مستقلة، يصبح من الصعب معرفة:

• من مارس السلطة؟
• من يجب Revoke؟
• من تجاوز Envelope؟
• من نفذ المعاملة؟

Shared Identity تضعف Authority Governance

إذا استخدمت عدة Agents نفس Account:

قد تعرف أن الحساب نفذ الفعل.

لكن لا تعرف أي Agent اتخذ القرار.

وهذا يضعف Accountability.

Authority وAudit Trail

Audit Trail الجيد يجب أن يربط:

Agent → Authority basis → Decision → Approval → Execution → Evidence

وليس فقط:

User X called API Y.

أدلة التدقيق المطلوبة

يمكن طلب:

• Authority Baseline.
• Delegation records.
• Approval matrix.
• IAM configuration.
• Transaction limits.
• Tool allowlists.
• MCP policies.
• Workflow rules.
• Policy engine rules.
• Authority event logs.
• Human approvals.
• Revocation records.
• Change history.
• Incident records.

أسئلة تدقيق Agent Authority

يمكن للمدقق أن يسأل:

1. من يملك السلطة الأصلية؟
2. من فوض Agent؟
3. ما Purpose المعتمد؟
4. ما القرارات المسموحة؟
5. ما الأفعال المسموحة؟
6. ما الأفعال المحظورة؟
7. ما Transaction Authority؟
8. ما Financial Limits؟
9. ما Approval Boundaries؟
10. هل يوجد Delegation؟
11. هل يسمح Re-delegation؟
12. ما Delegation Depth؟
13. هل توجد Transitive Authority؟
14. ما Authority Envelope؟
15. أين يتم Enforcement؟
16. هل Prompt جزء من Enforcement؟
17. هل توجد Authority Gap؟
18. ما Maximum Exercisable Authority؟
19. هل توجد Irreversible Actions؟
20. هل Kill Switch يسحب السلطة فعليًا؟
21. هل Authority Baseline محدثة؟
22. هل توجد Authority Drift؟
23. هل كل Authority Event مسجل؟
24. هل يمكن إثبات Denial خارج Envelope؟

Authority وContinuous Validation

السلطة ليست قرارًا لمرة واحدة.

يجب إعادة التحقق منها دوريًا.

خصوصًا عند تغير:

• Model.
• Tools.
• Workflows.
• MCP.
• APIs.
• Roles.
• Delegations.
• Transaction limits.
• Approvals.

دورة حياة Agent Authority

Design → تعريف السلطة المطلوبة.

Build → تطبيق Authority Envelope.

Test → اختبار السماح والمنع.

Deploy → اعتماد Authority Baseline.

Operate → مراقبة Authority Events.

Change → Revalidation.

Incident → Revoke / constrain.

Retire → إزالة السلطة والتفويضات.

عند إيقاف Agent

Retirement يجب أن يشمل:

• Disable identity.
• Revoke credentials.
• Remove roles.
• Remove delegated authority.
• Remove approval rights.
• Remove transaction rights.
• Disconnect execution tools.
• Remove MCP access.
• Update AI-BOM.
• Close audit record.

لا يجب أن تبقى السلطة بعد انتهاء Agent.

أخطاء شائعة

من الأخطاء الشائعة:

• اعتبار Permission مساوية لـAuthority.
• عدم تحديد Authority Owner.
• منح Agent سلطة أوسع من Purpose.
• الخلط بين Recommend وApprove وExecute.
• السماح بإنشاء واعتماد وتنفيذ المعاملة داخل Agent واحد دون مبرر.
• عدم تحديد Financial Limits.
• عدم تحديد Transaction Limits.
• عدم تحديد Delegation Rules.
• السماح بـRe-delegation غير المحدود.
• تجاهل Transitive Authority.
• استخدام Shared Identity.
• الاعتماد على Prompt لفرض Authority Envelope.
• عدم وضع Authority Enforcement Point.
• وضع Human Approval بعد التنفيذ.
• تجاهل Reversibility.
• منح Irreversible Authority بلا ضوابط إضافية.
• عدم بناء Authority Baseline.
• عدم اكتشاف Authority Drift.
• عدم اختبار أفعال يجب أن تفشل.
• عدم إلغاء السلطة عند Retirement.

قائمة تحقق سريعة

قبل تشغيل Agent، تحقق:

• هل Purpose واضح؟
• هل Authority Owner معروف؟
• هل Approved Authority موثقة؟
• هل Authority Envelope واضحة؟
• هل Effective Access متوافق معها؟
• هل Transaction Authority محددة؟
• هل Financial Limits محددة؟
• هل Approval Boundaries واضحة؟
• هل Delegation محدودة؟
• هل Re-delegation مضبوطة؟
• هل Transitive Authority مفهومة؟
• هل Authority Enforcement Point موجود؟
• هل Prompt ليس Control الوحيد؟
• هل Irreversible Actions محمية؟
• هل Human Oversight متناسب مع الأثر؟
• هل Kill Switch يسحب Authority فعليًا؟
• هل Authority Baseline محفوظة؟
• هل Authority Events مسجلة؟
• هل Authority Drift قابل للاكتشاف؟
• هل Maximum Exercisable Authority معروف؟

الخلاصة

في Agentic AI، الوصول ليس هو السلطة.

وقدرة النظام على تنفيذ فعل لا تعني أن المؤسسة فوضته لتنفيذه.

الحوكمة الناضجة تميز بين:

Effective Access → ما يستطيع Agent الوصول إليه.

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

Authority Envelope → الحدود والشروط التي تحكم هذه السلطة.

Transaction Authority → ما يحق له إنشاؤه أو اعتماده أو تنفيذه من معاملات.

Minimum Effective Authority → أقل سلطة مؤسسية لازمة لتحقيق الهدف.

الهدف ليس منع Agents من التنفيذ.

الهدف هو جعل سلطتها:

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

المرجع

يستند هذا المقال إلى مبادئ أمن وحوكمة الأنظمة الوكيلية الواردة في:

PCI Security Standards Council Security Considerations for AI Systems — Information Supplement Version 1.0 — September 2026.

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

أما مفاهيم:

Authority Gap Delegated Authority Authority Chain Transitive Authority Delegation Depth Authority Escalation Path Pre-Execution Authority Check Authority Revocation Irreversible Authority Boundary Transaction Authority Chain Transaction Envelope Context-bound Authority Authority Drift Authority Baseline Authority Reality Gap Authority Event Authority Enforcement Point Authority Decision Point Authority Ladder Capability-Authority Interaction Authority Change Event Authority Denial Evidence Communication Authority Environment-bound Authority Maximum Exercisable Authority Minimum Effective Authority

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