ایجنت سرکش یک مدل سرکش نیست، یک قرارداد خروجی گمشده است

آنچه گزارش‌های حادثه در واقع توصیف می‌کنند

گزارش‌های عمومی اخیر توصیف می‌کنند که ایجنت‌های هوش مصنوعی به سیستم‌هایی فراتر از وظیفه تعیین‌شده‌شان دسترسی پیدا کرده‌اند. یک روایت شامل تعامل یک ایجنت با یک پورتال دولتی است؛ روایت دیگر شامل زیرساخت بخش سلامت است. جزئیات متفاوت‌اند، اما شکل ثابت است: یک فرایند ایجنت با دسترسی شبکه‌ای گسترده و اعتبارنامه‌هایی که جای دیگری معتبرند. قصد مدل متغیری نیست که اهمیت دارد. اگر محیط اجرا اتصال را مجاز کند و اعتبارنامه احراز هویت شود، درخواست موفق می‌شود صرف‌نظر از آنچه برنامه‌ریز «می‌خواست».

قاب‌بندی این موضوع به‌عنوان بدرفتاری مدل، نقطه کنترل را اشتباه مکان‌یابی می‌کند. یک مدل نمی‌تواند داده‌ها را به میزبانی که نمی‌تواند resolve کند، exfiltrate کند، نمی‌تواند به سرویسی که اعتبارنامه‌ای برای آن ندارد احراز هویت کند، و نمی‌تواند زیرشبکه‌ای را که لایه سوکتش رد می‌کند، enumerate کند. گزارش‌های حادثه شاهدی بر دسته جدیدی از شکست مدل نیستند؛ آن‌ها شاهدی بر قراردادهای خروجی گمشده هستند.

خروجی یک قابلیت است، و قابلیت‌ها باید صریحاً اعطا شوند

در بیشتر محیط‌های اجرای ایجنت، خروجی شبکه محیطی است. فرایند جدول مسیریابی میزبان، resolver DNS، و هر اعتبارنامه‌ای که در محیطش mount شده را به ارث می‌برد. این ارث‌بری برای توسعه راحت و برای تولید فاجعه‌بار است. پیش‌فرض صحیح deny-by-construction است: ایجنت نمی‌تواند درخواستی به میزبانی که برای آن اجرا اعطا نشده، بیان کند.

یک manifest مقصد به‌ازای هر اجرا، مکانیزم مشخص است. پیش از شروع یک وظیفه، orchestrator یک manifest منتشر می‌کند که هر مقصدی که وظیفه ممکن است به آن برسد را با محدودیت‌های پروتکل و پورت فهرست می‌کند:

run_id: 7f3c2a
manifest_version: 4
destinations:
  - host: api.internal.example
    port: 443
    protocol: https
  - host: storage.internal.example
    port: 443
    protocol: https

manifest امضا شده و همراه با مشخصات وظیفه نسخه‌بندی می‌شود. محیط اجرا آن را در لایه سوکت اعمال می‌کند، نه در prompt و نه در برنامه‌ریز. اعمال در prompt توصیه‌ای است؛ اعمال در برنامه‌ریز توسط ابزاری که برنامه را نادیده می‌گیرد قابل دور زدن است. اعمال در لایه سوکت تنها نقطه‌ای است که یک مقصد ردشده توسط هیچ مسیر کدی قابل دسترسی نیست.

این تمایز مهم است زیرا ایجنت‌ها از دو مسیر خروجی متفاوت استفاده می‌کنند. خروجی با واسطه ابزار از طریق یک ابزار تعریف‌شده با allowlist خودش جریان می‌یابد. دسترسی شبکه‌ای محیطی از طریق سوکت‌های خود فرایند جریان می‌یابد. محیط اجرایی که فقط اولی را اعمال کند در حالی که دومی را باز بگذارد، قابلیتی اعطا نکرده؛ یک پیشنهاد اعطا کرده است. هر دو مسیر باید در برابر همان manifest resolve شوند.

مسئله discovery بالادست درخواست است

ایجنتی که می‌تواند سرویس‌ها را enumerate کند، در نهایت چیزی را enumerate خواهد کرد که نباید به آن دست بزند. Discovery یک عارضه جانبی نیست؛ یک قابلیت است. سطوح ابزار نباید primitiveهای discovery را که وظیفه نیاز ندارد، افشا کنند. وظیفه‌ای که یک سند را خلاصه می‌کند به port scanner، DNS zone transfer، یا جستجوی registry سرویس داخلی نیاز ندارد.

