Vercel Agent يصل إلى بيئة الإنتاج عبر خطة محددة بنطاقات صلاحيات (scopes) وموافقة واحدة

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

الخطة وحدةً للإذن

يتضح النهج في مثال نشر معطوب. يطّلع الوكيل على أحدث عمليات النشر وسجلات البناء، ويقارن النشر الفاشل بآخر نشر يعمل. تكفي لذلك صلاحية القراءة فقط، ويجري التحقيق تلقائيًا. وإذا خلص التحقيق إلى اقتراح إعادة النشر، يعدّ الوكيل خطة ويطلب scope باسم read-write:deployment. وهكذا يرى المستخدم الإجراء والصلاحية اللازمة له في قرار واحد.

تربط الخطة أربع طبقات: النية (ما يريده المستخدم)، والعمل (مهام الوكيل)، والوصول (scopes هذه المهام)، والإنفاذ (الرموز المميزة والفحوص على جانب API). وتحفظ كل خطة مخزَّنة المهام والتقدم وscopes المطلوبة، وتُجمع هذه الـ scopes عبر جميع الخطوات. ويستطيع الوكيل إجراء فحص مرجعي سريع دون خطة أصلًا. أما التحقيقات الطويلة فتُنشأ لها خطة للقراءة فقط، ليتمكن المستخدم من متابعة سير العمل.

يشمل المستوى الأساسي حاليًا جميع scopes المسجلة التي تبدأ بالبادئة read:. وتلزم الموافقة إذا تجاوزت الخطة هذا المستوى أو تضمنت إجراءات خارجية مدعومة، مثل فتح pull request في GitHub. وتنبّه Vercel صراحةً إلى أن القراءة قد تكشف هي الأخرى بيانات حساسة، فالموافقة التلقائية لا تعني انعدام الضرر.

رموز مميزة لا يستطيع النموذج الالتفاف عليها

يعمل Vercel Agent بوصفه Vercel App يفوّضه المستخدم ضمن الفريق. وهذا التفويض محدود بصلاحيات المستخدم نفسه، ولذلك لا تمنح الموافقة على الخطة الوكيلَ ما لا يملكه الإنسان. وتستبدل خدمة OAuth التفويضَ برموز مميزة قصيرة العمر ذات scopes محددة، وتتحقق واجهات API من الرمز عند كل طلب.

هناك تفصيل مهم: صلاحية deployment write أوسع من إعادة نشر واحدة. فذكر النشر X في الخطة لا يحصر الرمز المميز بهذا النشر وحده. لذلك تعتمد الحماية على طبقات عدة، ولا تُعد تعليمات النموذج حول وقت طلب الموافقة حدًّا أمنيًا. وإذا حاول الوكيل تنفيذ عملية خارج نطاق الرمز، يرفضها API حتى لو قرر النموذج أن الإجراء ضروري.

تتوقف بيانات الاعتماد (credential) المستخدمة على نوع العمل:

• التحقيق: رمز أساسي بـ scopes للقراءة فقط؛
• التغييرات المعتمدة في Vercel: scopes الأساسية بالإضافة إلى الإضافية المعتمدة؛
• الإجراءات الخارجية: بيانات اعتماد وصلاحيات المزوّد المعني.

قد تشمل الخطة الواحدة تغييرات في Vercel وpull request معًا. يراجع المستخدم كل شيء دفعة واحدة، لكن المزوّدين يستخدمون صلاحيات منفصلة. فوصول GitHub مرتبط بالمالك والمستودع: الموافقة الخاصة بـ acme/storefront لا تمتد إلى acme/payments، إذ تلزم موافقة مستقلة.

سجل موحد لـ scopes واستئناف العمل

كان لدى Vercel Agent في البداية قائمة أذونات خاصة به، وكانت تتباين مع خدمة OAuth التي تصدر الرموز. أما الآن فيحمّل الوكيل عند بدء الجلسة التعريفات من سجل scopes المشترك إلى فهرس في الذاكرة (in-memory). ويُستخدم الفهرس للتحقق من صحة الخطة (تُرفض الأسماء المجهولة وغير الصحيحة قبل عرضها على المستخدم)، ولتحديد ما إذا كانت الموافقة لازمة، ولتجهيز الرمز المميز. وإذا طلبت مهمة، وفق قواعد جدار الحماية، scope قديمًا، ترفض المنظومة الخطة وتعيد قائمة بالـ scopes المسموحة، ليصحح الوكيل طلبه بدلًا من أن يحصل افتراضيًا على وصول أوسع. ويُخزَّن الفهرس مؤقتًا، لذا تعكس الفحوص حالته إلى حين التحديث التالي.

وعولجت حالات الإخفاق بصورة مستقلة. فقد تصل الموافقة بعد انتهاء المحادثة الأصلية، أو ينقطع الاتصال في منتصف إعادة النشر. تحفظ الخطة حالتها ومن وافق عليها ووقت الموافقة. وقبل المتابعة يعيد وقت التشغيل (runtime) تحميل الخطة ويتحقق من أنها فعّالة. والخطة الموقوفة لا تجتاز الفحص، حتى لو بقيت للرمز المميز مدة صلاحية. وإذا وصلت الموافقة والإيقاف في اللحظة نفسها، فلن تنتقل الخطة من الانتظار إلى الحالة الفعّالة إلا بشرط ألا يكون الإيقاف قد غيّر حالتها. واستبدال الخطة بأخرى ذات صلاحيات أعلى يتطلب موافقة جديدة.

ما تُرك مفتوحًا

تسرد Vercel مواطن الضعف بصراحة. فالوكيل يختار scopes بمعلومات ناقصة، وقد يطلب أقل مما يلزم أو أكثر منه. وقد يكون scope صالح أوسع من المطلوب. ورفض API قد يعني نقص الصلاحيات، أو موردًا خاطئًا، أو عملية يجب أن تبقى محظورة، وعلى الوكيل أن يميز بينها. كذلك قد تختبئ تعليمات خبيثة في المحتوى المقروء، مثل سجلات البناء. لذلك تعمل الخطط جنبًا إلى جنب مع العزل في sandbox، وسياسات الشبكة، ومعالجة الأسرار، والحدود القصوى، وسجلات التدقيق، وتفويض الخدمات.

ما يمكن أخذه إلى أنظمتكم الوكيلية

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