مبدأ الحد الأدنى من الوكالة: كيف تقلّص صلاحيات وكلاء الذكاء الاصطناعي قبل أن تتحول إلى خطر؟

ما هو مبدأ الحد الأدنى من الوكالة؟

مبدأ الحد الأدنى من الوكالة Least Agency هو مبدأ حوكمة يقضي بألا تمنح المؤسسة وكيل الذكاء الاصطناعي أكثر من الحد اللازم من الاستقلالية والسلطة والصلاحيات والأدوات لتنفيذ الهدف المعتمد.

الفكرة الأساسية هي تقليل مساحة الضرر الممكن.

كل قدرة إضافية يحصل عليها Agent قد تزيد ما يستطيع فعله إذا:

• أخطأ.
• أسيء توجيهه.
• تعرض لـPrompt Injection.
• استخدم أداة بصورة غير متوقعة.
• حصل Drift في سلوكه.
• تغيرت صلاحياته أو تكاملاته.
• تم اختراق أحد المكونات المحيطة به.

لذلك لا يكفي أن يكون الهدف مشروعًا.

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

الفرق بين Least Privilege وLeast Agency

Least Privilege يركز تقليديًا على منح المستخدم أو النظام أقل قدر من الصلاحيات التقنية اللازمة.

مثل:

• أقل IAM Role.
• أقل Database Permission.
• أقل File Access.
• أقل API Scope.

أما Least Agency فهو أوسع.

هو لا يسأل فقط:

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

بل يسأل أيضًا:

• ما الذي يستطيع أن يقرره؟
• ما الأدوات التي يستطيع استخدامها؟
• ما الأفعال التي يستطيع تنفيذها؟
• هل يحتاج موافقة بشرية؟
• هل يستطيع الاتصال بالخارج؟
• هل يستطيع بدء إجراءات جديدة من تلقاء نفسه؟
• كم تبقى صلاحياته فعالة؟
• هل يستطيع استدعاء Agents أخرى؟

إذن:

Least Privilege جزء من Least Agency

لماذا هذا الفرق مهم في Agentic AI؟

في نظام تقليدي، قد تكون المشكلة الأساسية هي الوصول غير المصرح به.

أما في Agentic AI، فالنظام قد يجمع بين:

• الوصول.
• التحليل.
• اتخاذ القرار.
• اختيار الأداة.
• تنفيذ الفعل.
• متابعة النتيجة.
• إعادة المحاولة.

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

وكيل يملك Read Access فقط ليس مساويًا لوكيل يملك Read + Write + External Communication + Autonomous Execution.

قراءة سيادة: Effective Agency

يمكن تعريف Effective Agency عمليًا بأنها السلطة التي يستطيع النظام ممارستها فعلًا داخل البيئة التقنية.

ولا تقاس فقط بما هو مكتوب في Prompt.

بل بما تسمح به:

• IAM.
• APIs.
• Tools.
• MCP Servers.
• Network Access.
• Credentials.
• Workflow Engine.
• Approval Logic.
• Execution Services.

إذا كانت البنية التقنية تمنح Agent سلطة واسعة، فإن تعليمات لغوية مثل:

"استخدم فقط ما تحتاجه"

لا تقلص Effective Agency فعليًا.

البعد الأول: Data Scope

أول سؤال:

ما البيانات التي يستطيع Agent الوصول إليها؟

يجب تقليص النطاق إلى الحد اللازم.

بدل:

Agent → Entire Customer Database

يفضل:

Agent → Required Customer Record

يمكن تقليل Data Scope باستخدام:

• Row-level filtering.
• Scoped Retrieval.
• Data Minimization.
• Redaction.
• Tokenization.
• Purpose-specific Views.
• Read-only Datasets.
• Attribute-based Access Control.

كل Dataset إضافية توسع ما يمكن كشفه أو إساءة استخدامه.

Data Scope ليس فقط قواعد البيانات

يجب أن يشمل التقييم أيضًا:

• الملفات.
• البريد الإلكتروني.
• المحادثات.
• Vector Stores.
• Memory.
• Logs.
• Cached Context.
• SaaS Systems.
• Documents.
• APIs.