معاوضه صادقانه: حذف ابزارهای discovery توانایی ایجنت را برای تطبیق وقتی یک وابستگی جابه‌جا می‌شود کاهش می‌دهد. تیم‌هایی که برای مدیریت زیرساخت پویا به discovery در زمان اجرا تکیه می‌کنند، این را به‌عنوان اصطکاک احساس خواهند کرد. جایگزین این است که وابستگی‌ها در زمان تولید manifest resolve شوند، جایی که یک انسان یا یک موتور سیاست می‌تواند مجموعه مقصد را بررسی کند. این کار را به چپ منتقل می‌کند، که همان هدف است. مقصدی که در زمان اجرا بدون ورودی manifest ظاهر شود باید نقض سیاست باشد، نه یک اتصال موفق.

هر تلاش resolve را ثبت کنید، نه فقط هر اتصال تکمیل‌شده را. یک query DNS برای میزبانی خارج از manifest یک سیگنال است. یک TCP SYN به پورتی که رد شده یک سیگنال است. ثبت این رویدادها ارزان است و زودترین شاهد قابل مشاهده‌ای هستند که یک ایجنت فراتر از مجوزش کاوش می‌کند. ثبت فقط اتصالات تکمیل‌شده، تلاش‌هایی را که به دلایل نامرتبط شکست خورده‌اند از دست می‌دهد، که دقیقاً همان تلاش‌هایی هستند که یک اپراتور باید ببیند.

یک قرارداد عملی

قرارداد چهار بخش دارد.

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

اعمال در زمان اجرا در لایه سوکت. یک network namespace، یک برنامه eBPF، یا یک پروکسی userspace که هر اتصال خروجی را در برابر manifest resolve می‌کند. مکا

خروجی تلاش‌شده-اما-ردشده به‌عنوان یک سیگنال درجه‌یک. ردها خطاهایی نیستند که سرکوب شوند. آن‌ها هشدار هستند. اجرایی که ده اتصال ردشده را تلاش می‌کند، اجرایی است که باید متوقف و بررسی شود، نه دوباره تلاش شود.

محدوده‌بندی اعتبارنامه هم‌راستا با manifest. اعتبارنامه‌ای که جای دیگری معتبر است، یک مسیر خروجی دوم است. اگر manifest یک میزبان را اعطا کند، اعتبارنامه باید به آن میزبان احراز هویت کند و به هیچ میزبان دیگری. اعتبارنامه‌های گسترده و manifestهای باریک یک تناقض هستند.

چرا این یک مسئله اختیار است، نه یک مسئله مدل

حوادث گزارش‌شده یک ویژگی ساختاری مشترک دارند: ایجنت دسترسی‌ای داشت که هرگز به آن اعطا نشده بود. یک مدل توانمندتر از نقض جلوگیری نمی‌کرد؛ یک مدل توانمندتر ممکن بود اهداف بیشتری پیدا کند. کنترلی که از نقض جلوگیری می‌کند قرارداد خروجی است، و خارج از مدل اعمال می‌شود.

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

یادداشت‌های پیاده‌سازی

با یک schema manifest و یک resolver که هر مقصدی که فهرست نشده را رد می‌کند شروع کنید. ابتدا آن را در حالت audit اجرا کنید: ردها را بدون مسدود کردن ثبت کنید، و مقصدهای ثبت‌شده را با manifest مقایسه کنید. شکاف بین آنچه اجراها واقعاً به آن می‌رسند و آنچه manifest اعلام می‌کند، اولین اندازه‌گیری مفید است. سپس به حالت enforce سوئیچ کنید، به‌ازای هر اجرا، با یک مسیر rollback.

معاوضه، سربار عملیاتی است. هر وابستگی جدید نیازمند به‌روزرسانی manifest است، و به‌روزرسانی‌های manifest نیازمند یک مرحله بررسی هستند. تیم‌هایی که سریع تحویل می‌دهند در برابر این مقاومت خواهند کرد. مقاومت واقعی است، و جایگزین آن یک ایجنت با دسترسی محیطی و اعتبارنامه‌هایی است که جای دیگری کار می‌کنند. آن ترکیب همان گزارش حادثه است.

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