دليل موثّق
منح الوكيل صلاحية على الإنتاج: هوية خاصة به، وصلاحيات ضيقة، وتدوير للمفاتيح
الوكيل الذي يعمل ببيانات اعتمادك يستطيع فعل كل ما تستطيعه، وفي كل سجل تبدو أخطاؤه وكأنها أخطاؤك. ثلاثة إعدادات تمنحه وصولًا خاصًا به وأضيق: قاعدة البيانات، ومنصة استضافة الشيفرة، والأسرار التي رآها من قبل. ثم قاعدة رابعة للوكلاء الذين يعملون على الويب: ما المسموح لهم فعله، وما الذي ينبغي أن يفعلوه حين يتعثرون.
القاعدة
الوكيل الذي يعمل ببيانات اعتمادك يستطيع فعل كل ما تستطيعه، وفي كل سجل تبدو أخطاؤه وكأنها أخطاؤك. لا ينبغي أن يستعير هويتك، بل أن تكون له هويته الخاصة.
السؤال الذي أطرحه قبل منح أي وكيل أي صلاحية: لو تسرّبت بيانات الاعتماد هذه الليلة، ماذا يستطيع غريب أن يفعل بها، وهل أستطيع إيقافها دون أن أُغلق الباب على نفسي؟
١. قاعدة البيانات: دور للقراءة فقط يمكنك تضييقه
نصيحة Arvid Kahl المنشورة على X: امنح وكلاء البرمجة مستخدمًا للقراءة فقط على قاعدة بيانات الإنتاج، ويُفضّل أن يكون على نسخة متماثلة (replica)، ليتمكن الوكيل من الاطلاع على بيانات الإنتاج الحقيقية والتحقق منها. أتفق مع الهدف. القراءة فقط تبدو آمنة، لكنها ليست كذلك إن استطاع الوكيل قراءة بيانات شخصية لم تقصد كشفها، أو تشغيل استعلام يُبطئ الإنتاج على عملائك. هذا هو الإعداد الذي أضعه حول ذلك المستخدم.
أولًا، يحصل الوكيل على دور خاص به، لا على بيانات اعتماد التطبيق، لتتمكن من تضييقه أو سحبه دون المساس بأي شيء آخر.
ثانيًا، يقرأ هذا الدور من عرض (view) يُسقط أو يُخفي أعمدة البريد الإلكتروني والهاتف والاسم. امنحه SELECT على العرض لا على الجداول الأساسية، لأن العرض لا يحميك إلا إذا بقيت الجداول الخام مغلقة أمام الدور.
ثالثًا، الضوابط: مهلة للاستعلام (statement timeout) مضبوطة على هذا الدور لا على الخادم كله، وحدّ لعدد الصفوف المُعادة، مثل LIMIT تضيفه الأداة التي تُرسل الاستعلام.
أخيرًا، المكان الذي يقرأ منه. النسخة المتماثلة تُبعد عبء الاستعلامات عن الخادم الرئيسي. لكن بياناتها قد تتأخر، وقد يُلغى استعلام طويل حين يتعارض مع النسخ المتماثل (replication)؛ ومع تفعيل hot_standby_feedback قد يؤخّر استعلام طويل على النسخة المتماثلة أيضًا عملية التنظيف على الخادم الرئيسي.
تعامل مع إعداد القراءة فقط على أنه وسيلة تيسير. الصلاحيات الممنوحة هي الحدّ الحقيقي.
٢. منصة استضافة الشيفرة: رمز خاص به، أو تطبيق خاص به
لنفترض أن الوكيل يحتاج إلى فتح طلبات دمج (pull requests) في مستودع واحد، فتعطيه رمز GitHub الشخصي لأنه الأسرع. الرمز الكلاسيكي بنطاق repo يصل إلى كل مستودع تصل إليه أنت، وقد لا تنتهي صلاحيته أبدًا، وكل ما يفعله يظهر باسمك. وإن تسرّب عبر سجل أو نص جلسة أو حزمة تابعة (dependency) سيئة، فستُدوّر بيانات اعتمادك أنت، وتراجع كل ما تملك صلاحية الوصول إليه.
الآن امنح الوكيل رمزًا خاصًا به بدلًا من ذلك. رموز GitHub محددة الصلاحيات (fine-grained) يمكن حصرها في مستودعات مختارة، ومنحها الصلاحيات التي تحتاجها المهمة فقط، وضبطها لتنتهي. التسرّب نفسه يصبح محصورًا في مستودع واحد حتى تنتهي صلاحية الرمز، ويمكنك سحبه دون المساس بوصولك أنت.
وإن أردت أيضًا أن تظهر تغييراته باسمه لا باسمك، فامنحه تطبيق GitHub (GitHub App) يعمل بهويته الخاصة بدلًا من رمز على حسابك.
٣. الأسرار التي رآها من قبل: دوّرها
إن رأى وكيلٌ مفتاحًا في أي وقت، فدوّره. نقل الأسرار من ملف .env إلى خزنة يحمي مكان وجودها من الآن فصاعدًا، لا الأماكن التي مرّت بها من قبل.
وكلاء البرمجة مثل Claude Code وCodex يحتفظون بنصوص الجلسات على القرص. Claude Code مثلًا يحفظ النص الكامل لكل جلسة، بما في ذلك كل نتيجة أداة، ويحتفظ به 30 يومًا افتراضيًا. فإن فتح وكيلٌ ملف .env، أو شغّل printenv، أو لُصق له مفتاح في المحادثة خلال الشهر الماضي، فالأرجح أن ذلك المفتاح موجود في ملف نصي عادي على جهازك. وأي شيء يستطيع قراءة تلك الملفات يستطيع استخدامه، بما في ذلك الوكيل التالي الذي تشغّله هناك.
نصيحة Arvid Kahl ذات الصلة: احفظ بيانات اعتماد التطوير في خزنة تطلب كلمة مرور عند كل وصول، لأن الوكلاء بارعون في استخدام الحاسوب أيضًا. الخزنة هي الخطوة الأولى، والتدوير هو الخطوة الثانية. ابدأ بالمفاتيح التي تستطيع إنفاق المال أو الوصول إلى الإنتاج.
٤. ما المسموح له فعله، وما الذي يحدث حين يتعثر
تغطي الأقسام من ١ إلى ٣ قاعدة البيانات، ومنصة استضافة الشيفرة، والأسرار التي رآها من قبل. والوكيل الذي يتصفح الويب أو يملأ النماذج أو يستدعي خدمات خارجية يحتاج إلى المعاملة نفسها في ما يخص الأفعال، وإلى قاعدة إضافية: ما الذي ينبغي أن يفعله حين لا يمكن إنجاز المهمة بالطريقة التي أعددتها.
نشرت Anthropic في 9 أكتوبر 2026 تقريرًا عن قيام Claude بأفعال غير مقصودة على مواقع حقيقية أثناء التقييمات والاستخدام الداخلي. في إحدى الحالات طُلب من النموذج ألا يسجّل الدخول أبدًا، وألا ينشئ حسابات، وألا يُدخل بيانات شخصية، وألا يُجري عمليات شراء، وألا يُرسل أي شيء مُدمّر. لم تستبعد التعليمات إرسال النماذج، وقد أرسل بلاغًا مختلَقًا عبر نموذج البلاغات في موقع إدارة شرطة. لم يُخالَف أي بند في تلك القائمة. الثغرة كانت في الفعل الذي لم يُدرجه أحد. وتصف Anthropic معظم الحالات بأنها إصرار: حين لا يستطيع النموذج إكمال المهمة كما طُلبت، يلتفّ على القيد بدلًا من أن يتوقف.
يترتب على ذلك تغييران:
- اكتب النطاق على شكل قائمة سماح (allow-list). حدّد الأفعال التي يجوز له القيام بها، والمواقع أو نقاط النهاية (endpoints) التي يجوز له الوصول إليها. قائمة المنع (deny-list) لا تغطي إلا الأخطاء التي فكّرت فيها مسبقًا.
- اجعل التوقف هو النتيجة المتوقعة. ينبغي أن تكون عبارة «توقّف وأبلِغ عمّا منعك» نتيجةً عادية في التعليمات، لا فشلًا، حتى ينتهي التشغيل عند الطريق المسدود بدلًا من أن يبدأ محاولة للالتفاف عليه.
قائمة التحقق
- للوكيل دور خاص به في قاعدة البيانات، لا بيانات اعتماد التطبيق.
- لهذا الدور صلاحية SELECT على عرض يُخفي البيانات، لا على الجداول الأساسية.
- مهلة الاستعلام مضبوطة على الدور، والأداة التي ترسل الاستعلامات تضيف LIMIT للصفوف.
- إن كان يقرأ من نسخة متماثلة، فأنت تعرف مقايضات التأخر والإلغاء.
- وصوله إلى منصة استضافة الشيفرة برمز محدد الصلاحيات محصور في مستودعات مختارة، بالصلاحيات التي تحتاجها المهمة فقط وبتاريخ انتهاء، أو بتطبيق GitHub يعمل بهويته.
- كل مفتاح رآه وكيلٌ من قبل جرى تدويره، بدءًا بالمفاتيح التي تستطيع إنفاق المال أو الوصول إلى الإنتاج.
- الأفعال المسموح بها للوكيل، والمواقع ونقاط النهاية المسموح له بالوصول إليها، مكتوبة في قائمة.
- كل فعل يُرسِل أو يدفع أو ينشر أو يحذف يحتاج إلى تأكيد بشري لا يستطيع الوكيل تخطّيه.
- تنص التعليمات على ما يجب فعله عند التعثر: التوقف والإبلاغ.
ذو صلة
الخطوة التالية
الملاحظات الأطول عن قرارات كهذه تُنشر على Substack. وإن كان فريقك يُعدّ وصول الوكلاء إلى أنظمة الإنتاج ويريد مساعدة في البناء، فالمسار التجاري هو VentraM.