قد تكون البيانات الحساسة موجودة في Context أو Memory حتى لو لم يكن Agent متصلًا بقاعدة بيانات مباشرة.

البعد الثاني: Tool Scope

السؤال التالي:

ما الأدوات التي يستطيع Agent استخدامها؟

كل Tool تضيف قدرة.

مثل:

• Email Tool.
• Database Tool.
• Browser.
• File Tool.
• Shell.
• Code Executor.
• CRM Connector.
• Payment API.
• Cloud Console.
• MCP Tool.

Least Agency يعني ألا يتلقى Agent أداة لا يحتاجها للمهمة.

Agent مخصص للتلخيص لا يحتاج بالضرورة:

• Delete Permission.
• External Email.
• Shell Access.
• Production Database Write.

قراءة سيادة: Tool Exposure Budget

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

كل Tool يجب أن يكون لها سبب واضح.

اسأل:

• لماذا يحتاجها Agent؟
• ما الأفعال التي تتيحها؟
• ما الأنظمة التي تصل إليها؟
• هل يوجد بديل أضيق؟
• هل يمكن تحويلها إلى Read Only؟
• هل يمكن تقييدها بسياق محدد؟

الأداة العامة أخطر من أداة ضيقة الغرض.

البعد الثالث: Action Scope

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

يمكن أن يكون Agent قادرًا على:

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

Least Agency يعني تحديد أدنى Action Scope مناسب.

مثلًا:

بدل:

Agent → Create + Approve + Execute Payment

يفضل:

Agent → Prepare Payment Recommendation → Human Approval → Separate Execution Service

فصل التوصية عن التنفيذ

من أهم تطبيقات Least Agency فصل:

• التحليل.
• القرار.
• التنفيذ.

في كثير من الحالات، لا يحتاج Agent إلى تنفيذ الإجراء بنفسه.

قد يكفي أن:

• يقترح.
• يصنف.
• يجهز Draft.
• يرفع Request.

ثم تنفذ خدمة مستقلة أو مستخدم معتمد الإجراء.

البعد الرابع: Network Scope

السؤال:

إلى أين يستطيع Agent الاتصال؟

Network Access توسع السلطة الفعلية للنظام.

قد تشمل:

• Internet Access.
• External APIs.
• Email.
• Webhooks.
• SaaS.
• Cloud Services.
• MCP Servers.
• External Storage.

يمكن تطبيق Least Agency من خلال:

• Egress Allowlisting.
• Private Endpoints.
• Network Segmentation.
• Proxy Enforcement.
• Destination Restrictions.
• Protocol Restrictions.
• No-internet Environments.

Agent لا يحتاج اتصالًا عامًا بالإنترنت إذا كانت مهمته تعتمد على ثلاثة Endpoints محددة فقط.

الاتصال الخارجي ليس ميزة محايدة

وجود قناة خارجية قد يغير أثر Prompt Injection أو اختراق داخلي.

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

• قراءة بيانات حساسة.
• استقبال محتوى غير موثوق.
• الاتصال بالخارج.

فقد يظهر مسار Lethal Trifecta.

تقليل Network Scope يمكن أن يكسر هذا المسار.

البعد الخامس: Autonomy Scope

هذا هو الفرق الأكثر وضوحًا بين Least Privilege وLeast Agency.

Autonomy Scope يحدد مقدار ما يستطيع النظام فعله دون موافقة بشرية.

يمكن تصور مستويات مثل:

• Suggest Only.
• Draft.
• Execute with Approval.
• Execute within Threshold.
• Fully Autonomous.

ليس كل Use Case يحتاج المستوى الأعلى.

مثال:

Agent يراجع فواتير لا يحتاج بالضرورة القدرة على تحويل الأموال تلقائيًا.

Autonomy يجب أن تكون مرتبطة بالأثر

كلما زاد أثر القرار، قل المستوى المناسب من الاستقلالية.

أسئلة مهمة:

• هل الفعل قابل للتراجع؟
• هل يؤثر في عميل؟
• هل يحرك أموالًا؟
• هل يغير صلاحيات؟
• هل ينشر محتوى خارجيًا؟
• هل يغير Production؟
• هل يمس حقوق شخص؟

