سلطة الوكيل
نطاق السلطة المؤسسية المفوضة لوكيل ذكاء اصطناعي لاتخاذ قرارات أو تنفيذ أفعال باسم المؤسسة ضمن حدود وشروط معتمدة.
شرح تفصيلي
سلطة الوكيل (Agent Authority) هي مجموعة الحقوق التشغيلية التي تمنح لوكيل الذكاء الاصطناعي كي يقرر أو ينفذ أفعالًا ضمن هدف محدد، نيابةً عن شخص أو مؤسسة، وبحدود يمكن إنفاذها ومراجعتها وسحبها. لا تعني السلطة مجرد أن النظام يستطيع الوصول تقنيًا إلى أداة أو مورد؛ بل تعني أن هناك تفويضًا مشروعًا يبرر الفعل، وأن هذا التفويض مقيد بنطاق وغرض وشروط ومسؤولية واضحة. ## القدرة ليست سلطة أهم تمييز في حوكمة Agentic AI هو الفصل بين Capability وAuthority. القدرة تصف ما يستطيع النظام فعله تقنيًا، مثل قراءة ملف أو تشغيل API أو إرسال بريد أو تنفيذ معاملة. السلطة تصف ما يحق له فعله ضمن مهمة محددة. قد يكون الوكيل قادرًا على حذف سجل لأن الـAPI يسمح بذلك، لكن لا يملك سلطة الحذف. وقد يكون قادرًا على إجراء دفع، لكن تفويضه يقتصر على إعداد مسودة أمر شراء. هذا الفصل يمنع خطأ شائعًا: تحويل كل permission تقنية إلى حق تشغيلي ضمني. ## مصدر السلطة يجب أن يكون لكل سلطة مصدر واضح. من الذي فوض الوكيل؟ هل التفويض صادر من مستخدم، مدير، مالك عملية، نظام سياسات، أو قرار مؤسسي؟ يجب أن يسجل النظام Delegator أو Authority Source، لأن المساءلة لاحقًا تعتمد على معرفة من منح القدرة على التصرف ولماذا. الوكيل لا يخلق سلطته بنفسه، ولا يفترض أن له حق تنفيذ فعل فقط لأنه اكتشف أداة قادرة عليه. ## عناصر Agent Authority تتكون السلطة من عدة عناصر مترابطة: - **Objective:** الهدف الذي مُنحت السلطة لتحقيقه. - **Scope:** الموارد والأنظمة والبيانات التي يشملها التفويض. - **Actions:** الأفعال المسموحة أو المشروطة أو الممنوعة. - **Limits:** حدود القيمة والحجم والتكرار والوقت. - **Autonomy:** إلى أي درجة يمكن التنفيذ دون تدخل بشري. - **Delegation:** هل يمكن تمرير جزء من السلطة لوكيل آخر؟ - **Evidence:** ما الذي يجب تسجيله لإثبات أن الفعل كان مشروعًا؟ - **Revocation:** كيف تُسحب السلطة فورًا عند الحاجة؟ ## السلطة مقابل الوصول Access Control يجيب: هل يمكن لهذه الهوية الاتصال بالمورد؟ Agent Authority يجيب: هل يحق لها تنفيذ هذا الفعل في هذا السياق؟ قد يكون للوكيل read/write access تقني، لكن حوكمة السلطة تسمح بالقراءة وتمنع الكتابة إلا بعد approval. لذلك IAM وحده لا يكفي، رغم أنه جزء أساسي من enforcement. ## السلطة مقابل الاستقلالية السلطة تحدد ما هو مسموح، بينما الاستقلالية تحدد مقدار القرار والتنفيذ الذي يستطيع الوكيل القيام به وحده داخل المسموح. يمكن أن يمتلك الوكيل سلطة إعداد عقد، لكن لا يمتلك استقلالية إرساله. ويمكن أن يمتلك سلطة إعادة ضبط كلمة مرور منخفضة الخطورة مع استقلالية كاملة ضمن شروط محددة. من الخطأ استخدام كلمة Autonomous كبديل عن Authority؛ هما بعدان مختلفان. ## Authority Envelope حتى تصبح السلطة قابلة للتطبيق، يجب ترجمتها إلى Authority Envelope: حدود تشغيلية صريحة تشمل نوع الفعل والمورد والسياق والحدود الكمية والزمنية ونقاط الموافقة. هذا النطاق هو الشكل التنفيذي للسلطة. السلطة غير المقيدة بEnvelope تتحول إلى تفويض فضفاض يصعب اختباره أو تدقيقه. ## Transaction Authority عندما يترتب على الفعل التزام مالي أو قانوني أو تغيّر في الحقوق أو الصلاحيات، تصبح Transaction Authority طبقة خاصة. هنا لا يكفي read/write. يجب تحديد من يستطيع الاعتماد، القيمة القصوى، المستفيدين المسموحين، الفصل بين الاقتراح والتنفيذ، حدود التكرار والقيمة التراكمية، وآليات الإيقاف. ## Delegated Authority بين الوكلاء في الأنظمة متعددة الوكلاء، لا يجب أن يرث Sub-agent سلطة الوكيل الرئيسي تلقائيًا. كل تفويض فرعي يحتاج scope وpurpose وexpiry وهوية واضحة. إذا امتلك الوكيل الرئيسي صلاحية واسعة ثم مرر token أو credential لوكيل فرعي، فقد تنشأ سلطة فعلية أكبر من التصميم الأصلي. يجب قياس Effective Authority للنظام المركب، لا صلاحيات كل Agent بمعزل. ## السلطة والـMCP إضافة MCP Server أو أداة خارجية قد توسع Action-Space وتمنح النظام قدرة جديدة. لذلك أي Tool Onboarding يجب أن يراجع أثره على السلطة. هل الأداة تضيف write؟ هل تسمح بإرسال بيانات؟ هل تشغّل أوامر؟ هل تصل إلى نظام جديد؟ هل تستطيع استدعاء طرف ثالث؟ الأداة ليست مجرد integration؛ قد تكون بوابة Authority جديدة. ## السلطة المشروطة يمكن للسلطة أن تكون Conditional. مثال: يسمح للوكيل بإجراء فعل فقط إذا كانت القيمة تحت حد معين، المستخدم مصادقًا عليه، المورد معتمدًا، ولا توجد إشارة خطر. إذا فشل شرط واحد ينتقل الفعل إلى Human Approval أو يصبح ممنوعًا. هذه السياسات تحتاج Enforcement واضحًا، لا تعليمات نصية فقط. ## السلطة والـPrompt System Prompt يمكن أن يوجه السلوك، لكنه لا يمثل Authority Control كافيًا. إذا كان الوكيل قادرًا على الوصول إلى API خطرة، فلا يكفي أن تقول له "لا تستخدمها إلا عند الحاجة". يجب تقييد الـAPI نفسها، scope، allowlist، approval، transaction limit أو runtime policy. ## إثبات السلطة Audit trail الجيد يجب أن يربط كل فعل بـ: Identity → Delegator → Authority Rule → Resource → Context → Decision → Approval → Action → Result. عند وقوع incident، يجب أن نعرف هل الوكيل تجاوز سلطته، أم أن السلطة نفسها كانت مصممة بشكل سيئ. ## Authority Drift تتغير الأنظمة مع الوقت. يضاف Tool، يتغير API، يتوسع المستخدمون، أو تضاف بيئة جديدة. إذا لم نراجع authority بعد كل تغيير، قد تصبح Effective Authority أوسع من Approved Authority. هذا يسمى Authority Drift. يجب أن تكون هناك مقارنة دورية بين approved envelope وeffective permissions وactual actions. ## سحب السلطة كل سلطة يجب أن تكون قابلة للسحب. يجب أن نعرف كيف نوقف execution، نلغي credentials، نعطل tool calls، نمنع outbound actions ونحفظ الأدلة. سلطة لا يمكن سحبها بسرعة هي مخاطر تشغيلية حتى لو كان الهدف مشروعًا. ## السلطة المؤقتة يفضل ربط السلطة بمهمة أو جلسة أو مدة. صلاحية دائمة لوكيل يستخدم أحيانًا فقط توسع سطح المخاطر بلا حاجة. عند انتهاء المهمة يجب أن تنتهي السلطة أو تحتاج تجديدًا. ## توزيع المسؤولية Agent Authority لا تنقل المسؤولية إلى الآلة. يجب أن يبقى هناك مالك للـuse case، جهة تمنح التفويض، جهة تشرف، ومسؤول عن المراجعة والتغيير. عبارة "الAgent فعل ذلك" ليست نهاية سلسلة المساءلة. ## في نموذج سيادة تقع Agent Authority ضمن السلسلة: Objective → Delegation → Authority → Identity → Access → Decision → Action → Transaction → Evidence → Oversight → Intervention → Accountability. السلطة هي الجسر بين قرار المؤسسة بتفويض مهمة وبين ما يسمح للنظام أن يفعله فعليًا. إذا كانت هذه الحلقة غامضة، فإن الهوية والوصول والمراقبة تصبح ضوابط منفصلة دون منطق موحد. ## مؤشرات ضعف السلطة من العلامات: حساب مشترك؛ صلاحيات دائمة؛ عدم وجود delegator؛ غياب limits؛ عدم الفصل بين read/write/execute/transact؛ السماح للوكيل بإضافة أدوات بنفسه؛ تفويض فرعي غير مراقب؛ approval شكلي؛ أو عدم وجود سجل يربط الفعل بقاعدة authority. ## مثال تطبيقي وكيل مالي يمكنه قراءة فواتير، مطابقة أوامر شراء، وإعداد مسودة دفع. لكنه لا يستطيع إضافة مستفيد جديد، تغيير حساب بنكي، أو تنفيذ دفعة فوق حد معين دون موافقة. هذه ليست مجرد Permissions؛ هي تصميم Authority يربط كل فعل بغرض وحد وحدود ومسؤولية. ## الخلاصة Agent Authority هي قرار مؤسسي قابل للتنفيذ حول ما الذي يحق للوكيل فعله. كلما زادت قدرة الوكيل على التأثير في العالم الحقيقي، يجب أن تصبح السلطة أكثر تحديدًا، وأقصر مدة، وأقوى إنفاذًا، وأكثر قابلية للتدقيق والسحب. الحوكمة الناضجة لا تسأل فقط: "ماذا يستطيع الوكيل؟" بل: "من سمح له، لماذا، ضمن أي حدود، وكيف نثبت ذلك؟" ## سؤال التدقيق الحاسم عند مراجعة أي Agent Authority اسأل: لو نفذ الوكيل هذا الفعل غدًا، هل أستطيع أن أثبت من منحه السلطة، أي قاعدة سمحت بالفعل، ما الحدود التي كانت سارية، وما إذا كان التنفيذ داخلها؟ إذا كانت الإجابة تعتمد على تفسير يدوي أو على prompt غير موثق، فالسلطة غير ناضجة تشغيليًا. ## مبدأ الحد الأدنى من السلطة كما نطبق least privilege على الوصول، يجب تطبيق least authority على الفعل. امنح الوكيل أقل مجموعة من الأفعال اللازمة لتحقيق الهدف، لأقصر مدة، وعلى أضيق موارد. كل قدرة إضافية يجب أن يكون لها سبب عمل موثق. هذا يقلل blast radius عند الخطأ أو إساءة الاستخدام أو اختراق الوكيل. ## مراجعة دورية يجب أن تكون Agent Authority جزءًا من access/authority recertification. عند تغير الوظيفة أو مالك العملية أو الأداة أو المورد أو مستوى المخاطر، لا يكفي بقاء الصلاحية القديمة لأنها كانت صحيحة في الماضي. السلطة قرار حي يحتاج تجديدًا أو تقليصًا أو سحبًا.
مثال عملي
وكيل مالي يستطيع قراءة الفواتير وإعداد مسودة دفع، لكنه لا يملك سلطة إضافة مستفيد جديد أو تنفيذ دفعة تتجاوز حدًا معينًا دون موافقة بشرية.