يجب فرض صلاحيات AI Agent بشكل حتمي

يجب أن تحتوي صلاحيات AI Agent على الأخطاء حتى عندما يتخذ النموذج القرار الخاطئ. تصميم الإنتاج واضح: امنح كل تشغيل مجموعة قدرات ضيقة، وطبّقها خارج النموذج، واحجز الموافقة البشرية للإجراءات ذات العواقب، وسجّل أدلة كافية للتحقق مما حدث.

الجمهور: الممارسون المتقدمون الذين يبنون agents تستخدم الأدوات، أو coding agents، أو MCP servers.

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

ما الذي يجب أن تتحكم فيه صلاحيات AI Agent

يقرر نظام صلاحيات agent ما إذا كان متصل محدد يستطيع تنفيذ إجراء محدد على مورد محدد في ظل الظروف الحالية. عبارة «يمكن للـ agent استخدام GitHub» واسعة جدًا. يجب أن يتضمن القرار المفيد على الأقل:

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

يساعد فصل هذه الأدوار أيضًا في إبقاء عزل الأسرار صادقًا. يستطيع وسيط بيانات الاعتماد إخفاء API key عن النموذج مع الاستمرار في إتاحة كل عملية تسمح بها تلك key. يحمي الوسيط السر؛ بينما تحمي policy المقيّدة بالإجراء المورد.

ما الذي قاسه أحدث بحث في الصلاحيات

راجعت مسودة بحثية منشورة في يوليو 2026 بعنوان *How Agents Ask for Permission* عددًا من أنظمة واقتراحات صلاحيات agent بلغ 21 نظامًا، نُشرت أو أُطلقت بين عامي 2024 و2026. كما استعرض المؤلفون خمسة agents تجارية في إعدادات معزولة خلال أواخر مايو وأوائل يونيو.

يكشف تصنيفهم عن توتر هندسي ثلاثي:

تصف هذه الأعداد عينة المؤلفين، لا السوق بأكمله. استخدمت المراجعة أسلوب أخذ عينات بالتتابع، وشملت مسودات بحثية ومنتجات تجارية، ولم تتمكن من فحص المكونات الداخلية مغلقة المصدر. تظل الورقة مفيدة لأنها تفصل واجهة الصلاحيات عن policy وآلية الفرض. لا يمكن لحوار موافقة مصقول أن يعوض policy غامضة أو قرارًا غير مفروض.

تعكس الأدوات التجارية بالفعل جزءًا من هذا الفصل. تسمح وثائق Claude Code بقواعد السماح والسؤال والرفض، بينما تصف وثائق sandbox الخاصة به حدودًا على مستوى نظام التشغيل للملفات والشبكة. وبالمثل، تتعامل إرشادات OpenAI الأمنية الخاصة بـ Codex مع sandbox باعتباره حدًا تقنيًا، ومع approval policy باعتبارها النقطة التي قد يُطلب فيها من المستخدم اتخاذ قرار. هذه ضوابط خاصة بالمنتجات، وليست دليلًا على أن كل عملية نشر تضبطها بأمان.

إرهاق الموافقات مشكلة توجيه

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

تدرّب المطالبات منخفضة المخاطر المتكررة الأشخاص على النقر لتجاوزها. أفادت Anthropic بانخفاض قدره 84% في مطالبات الصلاحيات بعد طرح sandbox داخليًا، لكن هذه نتيجة تشغيلية أبلغت عنها الشركة وليست معيارًا مستقلًا. الدرس المستدام أضيق نطاقًا: يمكن للعمل المعتمد مسبقًا داخل حد مفروض أن يقلل المقاطعات دون منح agent وصولًا عامًا.

وجّه الإجراءات إلى أربع نتائج:

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

بنية صلاحيات من خمس طبقات

تتكون أصغر بنية موثوقة من خمس طبقات متميزة. يؤدي دمجها إلى جعل عمليات التدقيق أصعب وإنشاء مسارات تفشل بطريقة تسمح بالمرور.

*يقترح النموذج إجراءً. وتظل policy والفرض والتنفيذ والأدلة منفصلة.*

1. تطبيع الإجراء المقترح

حوّل استدعاء أداة مولدًا من النموذج إلى طلب ذي نوع قبل التفويض:

{ "actor": "agent-run-7f3", "on_behalf_of": "user-42", "action": "blog.publish", "resource": "post:ai-agent-permissions", "constraints": { "environment": "production", "language": "en" } }

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

2. تقييم policy خارج النموذج

أعد قرارًا حتميًا: `allow` أو `ask` أو `deny`. أدرج قاعدة policy ووقت الانتهاء. يمكن للنموذج المساعدة في تصنيف طلب جديد، لكن لا ينبغي لهذا التصنيف أن يمنح الوصول بمفرده. يجب أن تفشل الإجراءات غير المعروفة بطريقة مغلقة.

3. فرض القرار عند التنفيذ

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

تطبق مواصفة تفويض MCP المبدأ نفسه على access tokens: يجب على servers التحقق من أن token صدر للجمهور المقصود. وتحظر إرشادات MCP الأمنية صراحةً تمرير token لأنها قد تكسر ذلك الحد.

4. التنفيذ عبر أدوات ضيقة

فضّل `publish_draft(post_id)` على `run_sql(query)`، و`send_invoice(invoice_id)` على `http_request(url, body)`. تجعل الأدوات الضيقة policy قابلة للقراءة وتقلص مساحة الإجراءات غير المقصودة.