كلما ارتفع الأثر، زادت الحاجة إلى Approval أو Segregation of Duties.

البعد السادس: Time Scope

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

يمكن تطبيق Least Agency زمنيًا عبر:

• Just-in-time Access.
• Short-lived Credentials.
• Session-bound Permissions.
• Task-bound Authorization.
• Automatic Expiry.
• Temporary Network Access.

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

قراءة سيادة: Time-bound Agency

Time-bound Agency تعني أن السلطة تمنح للمدة اللازمة فقط.

مثال:

Agent يحتاج الوصول إلى API محددة لإنهاء Workflow.

يمكن أن تكون Credential:

• قصيرة العمر.
• مرتبطة بالمهمة.
• قابلة للإلغاء.
• غير صالحة خارج سياق التنفيذ.

هذا يقلل نافذة إساءة الاستخدام.

الأبعاد الستة معًا

يمكن تلخيص Least Agency عبر ستة أسئلة:

1. Data Scope — ما البيانات التي يستطيع الوصول إليها؟
2. Tool Scope — ما الأدوات التي يستطيع استخدامها؟
3. Action Scope — ما الأفعال التي يستطيع تنفيذها؟
4. Network Scope — إلى أين يستطيع الاتصال؟
5. Autonomy Scope — ماذا يستطيع أن يفعل دون موافقة؟
6. Time Scope — كم من الوقت تبقى السلطة متاحة؟

إذا كانت الإجابات أوسع من حاجة المهمة، فهناك Excess Agency.

قراءة سيادة: Excess Agency

Excess Agency هي أي سلطة أو أداة أو وصول أو استقلالية تزيد على ما تتطلبه المهمة المعتمدة.

قد تظهر مثلًا كالتالي:

• Database Access أوسع من الحاجة.
• Tool غير مستخدمة في المهمة.
• Write Permission بينما Read يكفي.
• Internet Access غير ضروري.
• Full Autonomy بينما Approval مناسب.
• Credential طويلة العمر دون حاجة.
• Access إلى أنظمة جانبية غير مرتبطة بالمهمة.

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

هي أيضًا مشكلة Governance Design.

Least Agency وAgent Identity

لا يمكن تطبيق Least Agency بصورة قوية إذا لم يكن للوكيل هوية مستقلة يمكن تقييدها ومراقبتها وإلغاؤها.

إذا استخدمت عدة Agents نفس Credential المشتركة، تصبح الحدود ضبابية.

لا تعرف بدقة:

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

لذلك Agent Identity عنصر أساسي في تقليص Agency.

ما الذي يجب أن ترتبط به هوية الوكيل؟

يفضل أن ترتبط الهوية بـ:

• Agent محدد.
• Workload محدد.
• Purpose محدد.
• Credential Scope محدد.
• Expiry واضح.
• Audit Trail مستقل.
• Revocation Method.
• Environment محدد.

الهدف هو أن تكون السلطة قابلة للقياس والعزل.

Machine Identity ليست تفصيلًا تقنيًا

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

هذا مهم خصوصًا عند:

• API Calls.
• Database Access.
• Cloud Actions.
• File Operations.
• MCP Tool Calls.
• Workflow Execution.

الهوية المشتركة توسع Blast Radius وتضعف Accountability.

Least Agency وMCP

MCP قد يوسع قدرات Agent بسرعة كبيرة.

إضافة MCP Server واحد قد تمنح النظام الوصول إلى:

• البريد.
• الملفات.
• Git.
• قواعد البيانات.
• SaaS.
• APIs.
• Cloud Resources.

لذلك يجب ألا يكون السؤال:

هل MCP Server موثوق؟

فقط.

بل أيضًا:

هل يحتاج Agent كل الأدوات التي يعرضها هذا MCP Server؟

قراءة سيادة: MCP Exposure

يمكن أن يكون MCP Server آمنًا بحد ذاته، لكن Tool Exposure تكون أوسع من حاجة Agent.

Least Agency يتطلب:

• Allowlist للأدوات.
• Scope لكل Tool.
• Read-only حيث يكفي.
• منع الأدوات غير اللازمة.
• Credential منفصلة.
• Logging مستقل.
• Revocation.
• Review عند إضافة Tool جديدة.

