گزارش unYOLO: نظارت انسانی بر توکن‌ها ریسک نفوذ عامل‌های AI را می‌کاهد

تصور کنید کلید اصلی تمام درهای دفترتان را به یک پیمانکار موقت بدهید، به‌جای اینکه کارتی صادر کنید که فقط یک در خاص را برای یک ساعت باز می‌کند. این دقیقاً همان ریسکی است که توسعه‌دهندگان هنگام دادن توکن‌های کامل حساب به یک عامل هوش مصنوعی می‌پذیرند. دادن یک توکن کامل حساب به یک عامل AI، یک قمار امنیتی است که به محض ارسال یک دستور اشتباه به یک شاخه عملیاتی (Production Branch)، به فاجعه ختم می‌شود.

به گزارش مستندات رسمی این پروژه، چارچوب unYOLO در ۹ اوت ۲۰۲۶ منتشر شد تا این حفره امنیتی را ببندد. در حال حاضر اکثر برنامه‌نویسان توکن‌های خام را در اختیار عامل‌ها قرار می‌دهند؛ یعنی یک خطای کوچک در پرامپت می‌تواند منجر به حذف اتفاقی داده‌ها، ارسال‌های اجباری غیرمجاز (unauthorized force-pushes) یا نشت اطلاعات در کل حساب شود. در واقع، سطح دسترسی عامل در این حالت دقیقاً با صاحب حساب برابر است و این موضوع یک سطح حمله (Attack Surface) عظیم ایجاد می‌کند. این نگرانی‌ها پیش‌تر در مورد نشت کلیدهای API در سیستم‌های پرداخت مطرح شده بود که نشان می‌داد دسترسی مستقیم عامل‌ها به زیرساخت‌های حساس می‌تواند مخاطرات مالی جبران‌ناپذیری داشته باشد.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جداسازی هویت از دسترسی، تنها راه مقابله با خطاهای پیش‌بینی‌ناپذیر مدل‌هاست. unYOLO این کار را با ایجاد یک واسط یا بروکر (Broker) بین عامل و ارائه‌دهنده سرویس انجام می‌دهد.

مرز اعتبار

بدون وجود این واسط، اگر توکنی برای ارسال کد به یک شاخه (Branch) خاص در گیت‌هاب به عامل بدهید، آن توکن می‌تواند به شاخه اصلی، کل مخزن و حتی مخازن خصوصی مجزا دسترسی داشته باشد. در این حالت، قدرت عامل در سطح کل حساب است.

اما در سیستم unYOLO، بروکر توکن اصلی را در یک فرآیند مجزا نگهداری می‌کند و عامل تنها یک اعتبار کلاینت (Client Credential) دریافت می‌کند. هر درخواست عامل ابتدا توسط بروکر و بر اساس یک فایل تنظیمات به نام scope.json بررسی می‌شود؛ اگر عامل بخواهد عملیاتی غیرمجاز (مثل force-push) انجام دهد، بروکر پیش از آنکه درخواست به گیت‌هاب برسد، آن را رد می‌کند.

طبق مستندات unyolo.io، این چارچوب دسترسی مستقیم به توکن را با یک سیستم اعتبار کلاینت جایگزین می‌کند. بروکر توکن واقعی ارائه‌دهنده را در یک پروسه جداگانه نگه می‌دارد و هر درخواست را با یک فایل سیاست محلی (scope.json) ارزیابی می‌کند.

خط لوله درخواست

طبق اعلام توسعه‌دهندگان، هر عملیات برای اطمینان از عدم نشت اسرار، هفت مرحله سخت‌گیرانه را طی می‌کند:

1. احراز هویت کلاینت: فراخواننده یک رمز عبور مخصوص کلاینت-بروکر را ارائه می‌دهد.
2. طبقه‌بندی درخواست: آداپتور، نوع عملیات و ویژگی‌های هدف را شناسایی می‌کند.
3. ارزیابی سیاست: موتور سیستم، درخواست را با فایل قوانین تطبیق می‌دهد.
4. بررسی مجوزهای فعال: سیستم به دنبال قوانین اجازه (Allow) موجود و زمان‌دار می‌گردد.
5. درخواست تایید: عملیات‌های پرریسک به اینباکس اپراتور یا تلگرام ارسال می‌شوند.
6. اجرای ارائه‌دهنده: بروکر عملیات را انجام داده و تنها نتیجه را بازمی‌گرداند.
7. ثبت بازرسی: تصمیم‌گیری ثبت می‌شود، اما هیچ توکن یا سری حساس در لاگ‌ها قرار نمی‌گیرد.

حفاظ‌های فنی

در unYOLO، یک ترتیب تصمیم‌گیری ثابت پیاده‌سازی شده است که در آن قانون «رد کردن» (Deny) همیشه بر «اجازه دادن» (Allow) یا «مجوزهای فعال» (Active Grants) برتری دارد. اگر درخواستی با هیچ قانونی تطبیق نیابد، به‌صورت پیش‌فرض رد می‌شود. ترتیب تصمیم‌گیری بدون توجه به ترتیب قرارگیری قوانین در فایل، به این صورت است: رد $ \rightarrow $ مجوز فعال $ \rightarrow $ اجازه $ \rightarrow $ درخواست تایید $ \rightarrow $ عدم تطبیق.