يظهر الاستدلال نفسه المتعلق بطبقة التحكم في MCP Developer Workflows: The Real Control Layer: إذ يحدد شكل الأداة، وبوابات الموافقة، والإجراءات القابلة لإعادة التشغيل ما يستطيع agent فعله بأمان.

5. تسجيل إيصال ودعم الإلغاء

سجّل الإجراء المطلوب، وقرار policy، وهوية الموافق، وملخص إدخال الأداة، وفئة النتيجة، والحالة اللاحقة. احجب الأسرار والحمولات الحساسة. يجب أن يتمكن المستخدم من إلغاء منح قائم دون إعادة بناء agent.

يجب أن يميز الإيصال بين «أعادت الأداة نتيجة» و«الحالة المقصودة موجودة». فاستجابة HTTP 200، أو استدعاء SDK ناجح، أو رسالة نهائية واثقة ليست حالة لاحقة.

تعامل مع عمليات كتابة الذاكرة باعتبارها إجراءات مميزة

تغير الذاكرة الدائمة السلوك المستقبلي، لذلك تحتاج عمليات كتابة الذاكرة إلى مسار صلاحيات وتحقق خاص بها.

قدمت ورقة MemGhost في يوليو 2026 معيار WhisperBench، وهو معيار يتكون من 108 حالات لحقن الذاكرة الخفي عبر مسارات عمل البريد الإلكتروني. أفاد المؤلفون بنجاح هجوم شامل من طرف إلى طرف على بيانات محجوزة بنسبة 87.5% ضد إعداد واحد من OpenClaw، وبنسبة 71.4% ضد إعداد واحد من Claude Code SDK. كما أفادوا بانتقال الهجوم إلى أنظمة ذاكرة أخرى.

لا تثبت هذه الأرقام معدل اختراق عالميًا. تغطي التجارب نماذج وبنى agents ومسار عمل متمحورًا حول البريد الإلكتروني، وتستخدم عدة تقييمات حكامًا من LLM، كما أن الورقة لا تختبر تلاشي الذاكرة على مدى أسابيع. ومع ذلك تظل الدلالة العملية قائمة: يجب ألا يصبح المحتوى غير الموثوق ذاكرة دائمة لـ agent دون مصدر موثق، والتحقق من المخطط، وعزل المستأجرين، وpolicy صريحة للكتابة.

يجب أن يحمل سجل الذاكرة ما يلي:

يجب أن تصمد الصلاحيات أمام أعطال الأدوات

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

يقيّم ToolBench-X agents في ظل انجراف المواصفات، وأخطاء الاستدعاء، وأعطال التنفيذ، وانجراف المخرجات، والتعارض بين المصادر. تفيد الورقة بأن agents التي تؤدي جيدًا مع أدوات نظيفة تتدهور تحت هذه المخاطر، بينما تساعد تلميحات التعافي الموجهة أكثر من مجرد إنفاق مزيد من حوسبة وقت الاختبار. هذه نتيجة معيارية وليست معدل حوادث إنتاجية.

تدرس AgentTether المسارات الفاشلة والتدخل المحمي أثناء التشغيل. وفي 261 مهمة من tau-bench، أفاد مؤلفوها بإصلاح 69.11% من عمليات Qwen التي فشلت مبدئيًا، بزيادة قدرها 26.02 نقطة مئوية عن إعادة المحاولة العمياء. تختلف النتائج حسب المجال، وتعتمد الأحكام المساعدة على نموذج آخر، ولا يستطيع tau-bench تمثيل كل سلسلة أدوات إنتاجية.

تدعم هذه الأوراق ضابطين:

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

سير عمل قابل لإعادة الإنتاج لاختبار الصلاحيات

نفّذ هذه الاختبارات قبل تفعيل عمليات الكتابة المستقلة:

بدأت مقاييس agents الحتمية بالظهور في أدوات التقييم مفتوحة المصدر. أضاف إصدار DeepEval 4.1.3 في 12 يوليو 2026، `ToolPermissionMetric` و`AgentLoopDetectionMetric` الحتميين. يمثل ذلك الإصدار إشارة إلى التبني، وليس دليلًا على أن المقاييس تغطي كل حالات إساءة الاستخدام.

يهم التحقق المستقل أيضًا خارج نطاق الأمن. تستخدم حلقة مراجعة الكود الهجينة هذه مراجعًا منفصلًا وبناءً حقيقيًا كدليل. ويظهر درس الأنظمة الأوسع مرة أخرى في Code Agents After 21.54 Billion Tokens: لا يمكن لجودة النموذج أن تحل محل التحقق والحدود التشغيلية.

قائمة فحص الإنتاج

تصل AI Agent Security Cheat Sheet من OWASP إلى نتيجة تشغيلية مشابهة: طبّق أقل قدر من الصلاحيات، وافصل اتخاذ القرار عن التنفيذ غير القابل للعكس، وتحقق من المدخلات الخارجية، وفرض حدود الحلقات، واحتفظ بسجلات إجراءات منظمة.

ما الذي لا تثبته هذه الأدلة

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

لذلك تمثل البنية إطارًا لاتخاذ القرار، لا شهادة اعتماد. وتأتي قيمتها من جعل الحد الأمني قابلًا للفحص: يقترح النموذج؛ وتقرر policy؛ وتفرض البنية التحتية؛ وتنفذ الأدوات؛ وتتحقق الأدلة المستقلة.

فحوصات الادعاءات

المصادر