إذا عرض MCP عشرين Tool ويحتاج Agent ثلاثًا فقط، فلا يوجد سبب حوكمي للسماح بالعشرين.

Least Agency وHuman Oversight

الإشراف البشري لا يعني بالضرورة أن كل إجراء يحتاج موافقة.

لكن يجب ربط مستوى الإشراف بمستوى الأثر.

يمكن تصور نموذج مثل:

Low-impact action → Automated

Medium-impact action → Threshold-based approval

High-impact action → Explicit human approval

Critical action → Segregated approval + independent execution

الفكرة هي ألا تستخدم Human-in-the-Loop كحل شكلي، بل كجزء من تصميم السلطة.

Human Oversight لا يعالج Excess Agency وحده

وجود موافقة بشرية فوق Agent واسع الصلاحيات لا يعني أن التصميم أصبح جيدًا.

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

• قراءة كل البيانات.
• استخدام كل الأدوات.
• الاتصال بكل الأنظمة.

ثم يطلب موافقة على خطوة واحدة فقط، فقد يبقى جزء كبير من Agency غير مضبوط.

لذلك يجب تقليص السلطة نفسها أولًا.

ثم استخدام Human Oversight كضابط إضافي.

Least Agency وKill Switch

كلما زادت Agency، زادت أهمية القدرة على إيقافها.

Kill Switch يجب أن يكون قادرًا فعليًا على:

• إلغاء Credential.
• تعطيل Agent.
• إيقاف Workflow.
• قطع Network Access.
• تعطيل Tool.
• منع Write.
• عزل النظام.
• إيقاف Integration.

ولا ينبغي أن يعتمد فقط على Prompt داخل النظام نفسه.

قراءة سيادة: Revocable Agency

Least Agency لا يتعلق فقط بكمية السلطة.

بل أيضًا بمدى سهولة سحبها.

السلطة الجيدة حوكميًا يجب أن تكون:

• محدودة.
• قابلة للمراقبة.
• قابلة للانتهاء.
• قابلة للإلغاء.
• قابلة للعزل.

إذا كانت صلاحية Agent لا يمكن إلغاؤها بسهولة، فهي Agency أصعب في السيطرة.

Least Agency وLethal Trifecta

مبدأ Least Agency من أهم الطرق لتقليل احتمالية ظهور Lethal Trifecta.

الثلاثية القاتلة تتطلب اجتماع:

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

يمكن لـLeast Agency كسر هذا المسار عبر:

• تقليل Data Scope.
• تقليل Tool Scope.
• تقليل Network Scope.
• منع External Egress.
• إزالة Write أو Execute.
• تقليل Autonomy.
• إضافة Approval Boundary.

وهنا يظهر أن Least Agency ليس مبدأ عامًا فقط، بل أداة معمارية.

مثال: وكيل بريد إلكتروني

افترض Agent يستطيع:

• قراءة البريد.
• قراءة CRM.
• إنشاء رد.
• إرسال البريد.

هذا Agent قد يملك Agency واسعة.

يمكن تقليصها إلى:

• قراءة الرسالة الحالية فقط.
• الوصول إلى حقول CRM محددة.
• إنشاء Draft فقط.
• منع الإرسال التلقائي.
• منع المرفقات الحساسة.
• منع الإرسال إلى Domains غير معتمدة.

كل تغيير هنا يقلل مساحة الضرر الممكن.

مثال: Agent لتحليل بيانات داخلية

Agent يحتاج تحليل Dataset داخلية.

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

• Internet.
• Email.
• External APIs.
• File Upload.
• Production Write.
• Admin Access.

إذا حرم من هذه القدرات، يصبح مسار الهجوم المحتمل أضيق بكثير.

Least Agency وفصل الواجبات

يمكن تطبيق Segregation of Duties على Agents كما يطبق على البشر.

مثلًا:

Agent A → Reads external input

Agent B → Performs internal analysis

Service C → Executes approved action

Human D → Approves critical change

الفكرة هي منع كيان واحد من امتلاك كامل المسار.

قراءة سيادة: Agentic Segregation of Duties