جزئیات سیاست‌گذاری و تایید

• فایل‌های سیاست: بروکر در هنگام شروع، یک فایل JSON قوانین را بارگذاری می‌کند. این سیستم دسترسی‌ها را از روی ترافیک حدس نمی‌زند. ویژگی‌ها (Attributes) اجازه محدودسازی دقیق را می‌دهند؛ برای مثال، یک قانون می‌تواند ارسال کد به refs/heads/agent-a/** را مجاز کند، در حالی که refs/heads/main را بدون پوشش و مسدود نگه دارد.
• اعتبارسنجی: اگر سرویس فیلدهای ناشناخته، شناسه‌های تکراری، عملیات‌های پشتیبانی‌نشده یا الگوهای (globs) نامعتبر شناسایی کند، برای جلوگیری از خطاهای امنیتی، اصلاً اجرا نمی‌شود.
• تایید اپراتور: وقتی یک عملیات درخواست می‌شود، یک رکورد دائمی ایجاد شده و تماس اصلی باز می‌ماند. اپراتورها می‌توانند درخواست‌ها را از طریق یک اینباکس محافظت‌شده در یک شنونده (Listener) مجزا یا از طریق تلگرام تایید کنند.
• چرخه حیات مجوز: پس از تایید، یک عملیات (مثلاً git push) به عنوان همان درخواست قبلی ادامه می‌یابد. تاییدها را می‌توان بر اساس مدت زمان یا تعداد دفعات استفاده محدود کرد. اگر درخواستی رد شود یا منقضی گردد، یک خطای معمولی Git بازگردانده می‌شود.

در حال حاضر unYOLO دارای بروکر‌های پیش‌ساخته برای GitHub، Hugging Face و یک sudo-broker برای دستورات تاییدشده یونیکس است. هر کدام در فرآیندی مجزا اجرا می‌شوند و نمی‌توانند به اعتبار سرویس‌های دیگر دسترسی داشته باشند.

پیاده‌سازی بروکر سفارشی

توسعه‌دهندگان می‌توانند با پیاده‌سازی یک طبقه‌بندی‌کننده (Classifier) و اجراکننده (Executor) مخصوص هر ارائه‌دهنده، بروکر خودشان را بسازند. معماری این سیستم به‌طور صریح از اشتراک‌گذاری کدهایی که ارائه‌دهنده را وارد (Import) می‌کنند منع می‌کند تا ایزولاسیون کامل حفظ شود.

هنگام نوشتن یک بروکر سفارشی، توسعه‌دهنده موارد زیر را ارائه می‌دهد:

• یک طبقه‌بندی‌کننده برای شناسایی کلاینت و عملیات.
• یک رجیستری که عملیات‌ها و انواع اهداف را تعریف می‌کند.
• یک اجراکننده که اعتبار را نگه داشته و عملیات را انجام می‌دهد.
• متون محدودی برای تایید شامل حقایق مربوط به ریسک و هشدارها.

در مقابل، توسعه‌دهنده موتور سیاست‌گذاری، چرخه حیات مجوزها (شامل بودجه‌های استفاده و تلاش‌های مجدد Idempotent)، اینباکس اپراتور و سیستم بازرسی امن را به ارث می‌برد.

این تغییر، امنیت را از مدل «همه یا هیچ» به مدل «حداقل دسترسی» (Least Privilege) منتقل می‌کند. با جداسازی هویت عامل از قدرت توکن، سازمان‌ها می‌توانند بدون ترس از یک دستور اشتباه و فاجعه‌بار مانند git push --force به شاخه اصلی، عامل‌ها را در محیط عملیاتی مستقر کنند.

برای کاربر نهایی، این یعنی تفاوت بین «هک شدن کامل حساب» و «یک درخواست مسدود شده». قابلیت صدور مجوزهای زمان‌دار که به‌طور خودکار منقضی می‌شوند، نیاز به چرخش دستی کلیدها پس از هر تسک را از بین می‌برد.

برای تست این پیاده‌سازی، کاربران می‌توانند gh-broker را روی یک مخزن واحد اجرا کنند تا تایید کنند که ارسال کد به شاخه‌های مجاز موفق است، در حالی که ارسال به شاخه پیش‌فرض مسدود می‌شود.

گام بعدی شما

• اگر از عامل‌های AI برای مدیریت کد استفاده می‌کنید، بروکر gh-broker را روی یک مخزن تست اجرا کنید تا مسدود شدن دسترسی به شاخه اصلی را ببینید.
• فایل scope.json را برای محدود کردن دسترسی‌های عامل‌های خود به شاخه‌های Feature تعریف کنید.
• برای عملیات حساس، اتصال تلگرام را برای تایید لحظه‌ای درخواست‌ها فعال کنید.

اما مدیریت این دسترسی‌ها در مقیاس هزاران عامل، چالش جدیدی را ایجاد می‌کند — به تحلیل ما درباره‌ی پروتکل MCP برای استانداردسازی ارتباط مدل‌ها مراجعه کنید.