آسودگی یک کلید قطع سریع
پلتفرم‌های مهار runtime مانند OpenShell انویدیا به‌عنوان یک لایه ایمنی برای agentهای خودمختار معرفی می‌شوند. وعده ساده است: یک فرایند agent مشاهده می‌شود و اگر از مرز خارج شود — نوشتن در مسیری غیرمجاز، باز کردن سوکتی غیرمنتظره، ایجاد فرایندی که نباید — پلتفرم آن را رهگیری و خاتمه می‌دهد. تأخیر گزارش‌شده در حد میلی‌ثانیه‌های پایین است. این یک دستاورد مهندسی واقعی است و همچنین عدد اشتباهی است که یک استدلال ایمنی بر آن بنا شود.
مهار به یک پرسش پاسخ می‌دهد: آیا این اجرا هنوز داخل جعبه‌اش است؟ اما به پرسشی که در واقع شدت حادثه را تعیین می‌کند پاسخ نمی‌دهد: آیا این اجرا اصلاً باید قادر به چنین تلاشی می‌بود؟ این تمایز فلسفی نیست. تفاوت میان agentی است که تلاش کرد به یک endpoint داخلی metadata دسترسی پیدا کند و کشته شد، و agentی که هرگز اعتبارنامه‌ای نداشت که بتواند به آن دسترسی پیدا کند. هر دو یک خط log تولید می‌کنند. فقط یکی از آن‌ها یک نفوذ تولید می‌کند.
این مقاله استدلال می‌کند که پلتفرم‌های مهار یک ویژگی تأخیر هستند، نه یک ویژگی اختیار، و ایمنی agent به یک مدل اختیار نیاز دارد که بالای سندباکس بنشیند، نه یک مسیر خاتمه سریع‌تر در داخل آن.
مهار در واقع چه چیزی می‌خرد
یک پلتفرم مهار، از نظر مکانیکی، یک ناظر است. به یک درخت فرایند متصل می‌شود، syscallها یا رویدادهای شبهsyscall را از طریق یک رابط کرنل تماشا می‌کند، آن‌ها را با یک policy تطبیق می‌دهد و در صورت نقض، می‌کشد. هدف طراحی زمان تا خاتمه است. آن را کاهش دهید و پنجره‌ای را که یک agent بدرفتار می‌تواند در آن عمل کند کاهش می‌دهید.
آن پنجره واقعی است. همچنین با سرعت خود عمل محدود می‌شود. یک نوشتن در فایل‌سیستم در میکروثانیه کامل می‌شود؛ یک درخواست شبکه پیش از آنکه موتور policy ناظر ارزیابی قاعده‌ای را که آن را متوقف می‌کرد به پایان برساند، میزبان را ترک می‌کند. مهار مواجهه را محدود می‌کند اما قابلیت را حذف نمی‌کند. agent هنوز دسته، توکن، سوکت و مسیر را در اختیار داشت. از آن‌ها استفاده کرد. سهم پلتفرم این بود که بعداً، به‌سرعت، متوجه شود.
لایه گمشده: اختیار پیش از قابلیت
هر tool call که یک agent انجام می‌دهد یک اعطای قابلیت است. وقتی orchestrator ابزار read_file را به مدل می‌دهد، دسترسی خواندن به هر چیزی که پیاده‌سازی ابزار می‌تواند به آن برسد را اعطا می‌کند. وقتی یک HTTP client می‌دهد، خروج به هر چیزی که اعتبارنامه‌ها و policy شبکه client اجازه می‌دهد را اعطا می‌کند. وقتی یک shell می‌دهد، اجتماع هر چیزی که shell می‌تواند انجام دهد را اعطا می‌کند.
پلتفرم‌های مهار به‌ندرت مالک این اعطاها هستند. آن‌ها زیر لایه ابزار، در مرز فرایند، می‌نشینند و اثرات اعطاها را می‌بینند نه خود اعطاها را. این یک نقطه کور ساختاری است: پلتفرم می‌تواند به شما بگوید یک فرایند سوکتی باز کرد، اما نه اینکه agent هرگز قرار نبوده ابزاری داشته باشد که سوکت باز می‌کند.
اختیار به policy تعلق دارد، بالای سندباکس. به‌طور مشخص، این یعنی تعریف بودجه‌های اختیار به‌ازای هر اجرا:
- سطح ابزار: مجموعه دقیق ابزارهایی که اجرا می‌تواند فراخوانی کند، نه مجموعه‌ای که framework به‌طور تصادفی در معرض قرار می‌دهد.
- دامنه endpoint: کدام میزبان‌ها یا سرویس‌ها هر ابزار می‌تواند با آن‌ها تماس بگیرد، به‌صورت allowlist نه blocklist.
- دامنه اعتبارنامه: توکن‌های کوتاه‌عمر و باریک‌دامنه که به‌ازای هر اجرا صادر می‌شوند، تا یک توکن لو‌رفته بیرون از عمر اجرا بی‌استفاده باشد.
- سقف‌های هزینه و نرخ: محدودیت‌های سخت بر میزان منبع خارجی که اجرا می‌تواند مصرف کند، مستقل از آنچه ابزارها اجازه می‌دهند.
- کران زمانی: انقضایی که پس از آن اختیار بدون توجه به وضعیت اجرا لغو می‌شود.
هیچ‌یک از این‌ها نیازمند سریع‌تر بودن سندباکس نیست. آن‌ها نیازمند این هستند که orchestrator همان چیزی باشد که تصمیم می‌گیرد agent چیست، پیش از آنکه agent اجرا شود. جدا کردن اختیار از مهار همچنین به شما اجازه می‌دهد درباره شعاع انفجار مستقل از احتمال فرار استدلال کنید. یک اجرا بدون اختیار شبکه، شعاع انفجاری صفر برای حوادث شبکه دارد، مهم نیست agent چقدر در فرار از مرز فرایند زیرک باشد. این گزاره‌ای قوی‌تر از «ما آن را در کمتر از ده میلی‌ثانیه می‌کشتیم» است.
یک تجزیه مرجع
سه لایه، هر یک با وظیفه‌ای متمایز.
سندباکس. جداسازی فایل‌سیستم، جداسازی network namespace، جداسازی فرایند، محدودیت‌های منبع. وظیفه سندباکس این است که فرار را پرهزینه و قابل‌مشاهده کند. این خط آخر است، نه خط اول.
اختیار. اعتبارنامه‌های دامنه‌دار، allowlistهای خروج، سقف‌های هزینه، باریک‌سازی سطح ابزار، انقضای دامنه‌دار اجرا. وظیفه لایه اختیار این است که قابلیت غیرمجاز را غیرقابل‌دسترس کند، نه صرفاً قابل‌تشخیص. اینجاست که مهندسی جالب زندگی می‌کند: یک کارگزار اعتبارنامه که توکن‌های به‌ازای هر اجرا صادر می‌کند، یک موتور policy که سطح ابزار یک اجرا را از قصد اعلام‌شده‌اش استخراج می‌کند، یک پروکسی خروج که allowlistهای میزبان را در لبه شبکه uit-board-macro-62542d-755b13.jpg)
تله‌متری. logهای قصد و سوابق مسیر. برای هر tool call: agent گفت چه کاری انجام می‌دهد، چه اختیاری را فراخوانی کرد، موتور policy چه تصمیمی گرفت، و ابزار در واقع چه کرد. این همان چیزی است که تصمیم اختیار را پس از واقعه قابل‌حسابرسی می‌کند — و به شما اجازه می‌دهد هفته‌ها بعد بازسازی کنید که آیا یک حادثه یک شکاف policy بود یا یک باگ پیاده‌سازی.
مبادله واقعی است و ارزش دارد صریح بیان شود. اجرای اختیار اصطکاک اضافه می‌کند. سطوح باریک ابزار یعنی agentها بیشتر روی وظایف مشروع شکست می‌خورند، چون سطح پیش‌فرض framework پهن‌تر از نیاز وظیفه بود و کسی آن را هرس نکرد. اعتبارنامه‌های کوتاه‌عمر یعنی رفت‌وآمدهای بیشتر با کارگزار و یک حالت شکست جدید وقتی کارگزار در دسترس نیست. allowlistهای خروج یعنی هر یکپارچه‌سازی جدید یک تغییر policy است، نه یک تغییر کد. تیم‌هایی که لایه‌های اختیار را می‌پذیرند معمولاً پیش از تثبیت سطح policy، افزایش کوتاه‌مدت در نرخ شکست وظایف agent را می‌بینند. این هزینه بهای انتقال تضمین ایمنی از «ما متوجه می‌شدیم» به «نمی‌توانست اتفاق بیفتد» است.
چه چیزی را اندازه بگیریم
متریک‌های مهار و متریک‌های اختیار به پرسش‌های متفاوتی پاسخ می‌دهند و یکی گرفتن آن‌ها سیگنالی را که اهمیت دارد پنهان می‌کند.
- تلاش‌های فرار مسدودشده در هر هزار اجرا یک متریک مهار است. اندازه می‌گیرد که ناظر سندباکس چند وقت یک‌بار شلیک کرده است. یک عدد بالا ممکن است نشان‌دهنده یک agent پرخاشگر، یک policy بدپیکربندی‌شده، یا هر دو باشد. درباره آنچه agent مجاز به انجامش بود چیزی نمی‌گوید.
- تلاش‌های قابلیت غیرمجاز در هر هزار اجرا یک متریک اختیار است. تعداد دفعاتی را می‌شمارد که یک agent تلاش کرد ابزاری را فراخوانی کند، به یک endpoint برسد، یا برخلاف بودجه‌ای که در اختیار نداشت خرج کند. این عددی است که حوادث را پیش‌بینی می‌کند، چون شکاف میان آنچه agent باور داشت می‌تواند انجام دهد و آنچه در واقع به او اعطا شده بود را اندازه می‌گیرد.
متریک دوم سخت‌تر جمع‌آوری می‌شود، چون نیازمند آن است که لایه اختیار ردها را در نقطه تصمیم ثبت کند نه در نقطه اثر. دقیقاً به همین دلیل است که آموزنده‌تر است. سیستمی که می‌تواند ردهای اختیار خود را گزارش کند، سیستمی است که مدل اختیارش به‌قدر کافی صریح است که بتوان درباره‌اش استدلال کرد.
سطح کنترل بالای سندباکس است
پلتفرم‌های مهار مفیدند. پنجره‌ای را که یک agent بدرفتار می‌تواند در آن عمل کند کاهش می‌دهند و برای مواردی که هر لایه دیگری شکست خورده یک توقف سخت فراهم می‌کنند. اما یک توقف سخت یک پشتیبان است، نه یک سطح کنترل. سطح کنترل مجموعه تصمیماتی است که پیش از اجرای agent گرفته می‌شود: کدام ابزارها را در اختیار دارد، کدام اعتبارنامه‌ها را حمل می‌کند، به کدام endpointها می‌تواند برسد، چقدر می‌تواند خرج کند، و چه زمانی همه این‌ها منقضی می‌شوند.
خوانش ناهمسو با OpenShell نشان می‌دهد که صنعت به سمت مهار عالی همگرا می‌شود و در اختیار کم‌سرمایه‌گذاری می‌کند. راه‌حل یک کلید قطع سریع‌تر نیست. یک لایه policy است که کلید قطع را برای حوادثی که اهمیت دارند غیرضروری می‌کند.