يمكن تقسيم الوظائف بين:

• Input.
• Analysis.
• Recommendation.
• Approval.
• Execution.
• Verification.

لكن يجب التأكد من أن الفصل حقيقي.

إذا كانت كل Agents تستخدم Credential نفسها أو تستطيع استدعاء بعضها بلا ضوابط، فقد يكون الفصل شكليًا.

Least Agency وReversibility

Agency يجب أن تتأثر أيضًا بقابلية التراجع عن الفعل.

الأفعال التالية ليست متساوية:

• Draft.
• Send.
• Modify.
• Delete.
• Publish.
• Transfer.
• Change Permission.
• Execute Production Command.

كلما قلّت Reversibility، يجب أن تقل Agency المتاحة تلقائيًا.

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

يمكن اعتبار الأفعال غير القابلة للتراجع Boundary خاصة.

عند تجاوزها، يمكن فرض:

• Human Approval.
• Dual Approval.
• Independent Validation.
• Separate Execution Service.
• Stronger Authentication.
• Temporary Credential.

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

Least Agency وAI-BOM

AI-BOM يمكن أن يكون المصدر الذي يوضح أين توجد Agency.

لكل Agent يمكن ربط:

• Data Sources.
• Tools.
• APIs.
• MCP Servers.
• Credentials.
• Network Access.
• Target Systems.
• Approval Requirements.

إذا كان AI-BOM يوضح هذه العناصر، يصبح من الممكن تقييم Least Agency بصورة عملية بدل الاعتماد على وصف عام.

قراءة سيادة: Agency Surface

يمكن تصور Agency Surface على أنها مجموع نقاط السلطة المتاحة للنظام.

تشمل:

• Data.
• Tools.
• Actions.
• Network.
• Autonomy.
• Time.
• Identities.
• Dependencies.

الهدف ليس الوصول إلى Agency = Zero.

الهدف هو:

Minimum Effective Agency

أي أقل Agency تحقق الهدف المعتمد بصورة موثوقة.

نموذج تقييم Least Agency

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

• Data Scope.
• Tool Scope.
• Action Scope.
• Network Scope.
• Autonomy Scope.
• Time Scope.

لكل بُعد، اسأل:

• ما المطلوب فعليًا للمهمة؟
• ما المتاح فعليًا في البيئة؟
• ما الفرق بين الاثنين؟
• هل الفرق مبرر؟
• هل توجد ضوابط تقلص الأثر؟

هذا الفرق هو مكان البحث عن Excess Agency.

Baseline عملي

يمكن بناء Baseline لكل Agent يحتوي على:

• Approved Purpose.
• Approved Data Sources.
• Approved Tools.
• Approved Actions.
• Approved Network Destinations.
• Approved Autonomy Level.
• Approved Time Window.
• Approved Identity.
• Required Human Approvals.
• Required Monitoring.
• Revocation Method.
• Kill Switch.

هذا يجعل المبدأ قابلًا للتدقيق.

بدل أن تقول المؤسسة:

"لدينا Least Agency"

يمكنها إظهار:

"هذه هي Agency المعتمدة لهذا Agent، وهذه هي القيود التقنية التي تفرضها."

مصفوفة بسيطة للسلطة

يمكن توثيق كل Agent بهذه الصورة:

Data → ماذا يقرأ؟

Tools → ماذا يستطيع استخدامه؟

Actions → ماذا يستطيع فعله؟

Network → إلى أين يستطيع الاتصال؟

Autonomy → ماذا يستطيع تنفيذ دون موافقة؟

Time → متى تنتهي الصلاحية؟

Identity → بأي هوية ينفذ؟

Approval → أين يتوقف للمراجعة؟

هذه المصفوفة تساعد على رؤية السلطة الكاملة للنظام.

مؤشرات Excess Agency

هناك إشارات شائعة تدل على أن Agent يملك Agency أوسع من الحاجة.

منها:

• Full database access لمهمة محدودة.
• Write Permission بينما Read يكفي.
• Internet access دون حاجة واضحة.
• عدد كبير من Tools غير المستخدمة.
• Shared admin credential.
• Long-lived credential.
• Full autonomy لفعل عالي الأثر.
• Ability to delete.
• Ability to publish externally.
• Ability to change permissions.
• Ability to invoke other Agents بلا قيود.
• MCP Server يعرض أدوات أكثر من المطلوب.
• Human approval موجود بعد تنفيذ جزء حساس بالفعل.

كل واحدة من هذه الإشارات تستحق مراجعة.

Excess Agency لا تعني دائمًا خطأ فوريًا

قد توجد حالات تحتاج Agency أوسع.

لكن يجب أن تكون:

• مبررة.
• موثقة.
• محدودة.
• مراقبة.
• قابلة للإلغاء.
• مرتبطة بمدة.
• خاضعة لمراجعة دورية.

الفرق بين Agency المقبولة وExcess Agency هو وجود مبرر وضابط واضحين.

أسئلة Architecture Review

عند مراجعة Agent، اسأل:

1. ما الهدف المعتمد للوكيل؟
2. ما أقل Data Scope يحقق هذا الهدف؟
3. ما أقل Tool Set مطلوب؟
4. ما أقل Action Scope مطلوب؟
5. هل يحتاج Write أصلًا؟
6. هل يحتاج Execute؟
7. هل يحتاج Internet؟
8. هل يحتاج External Email؟
9. هل يحتاج MCP؟
10. ما أقل Autonomy Level مناسب؟
11. أين يجب وضع Human Approval؟
12. هل الصلاحيات دائمة أم مؤقتة؟
13. ما الهوية التي يستخدمها؟
14. هل يمكن إلغاء Credential فورًا؟
15. هل يمكن تعطيل Tool محددة دون إيقاف النظام كله؟
16. هل توجد Action غير قابلة للتراجع؟
17. هل يحتاج Agent الوصول إلى Secrets؟
18. هل يمكن فصل بعض الوظائف إلى خدمة مستقلة؟
19. هل توجد Tools لا تستخدمها المهمة؟
20. هل يمكن إثبات كل ذلك من Configuration فعلية؟

أسئلة مراجعة Data Scope

راجع:

• هل Agent يرى أكثر مما يحتاج؟
• هل يمكن استخدام Views محددة؟
• هل يمكن تطبيق Row-level filtering؟
• هل يمكن إخفاء الحقول الحساسة؟
• هل يستطيع الوصول إلى Historical Data غير لازمة؟
• هل يستطيع الوصول إلى بيانات أقسام أخرى؟
• هل Memory تحتوي بيانات أوسع من المهمة الحالية؟

أسئلة مراجعة Tool Scope

راجع:

• كم Tool متاحة؟
• كم Tool تستخدم فعليًا؟
• هل Tool واسعة الغرض؟
• هل يمكن بناء Tool أضيق؟
• هل يوجد Write Tool بينما Read Tool تكفي؟
• هل MCP Server يعرض أدوات غير لازمة؟
• هل يمكن تطبيق Tool Allowlist؟

أسئلة مراجعة Action Scope

راجع:

• هل Agent يستطيع Approve؟
• هل يستطيع Execute؟
• هل يستطيع Delete؟
• هل يستطيع Publish؟
• هل يستطيع Change Permissions؟
• هل يستطيع Create Users؟
• هل يستطيع Send Money؟
• هل يستطيع Modify Production؟

كل Action عالية الأثر يجب أن يكون لها سبب واضح.

أسئلة مراجعة Network Scope

راجع:

• هل يحتاج Internet Access؟
• هل يمكن استخدام Allowlist؟
• هل يحتاج الوصول إلى كل Domains؟
• هل يمكن منع Upload؟
• هل يمكن تقييد Webhooks؟
• هل هناك External Storage؟
• هل MCP ينشئ Egress غير واضح؟

أسئلة مراجعة Autonomy Scope

راجع:

• هل Agent يقترح أم ينفذ؟
• هل توجد Thresholds؟
• ما الأفعال التي تحتاج Approval؟
• هل يمكن تحويل التنفيذ إلى Service مستقلة؟
• هل Autonomy أعلى من أثر المهمة؟

أسئلة مراجعة Time Scope

راجع:

