GitHub برای سازمانهایی که از Copilot Business یا Copilot Enterprise استفاده میکنند، کنترل مرکزی تازهای بر کارهایی که عامل میتواند انجام دهد ارائه کرده است. مدیران حالا میتوانند مشخص کنند کدام فرمانها و دسترسیها ممنوع باشند، کدام کارها هر بار به تأیید انسان نیاز داشته باشند و کدام موارد بدون پرسش اجرا شوند. این قابلیت در برنامه GitHub Copilot، ابزار خط فرمان Copilot و نشستهای Visual Studio Code مبتنی بر Agent Host بهطور عمومی در دسترس است.
اهمیت این تغییر در خودِ فهرست تنظیمات نیست. GitHub صریحاً میگوید محدودیتهای مدیریتی را نمیتوان با تنظیمات شخصی یا فضای کاری، تأیید خودکار یا مجوزی که از دفعه قبل باقی مانده دور زد. در نتیجه، تصمیم نهایی درباره بخشی از اختیارات عامل از رایانه و نشست توسعهدهنده به سیاستی منتقل میشود که سازمان آن را اداره میکند.
سازمان میتواند برای هر نوع عملیات تصمیم متفاوتی بگیرد
در مستندات GitHub سه سطح برای مجوزها تعریف شده است: ممنوع کردن، گرفتن تأیید و اجازه اجرای مستقیم. این قواعد میتوانند فرمانهای پوسته، خواندن فایل، ویرایش فایل و مقصدهای شبکه را پوشش دهند. ترتیب اولویت نیز روشن است: ممنوعیت بر درخواست تأیید مقدم است و درخواست تأیید نیز بر اجازه مستقیم برتری دارد.
در حالتی که سازمان برای یک کار تأیید میخواهد، همان تأیید فقط برای همان نوبت معتبر است. طبق مستندات، حالت اجرای بدون پرسش، تنظیمات تأیید خودکار، سازوکارهای جانبی یا مجوزی که قبلاً ذخیره شده نمیتوانند این شرط را برآورده کنند. اگر همان عملیات دوباره درخواست شود، کاربر دوباره باید تصمیم بگیرد.
این ساختار اجازه میدهد میان کارهای روزمره و عملیات حساس تفاوت گذاشته شود. برای نمونه، اجرای یک آزمون مشخص میتواند آزاد باشد، ارسال تغییرات به مخزن یا ویرایش مسیر حساس نیازمند تأیید شود و دسترسی به یک مسیر یا مقصد شبکه کاملاً مسدود بماند.
شکاف تنظیمات محلی کوچکتر شده، اما همه خطرهای اجرا از بین نرفته است
GitHub در ماه ژوئن امکان دیگری اضافه کرده بود که مدیر سازمان میتوانست با آن حالت اجرای بیقیدوشرط Copilot را غیرفعال کند. آن کنترل بیشتر ماهیتی دوحالته داشت: کاربر یا میتوانست مسیر «همهچیز مجاز است» را فعال کند یا سازمان آن را میبست.
تغییر سپتامبر دقیقتر است. مدیر میتواند برای عملیات مشخص قاعده بنویسد و آن قاعده را بالاتر از تنظیمات محلی قرار دهد.
برداشت Aipolix این است که مرز اعتماد در استفاده سازمانی از عاملهای برنامهنویسی جابهجا شده است. سلیقه توسعهدهنده در نشست محلی دیگر برای عملیات مدیریتشده حرف آخر را نمیزند. فایل سیاست مرکزی بخشی از سازوکار امنیتی میشود؛ بنابراین بهتر است مانند کد زیرساختی مهم نسخهبندی، بازبینی و آزمایش شود و تغییر آن مسیر پاسخگو و قابل پیگیری داشته باشد.
با این حال، «داشتن مجوز» با «محصور بودن اجرای برنامه» یکی نیست. خود GitHub نیز تنظیمات مجوز را از تنظیمات محیط محدود اجرای عامل جدا کرده است. بخش دوم میتواند دسترسی فایل، شبکه، اعتبارنامهها، سرورهای محلی MCP و رفتار سامانه در صورت نبود امکان اعمال محدودیت را کنترل کند. سیاست مجوز تعیین میکند آیا عامل اصولاً اجازه درخواست یک عمل را دارد؛ محیط محدود مشخص میکند فرایندی که اجرا میشود واقعاً تا کجا دسترسی خواهد داشت.
وقتی چند سیاست وجود دارد، محدودکنندهترین قاعده تعیینکننده است
مستندات GitHub توضیح میدهد که اگر چند منبع مدیریتی همزمان سیاست تعیین کنند، یک قاعده ممنوعیت در هرکدام میتواند عملیات منطبق را برای همه ببندد. اگر چند منبع فهرست مجاز داشته باشند، نتیجه اشتراک آنهاست، نه جمع همه مجوزها. همچنین در شرایطی که سیاست مدیریتی برای مجوزها تعریف شده باشد، یک عملیات پشتیبانیشده که با هیچ قاعدهای تطبیق ندارد میتواند بهطور پیشفرض نیازمند تأیید شود.
برای سازمانهای بزرگ این جزئیات مهم است. در صورتی که سیاست اصلی صریحاً اجازه بدهد، میتوان برای تیمهای مختلف تنظیم متفاوتی ساخت؛ اما یک تنظیم آزادتر روی دستگاه کاربر نمیتواند ممنوعیت مرکزی را بیاثر کند.
همین قدرت مرکزی خطر تازهای هم دارد. یک ممنوعیت بیش از حد گسترده میتواند کار تعداد زیادی توسعهدهنده را مختل کند و یک اجازه بیش از حد باز میتواند عملی پرخطر را برای کل تیم عادی کند. بنابراین تغییر در این سیاستها باید همان دقتی را داشته باشد که برای حفاظت شاخه، مجوز استقرار یا تنظیمات هویتی به کار میرود.
تأیید انسانی حالا بخشی واقعی از طراحی کنترل است
در عامل برنامهنویسی، مسئله فقط این نیست که مدل قادر به اجرای فرمان یا ویرایش فایل هست یا نه. سؤال مهمتر این است که چه کسی در لحظه تصمیم میگیرد، این تصمیم تا چه زمانی معتبر میماند و آیا کاربر میتواند از مسیر دیگری آن را دور بزند.
قاعدهای که هر بار تأیید تازه میخواهد برای عملیات پرپیامد مناسبتر است. مثلاً اگر ارسال کد یا تغییر فایل حساس به تصمیم انسان وابسته باشد، تأیید دیروز نباید ناخواسته به اختیار دائمی امروز تبدیل شود.
در عین حال، گذاشتن پرسش تأیید روی هر اقدام هم راهحل خوبی نیست؛ انبوه پرسشها میتواند کاربر را به تأیید عادتوار سوق دهد. بهتر است کارهای واقعاً ممنوع بسته شوند، عملیات حساس و وابسته به زمینه تأیید بخواهند و فقط کارهای تکراری و کمخطر بهصورت محدود از پیش مجاز باشند.
استقرار امن به مجوز و محدودسازی اجرا با هم نیاز دارد
این قابلیت، کنترل سازمانی Copilot را جدیتر و قابل اعمالتر میکند، اما بهتنهایی یک مرز امنیتی کامل نیست. سیاست مجوز باید در کنار محدودسازی محیط اجرا، حفاظت مخزن و شاخه، مدیریت اسرار، محدودیت شبکه و ثبت تغییرات خودِ سیاست استفاده شود.
آزمون عملی این است که آیا توسعهدهنده با عوض کردن تنظیم محلی، روشن کردن تأیید خودکار، استفاده از مجوز قبلی یا رفتن به یک رابط دیگر میتواند عملی را انجام دهد که سازمان قصد محافظت از آن را داشته است. GitHub برای عملیات پشتیبانیشده در محیطهای مبتنی بر Agent Host چند مسیر از این دست را صریحاً بسته است.
تغییر اصلی همین است: سیاست سازمانی Copilot از یک مجموعه ترجیحات به لایهای نزدیکتر به «اختیاردهی» تبدیل میشود. هرچه عاملهای برنامهنویسی دسترسی بیشتری بگیرند، مستقل بودن این لایه از تصمیم خود عامل و از تنظیمات راحتی کاربر اهمیت بیشتری پیدا میکند.