تُوكل إلى وكيل برمجي مهمة صغيرة: أصلح اختبارًا فاشلًا. وبعد عشرين دقيقة تجده قد أعاد كتابة ثلاثة ملفات لا علاقة لها بالمهمة، ونفّذ ترحيلًا لقاعدة البيانات على أي DATABASE_URL وجده في صدفة الطرفية لديك، ثم دفع بالقوة (force-push) إلى فرع كان شخص آخر يستخدمه. لم يطلب أي شيء في التوجيه شيئًا من ذلك. كان الوكيل يملك حرية التصرف الكاملة على الجهاز، فاستعملها.
الصلاحيات هي وسيلتك لتقرير ما يجوز للوكيل أن يلمسه مسبقًا. وصلاحية وكيل البرمجة هي قاعدة تحدد الملفات والأوامر وبيانات الاعتماد والمستودعات التي يمكن لوكيل معيّن الوصول إليها خلال تشغيل واحد، والنقاط التي يجب أن يتدخل فيها إنسان. فإن أحسنت ضبطها، فشل الوكيل الخارج عن النص بأمان داخل إطار رسمته أنت. وإن أخطأت، وصل تشغيل واحد سيّئ إلى الإنتاج.
تستعرض هذه المقالة نموذج الصلاحيات طبقةً طبقة، وتسمّي نمط الفشل عند كل خطوة، وتنتهي بقائمة تحقق يمكنك تطبيقها اليوم. وهي تستعين بـ Sharkly لتجسيد كل طبقة على أرض الواقع، لأن مهمة Sharkly أن تعلو فوق وكلاء البرمجة لديك وتحتفظ بهذا النطاق في مكان واحد. أنت تملك وكلاء برمجة بالفعل. وSharkly تحوّلهم إلى فريق، والفريق يحتاج قواعد تحدد من يُسمح له بفعل ماذا.
الطبقات الثلاث التي تُحدَّد فيها صلاحيات الوكيل
صلاحيات وكيل البرمجة ليست إعدادًا واحدًا. إنها تقيم في ثلاثة مواضع، وأي ثغرة في أحدها تُبطل الاثنين الآخرين.
- بيئة التشغيل تقرر الأدوات التي يمكن للوكيل استدعاؤها: قراءة ملف، تعديل ملف، تنفيذ أمر في الصدفة، الوصول إلى الشبكة. وهذه هي Claude Code أو Codex أو Gemini CLI أو أي وكيل ينفّذ العمل.
- الجهاز يقرر ما يمكن لتلك الأدوات الوصول إليه: أي مجلدات، وأي بيانات اعتماد، وأي متغيرات بيئة، وأي شبكة. فالـ Computer في Sharkly «يوفّر نظام التشغيل والملفات وبيانات الاعتماد والوصول إلى الشبكة والأدوات التي يحتاجها الوكيل»، ومن ثمّ فالجهاز هو نطاق التأثير الحقيقي.
- المهمة تحدد حدود النية: أي مستودع يقتصر عليه هذا التشغيل، وأي حالات يجوز للوكيل تعيينها، والنقطة التي يقبل فيها إنسان النتيجة.
ثمة حدّ يستحق التوضيح صراحة: الصلاحية ليست بوابة موافقة. الصلاحية هي ما يستطيع الوكيل فعله. أما بوابة الموافقة فهي حيث يقرر الإنسان. وأنت تحتاج الاثنين معًا. صلاحيات محكمة بلا بوابة تعني ألا أحد يفحص النتيجة. وبوابة مع صلاحيات فضفاضة تعني أن الضرر قد وقع بحلول الوقت الذي ينظر فيه أحد.
الخطوة 1: حدِّد نطاق أدوات بيئة التشغيل
ابدأ من حيث يعمل الوكيل. معظم وكلاء البرمجة يأتون مزوّدين بنظام صلاحيات: قائمة سماح وقائمة منع للأدوات، إضافة إلى طلب تأكيد قبل تنفيذ أي أمر مدمّر. ففي Claude Code، على سبيل المثال، يمكنك السماح بأدوات معيّنة أو منعها، ويسألك قبل تنفيذ أوامر الصدفة؛ لكن أسماء الإعدادات الدقيقة تختلف من بيئة تشغيل إلى أخرى وتتغير كثيرًا، فاقرأ وثائق وكيلك الحالية بدلًا من مقتطف وجدته العام الماضي.
الإعداد الآمن الافتراضي هو التساهل في القراءة والتشدد في الكتابة. دع الوكيل يقرأ المستودع ويشغّل الاختبارات وفحص الأنواع والبناء دون سؤال. أما تعديل الملفات وأوامر الصدفة فضعها خلف طلب تأكيد أو قائمة سماح صريحة.
لنمط الفشل هذا اسم، وهو الخيار الذي يلجأ إليه الجميع تحت ضغط المواعيد النهائية: وضع التخطي الشامل. ففي كل بيئة تشغيل علم (flag) يعطّل جميع طلبات التأكيد، وهو مريح في جلسة تحت إشراف. لكن الخطر يكمن في تركه مفعّلًا في تشغيل بلا مراقبة. فالوكيل الذي لا يُسأل أبدًا، وهو يعمل وفق خطة تبيّن أنها خاطئة، سيحذف بكل سرور الشيء الذي أساء فهمه. استخدم القبول التلقائي حين تكون مراقبًا. وأوقفه حين تبتعد.
الخطوة 2: حدِّد نطاق الجهاز وبيانات الاعتماد فيه
قائمة أدوات بيئة التشغيل لا قيمة لها إذا سلّم الجهاز كل شيء إلى الوكيل. فالوكيل المسموح له بتنفيذ أوامر الصدفة على جهازك اليومي يستطيع قراءة كل مفتاح SSH، وكل ملف .env، وكل بيانات اعتماد يصل إليها حسابك أنت. ونمط الفشل هنا صامت: لا شيء يبدو خطأً حتى يستخدم الوكيل مفتاح إنتاج لم يكن يُفترض أن يراه أبدًا.
هناك حركتان تقلّصان نطاق التأثير. أولًا، شغّل الوكلاء في مكان محدود النطاق بدلًا من الحاسوب المحمول الذي تحتفظ فيه بأسرارك الحقيقية. تسجّل Sharkly جهاز Computer برمز تثبيت لمرة واحدة، قصير العمر ويُستخدم مرة واحدة فقط، والوثائق صريحة: لا تضع ذلك الرمز في صورة قابلة لإعادة الاستخدام أو سكربت أو مهمة أو تعليق. وسواء كان الـ Computer حاوية أو خادمًا أو جهازًا احتياطيًا، فإن مدى وصول الوكيل هو مدى وصول تلك البيئة، لا بيئتك. وإذا أردت أن يعمل الوكلاء وأنت غير متصل، فـشغّلهم على Computer بعيد بدلًا من حاسوبك المفتوح.
ثانيًا، لا تسلّم إلا ما يحتاجه التشغيل. فبيئة التشغيل في Sharkly تُجمَّع من إعدادات صريحة: المستودعات المرتبطة، ومتغيرات البيئة، وارتباطات الأسرار، ودليل العمل. اربط المستودعات بوكيل معيّن عندما يحتاج نطاقًا برمجيًا أضيق من الافتراضي في الـ Space، حتى لا يسحب وكيل الواجهة الأمامية خدمة الفوترة أبدًا. واحتفظ بكل تشغيل في شجرة عمل معزولة خاصة به، وهذا هو الفرق بين بقاء تعديل سيّئ داخل نسخة عمل واحدة وإفساد وكيلين لشجرة العمل نفسها. والقاعدة الداخلية تسري على كل حقل: أدخل فقط الإعدادات التي يطلبها المنتج، ولا تلصق أبدًا كلمات المرور أو الرموز في حقول غير ذات صلة أو في أوامر بدء التشغيل.
الخطوة 3: حدِّد نطاق المهمة واحتفظ بعملية الدمج لشخص
الطبقة الأخيرة هي النية. فحتى الوكيل المحصور بشكل صحيح في بيئة معزولة، وببيانات اعتماد محدودة النطاق، قد ينفّذ العمل الخطأ: يعلّم مهمته الخاصة كمكتملة، أو يدفع تغييرًا نصف منجز إلى فرع مشترك، أو يقرر أن طلب سحب (PR) جاهز للدمج.
هنا يأتي دور العقد بين الإنسان والوكيل. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير. أما البشر فيحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وتتوقف الأتمتة عند النقطة التي يلزم فيها حكم الفريق. ينبغي أن يُسمح للوكيل بفتح طلب سحب كمسودة (draft PR) وإرفاق مخرجات اختباره؛ لكن لا ينبغي أن يوافق على ذلك الطلب أو يدمجه في فرعك المحمي. حماية الفروع على المضيف والمراجعة البشرية على المهمة هما القفلان اللذان يحفظان هذا الخط سليمًا.
في Sharkly، المهمة نفسها تحمل هذا الحد. فنوع المهمة Workflow يقيّد الحالات التي يمكن للوكيل اختيارها، فلا يستطيع الوكيل نقل العمل بهدوء إلى حالة «مكتمل» أو «صدر» يملكها إنسان. وعندما يحتاج الوكيل إلى قرار، يترك المهمة في انتظار مراجعة بشرية أو ردّ بشري، ويظهر ذلك في صندوق الوارد ليتولى الشخص المسؤول قبولها أو طلب تعديلات أو إعادة تعيينها. وهكذا يعود التنفيذ والعوائق والنتائج والمراجعة كلها إلى المهمة الواحدة بدلًا من التشتت بين خمسة طرفيات.
وهنا أيضًا يتوقف إعداد «افعلها بنفسك» عن التوسع. وكيل واحد، ومستودع واحد، ومهندس واحد حذر: يمكنك أن تحمل نموذج الصلاحيات كله في رأسك. لكن أضف وكيلًا ثانيًا وثالثًا، ومزيدًا من المستودعات، وزميلًا في الفريق، وسيصبح سؤال «ما المسموح لكل وكيل هنا؟» سؤالًا لا يستطيع أحد الإجابة عليه من الذاكرة. ولوحة المهام تحوّل تلك القواعد إلى إعدادات مشتركة قابلة للفحص: من أسند العمل، وما النطاق الذي جرى به التشغيل، وما الأدلة التي عادت، ومن قَبِلها. تلك هي طبقة الإدارة فوق وكلاء البرمجة لديك. يمكنك بناؤها يدويًا باستخدام أشجار العمل وبيانات الاعتماد محدودة النطاق وحماية الفروع، أو تشغيل وكلاء البرمجة الحاليين لديك عبر Sharkly وإدارة الصلاحيات والمهام والمراجعة في مكان واحد.
قائمة التحقق من الصلاحيات التي يمكنك تطبيقها اليوم
راجع هذه القائمة لكل وكيل تسمح له بلمس مستودع حقيقي:
- بيئة التشغيل: القراءة والاختبارات مسموحتان دون طلب تأكيد؛ التعديلات وأوامر الصدفة مقيّدة؛ ووضع التخطي الشامل معطّل في التشغيلات بلا مراقبة.
- الجهاز: يعمل الوكيل على Computer محدود النطاق، لا على جهازك اليومي؛ ورموز التثبيت والوصول تُستخدم مرة واحدة ولا تُرفع إلى المستودع أبدًا.
- بيانات الاعتماد: متغيرات البيئة وارتباطات الأسرار التي يحتاجها هذا التشغيل فقط، ولا شيء ملصوق في حقول غير ذات صلة.
- نطاق المستودعات: يرتبط الوكيل بالمستودعات التي يتطلبها عمله، لا بكل مستودع في الـ Space.
- العزل: يحصل كل تشغيل على شجرة عمل خاصة به حتى لا يُفسد تغيير سيّئ نسخة عمل مشتركة.
- نطاق المهمة: يستطيع الوكيل تعيين حالات العمل الجارية لكنه لا يستطيع نقل مهمة إلى حالة مقبولة أو مُصدَرة يملكها إنسان.
- الدمج: حماية الفروع إلى جانب المراجعة البشرية المستندة إلى أدلة على مستوى المهمة يقفان بين طلب السحب الخاص بالوكيل والفرع الرئيسي.
إذا كان أي بند متراخيًا، فأحكمه قبل التشغيل التالي، لا بعد الحادثة التي تعلّمك لماذا كان مهمًا.
الأسئلة الشائعة
ما الفرق بين صلاحيات وكيل البرمجة وبوابات الموافقة؟ الصلاحيات تحدد ما يستطيع الوكيل فعله تقنيًا: الملفات والأوامر وبيانات الاعتماد التي يمكنه الوصول إليها. أما بوابة الموافقة فهي النقطة التي يقرر فيها إنسان قبول ما فعله الوكيل. وأنت تحتاج الاثنين، لأن الصلاحيات المحكمة تترك مع ذلك عملًا ينبغي أن يصادق عليه إنسان، ولن تفيد بوابات الموافقة إذا كان الوكيل يملك أصلًا صلاحية إحداث الضرر.
هل ينبغي أبدًا السماح لوكيل البرمجة بدمج طلبات السحب الخاصة به؟ لا، ليس افتراضيًا. دع الوكيل يفتح طلب سحب كمسودة ويرفق مخرجات التحقق الخاصة به، ثم اترك الدمج لشخص أو لمراجعة إلزامية. والمنطق هنا هو العقد بين الإنسان والوكيل: الوكلاء ينفّذون ويقدّمون التقارير، والبشر يقبلون ويصدرون. وهذا يسري حتى في سير العمل الذي يبقى فيه الإنسان في الحلقة ويؤدي الوكيل فيه معظم العمل.
هل من الآمن تشغيل وكيل مع تعطيل جميع طلبات تأكيد الصلاحيات؟ فقط حين تكون تراقبه. فأوضاع القبول التلقائي مفيدة في جلسة تحت إشراف يمكنك فيها إيقاف خطوة خاطئة. أما التشغيلات بلا مراقبة أو التي تمتد طوال الليل، فأبقِ طلبات التأكيد أو قائمة السماح مفعّلة، وضع الوكيل على جهاز محدود النطاق حتى يبقى أي خطأ محصورًا.
