Vercel Agent على production: الخطة هي اللي بتحدد الصلاحيات
إزاي Vercel Agent بيحقق بصلاحية قراءة بس، ويقترح خطة فيها الـ scopes، وياخد token قصير العمر بعد موافقة واحدة، وإيه اللي تنقله من الفكرة دي للـ agents بتاعتك.
بتدّي الـ AI agent صلاحيات واسعة علشان ما يقفش في نص الشغل؟ ولا بتدوس approve على كل خطوة لحد ما بقت حركة لا إرادية؟ الاتنين غلط. وVercel نشرت يوم 23 أكتوبر 2026 شرح لإزاي Vercel Agent بيتعامل مع production من غير ما ياخد أكتر من اللازم. النهارده في سلسلة «أخبار AI في دقيقة» (الجزء ٤٣) هنفصّص الفكرة دي.
الفكرة الأساسية: الخطة هي اللي بتحدد الصلاحيات
بدل ما الـ agent يبقى معاه token واسع طول الوقت، Vercel ربطت الصلاحيات بالـ plan اللي الـ agent بيقترحه. يعني الـ agent ما بياخدش صلاحية كتابة إلا لما يكون فيه خطة واضحة، مكتوب فيها كل خطوة وسببها والـ scope اللي محتاجه، وإنت توافق عليها.
الخطوات بالترتيب
- التحقيق بصلاحية قراءة بس: الـ agent بيبدأ بـ scopes بتبدأ بـ
read:، زيread:deployment. بيقرا لوجز الـ build ويقارن بآخر deployment ناجح، والجزء ده بيمشي لوحده من غير موافقة. - اقتراح خطة: لو محتاج يغيّر حاجة، بيكتب خطة: كل task جنبها السبب والـ scope، زي
read-write:deploymentعلشان يعمل redeploy. - موافقة واحدة: إنت بتوافق على الخطة كلها مرة واحدة، بدل ما توافق على كل أمر لوحده.
- token محدود: بعد الموافقة، OAuth بيطلّع token أقصر عمرًا بالـ scopes اللي في الخطة بس، ومش ممكن يتعدى صلاحيات المستخدم نفسه.
- أي حاجة برة الـ scopes بتترفض: الـ API بترفض أي طلب برة اللي اتوافق عليه، حتى لو الموديل شايف إنه ضروري.
تفاصيل صغيرة بس مهمة
- الخطة لازم تكون active: الـ runtime بيتأكد إن الخطة لسه شغالة قبل ما يستخدم الـ token. لو وقّفت الخطة، الـ token مش هيتستخدم حتى لو مدته لسه ما خلصتش.
- موافقة الـ PR مربوطة بالـ repo: الموافقة على PR في repo معينة ما تنفعش لـ repo تانية.
- نفس الـ registry: الـ scopes بتتشيّك على نفس الـ registry اللي بيطلّع الـ tokens، فالـ scope الغلط بيترفض وقت التخطيط نفسه، بدل ما النظام يرجع لصلاحية أوسع.
الـ scopes لوحدها مش كفاية
Vercel نفسها بتقول إن صلاحية القراءة لوحدها ممكن تكشف معلومات حساسة، وإن الـ scopes مش الحماية الوحيدة. محتاج كمان sandbox وnetwork policy وaudit logs. ودي نقطة مهمة لأن ناس كتير بتفتكر إن "read-only" معناها "آمن".
اعمل إيه دلوقتي على الـ agents بتاعتك
- اعمل جرد بالـ tokens اللي الـ agent بيستخدمها، ولو فيه token بصلاحية كتابة دايمة شيله.
- خلي مرحلة التحقيق read-only بس.
- أي تغيير يعدّي على خطة واحدة مكتوب فيها السبب والصلاحية، وإنت توافق عليها.
- زوّد sandbox و audit logs، زي ما Vercel نفسها بتقول.
رأيي
«موافقة على خطة» أحسن بكتير من «موافقة على كل أمر». لما بتوافق على كل أمر، بعد شوية بتبطّل تقرا وبتدوس approve وخلاص. لكن لما بتوافق على خطة واحدة، بتاخد قرار واحد وإنت فاهم الـ agent ناوي يعمل إيه وبأنهي صلاحية. وده نموذج يستاهل يتنقل لأي agent بتبنيه، مش بس على Vercel.
والـ agents عندك شغالة بأنهي صلاحيات على production؟
المصادر
- AI Agents
- Vercel
- Security
- OAuth
- DevOps