• هل Credential طويلة العمر؟
• هل يمكن استخدام Short-lived Token؟
• هل يمكن منح Access أثناء المهمة فقط؟
• هل الصلاحية تنتهي تلقائيًا؟
• هل يمكن Revoke فورًا؟

Change Triggers

Least Agency يجب ألا يراجع مرة واحدة فقط.

أعد التقييم عند:

• إضافة Tool جديدة.
• إضافة MCP Server.
• إضافة Data Source.
• توسيع IAM Role.
• إضافة Write Access.
• تفعيل Internet Access.
• إضافة External API.
• رفع Autonomy Level.
• إزالة Human Approval.
• تغيير Workflow.
• تغيير Agent Identity.
• إضافة Agent جديد.
• تغيير Use Case.
• زيادة Criticality.

أي تغيير يوسع السلطة يستحق Revalidation.

قراءة سيادة: Agency Change as a Governance Event

من منظور سيادة، توسيع Agency ليس مجرد تغيير تقني.

إذا حصل Agent على:

• Data أكثر.
• Tool أكثر.
• صلاحية أوسع.
• اتصال خارجي جديد.
• Autonomy أعلى.
• مدة وصول أطول.

فقد تغير ملف المخاطر حتى لو بقي النموذج نفسه.

لذلك يجب التعامل مع توسع Agency كحدث حوكمي يستدعي المراجعة.

Least Agency والتدقيق

يمكن للمدقق اختبار المبدأ بدل الاكتفاء بسؤال الإدارة عنه.

يمكن طلب:

• IAM Roles.
• API Scopes.
• Tool Inventory.
• MCP Configuration.
• Network Policies.
• Credentials.
• Approval Rules.
• Workflow Configuration.
• Audit Logs.
• Expiry Settings.

ثم مقارنة الحالة الفعلية مع Baseline المعتمد.

اختبارات تدقيق عملية

اسأل:

• هل Agent يملك Tool غير مذكورة في التصميم؟
• هل يستطيع الوصول إلى System غير معتمد؟
• هل IAM Scope أوسع من الحاجة؟
• هل Network Egress أوسع من القائمة المسموحة؟
• هل توجد Credential مشتركة؟
• هل انتهت صلاحية Access يفترض أنها مؤقتة؟
• هل يمكن تنفيذ Action عالية الأثر دون Approval؟
• هل يمكن إلغاء Agency فعليًا؟
• هل الـMCP Tools الفعلية تطابق المعتمدة؟
• هل هناك اختلاف بين AI-BOM والبيئة الفعلية؟

اختبار الفشل

Least Agency يجب أن يقاس أيضًا عبر سؤال:

إذا فشل Agent، ما أقصى ضرر يستطيع إحداثه؟

هذا السؤال أقوى من:

هل نتوقع أن يتصرف بشكل صحيح؟

صمم السلطة على افتراض أن:

• النموذج قد يخطئ.
• Prompt Injection قد ينجح.
• Tool قد تعيد نتيجة خبيثة.
• المستخدم قد يسيء الاستخدام.
• Integration قد تتغير.

ثم قلل Blast Radius.

قراءة سيادة: Maximum Credible Agency

يمكن للمؤسسة أن تسأل:

ما أقصى Agency يستطيع النظام ممارستها في أسوأ حالة معقولة؟

هذه القراءة تختلف عن Intended Agency.

Intended Agency هي ما نتوقع أن يفعله النظام.

Maximum Credible Agency هي ما يستطيع فعله فعليًا ضمن صلاحياته الحالية إذا ساءت الظروف.

الفجوة بينهما مؤشر مهم للمخاطر.

مثال: Agent الموارد البشرية

افترض Agent يساعد في الرد على أسئلة الموظفين.

الهدف:

الإجابة عن السياسات.

Agency مناسبة قد تكون:

• Read access إلى Knowledge Base محددة.
• لا وصول إلى Payroll.
• لا وصول إلى ملفات الموظفين.
• لا Write.
• لا External Email.
• لا Internet.
• لا تنفيذ قرارات HR.

إذا منح النظام صلاحيات أوسع، تصبح Agency غير مرتبطة بالمهمة.

مثال: Agent مالي

Agent يراجع فواتير.

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

• قراءة Invoice.
• قراءة Purchase Order.
• مقارنة القيم.
• Flag discrepancies.
• إنشاء Recommendation.

ليس بالضرورة:

• Approve Payment.
• Execute Transfer.
• Modify Vendor Bank Details.

فصل هذه الوظائف يقلل الأثر.

مثال: Agent أمني

Agent يحلل Alerts.

قد يحتاج:

• Read Logs.
• Query SIEM.
• Open Ticket.

لكن قد لا يحتاج:

• Disable Accounts.
• Block Firewall Rules.
• Delete Logs.
• Execute Shell on Production.

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

Progressive Agency

يمكن منح Agency تدريجيًا بدل منح أعلى مستوى من اليوم الأول.

مثال:

Phase 1 → Suggest

Phase 2 → Draft

Phase 3 → Execute with Approval

Phase 4 → Execute within Narrow Policy

هذا يسمح للمؤسسة ببناء الثقة والضوابط تدريجيًا.

Least Agency وContinuous Validation

Agency قد تتغير مع الزمن.

حتى دون تغيير التصميم الرسمي، يمكن أن يحدث:

• Permission Drift.
• Tool Addition.
• Credential Expansion.
• Network Change.
• MCP Change.
• Workflow Change.

لذلك يجب مقارنة Baseline بالحالة الفعلية بصورة دورية.

ما الذي لا يقوله Least Agency؟

Least Agency لا يعني:

• إزالة كل Autonomy.
• جعل كل Agent عديم الفائدة.
• طلب موافقة بشرية على كل خطوة.
• منع استخدام الأدوات.
• منع الاتصال الخارجي دائمًا.
• أن Least Privilege وحده يكفي.
• أن تقليل Agency يلغي جميع مخاطر AI.

المبدأ يعني:

امنح النظام أقل سلطة فعالة تحقق الهدف المعتمد.

أخطاء شائعة

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

• الاعتماد على Prompt لتقييد السلطة.
• استخدام Shared Credentials.
• منح Tools كثيرة "للمستقبل".
• السماح بـWrite بينما Read يكفي.
• Internet Access عام بلا حاجة.
• اعتبار MCP Trusted بالكامل.
• Full Autonomy منذ البداية.
• عدم استخدام Expiry.
• Human Approval شكلي.
• عدم وجود Kill Switch.
• عدم مراقبة Tool Calls.
• عدم إعادة التقييم بعد التغيير.
• عدم مقارنة Baseline بالواقع.
• تجاهل Irreversible Actions.
• اعتبار Least Agency مرادفًا لـLeast Privilege فقط.

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

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

• هل Purpose محدد؟
• هل Data Scope هو الأدنى؟
• هل Tool Scope هو الأدنى؟
• هل Action Scope هو الأدنى؟
• هل Network Scope هو الأدنى؟
• هل Autonomy Scope مناسب؟
• هل Time Scope محدود؟
• هل Agent Identity مستقلة؟
• هل Credentials قصيرة ومحدودة؟
• هل Approval Boundaries واضحة؟
• هل Kill Switch موجود؟
• هل Logging يغطي الأفعال؟
• هل MCP Scope مقيد؟
• هل هناك Revalidation Triggers؟
• هل AI-BOM يعكس Agency الفعلية؟

الخلاصة

Least Agency هو انتقال من سؤال:

ما الذي يمكننا أن نجعل Agent يفعله؟

إلى سؤال أكثر أهمية:

ما أقل قدر من السلطة يحتاجه فعلًا؟

في Agentic AI، السلطة لا تتكون من Permission واحدة.

هي مجموع:

• البيانات.
• الأدوات.
• الأفعال.
• الشبكة.
• الاستقلالية.
• الزمن.
• الهوية.
• التكاملات.

كل عنصر زائد يوسع Blast Radius.

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

المرجع

تعريف Least Agency المستخدم في هذا المقال هو مفهوم تشغيلي تستخدمه سيادة AI في حوكمة الأنظمة الوكيلية.

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

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

هذه المادة قراءة تطبيقية من سيادة AI، وليست تعريفًا رسميًا لمصطلح Least Agency صادرًا عن PCI SSC.