یک پیشچاپ تازه روشی پیشنهاد میکند برای اینکه پیش از اعتماد به یک سازوکار نظارتی، بتوان سنجید آیا اطلاعاتی که آن سازوکار از سامانه خودکار میبیند واقعاً برای تصمیمگیری کافی است یا نه. اهمیت کار در این است که بحث را از «سیاست خوب» به «اطلاعات کافی در لحظه تصمیم» منتقل میکند. نویسنده همراه مقاله کد، دادههای آزمایش، پیشثبت نتایج و سابقه بازتولید مستقل را نیز منتشر کرده است.
مسئله اصلی ساده است: اگر یک عامل نرمافزاری اجازه تغییر کد، استقرار سرویس یا دسترسی به منابع حساس را داشته باشد، داشتن یک قانون تأیید بهتنهایی کافی نیست. سامانهای که قرار است اجازه بدهد یا مانع شود باید تفاوت میان وضعیتهایی را که تصمیم متفاوت میطلبند ببیند.
چه چیزی محاسبه میشود؟
مقاله مجموعهای محدود از وضعیتهای قابلدستیابی سامانه، نتیجهای که برای هر وضعیت باید صادر شود و چند ویژگی قابل مشاهده را در نظر میگیرد. سپس بهدنبال کوچکترین مجموعهای از این ویژگیها میگردد که با دانستن آنها بتوان برای همه وضعیتهای مدلشده تصمیم درست را تعیین کرد.
در نمونه ساختهشده برای یک عامل کدنویسی و زیرساخت ابری، شش ویژگی که هرکدام بهتنهایی ضروری تشخیص داده میشوند، در کنار هم هنوز کافی نیستند. تحلیل دو مجموعه هفتویژگی متفاوت پیدا میکند که هر دو کفایت دارند. بعد، یک مدل هزینه که از قبل ثبت شده است میان این دو گزینه تمایز میگذارد. این نتیجه نشان میدهد فهرست کردن دادههای «مهم» با اثبات کفایت اطلاعات برای تصمیمگیری یکی نیست.
برای فضای جستوجوی کوچک، همه حالتها بررسی میشوند. در نمونههای بزرگتر از SAT و MaxSAT استفاده شده است. طبق نتایج گزارششده، در جایی که بررسی کامل در مهلت ۳۰۰ ثانیهای عملی نیست، روشهای ترکیبی آزمایششده در کمتر از یک ثانیه جواب دادهاند. نویسنده صریحاً تأکید میکند که این نتیجه درباره یک ابزار محاسباتی است و نباید آن را اثبات ایمنی یک سامانه واقعی دانست.
پرسش مهم برای سامانههای عاملمحور
در بسیاری از طراحیها ابتدا سیاست نوشته میشود و بعد هر دادهای که در دسترس است به بخش تأیید فرستاده میشود. این پژوهش پیشنهاد میکند بخشی از مسیر برعکس طی شود: ابتدا مشخص کنیم چه زیانهایی باید جلوگیری شوند و عامل به چه وضعیتهایی میتواند برسد؛ سپس بسنجیم آیا اطلاعاتی که هنگام تصمیم در اختیار بخش کنترل قرار میگیرد برای تشخیص همه حالتهای مهم کافی است.
برای یک عامل کدنویسی یا ابری، ممکن است هویت شاخه کد، محیط اجرا، دامنه اعتبارنامه، مقصد استقرار یا وضعیت مخزن اهمیت داشته باشد. مقاله ادعا نمیکند این فهرست در همه سامانهها یکسان است. نکته این است که باید ترکیب لازم برای همان سامانه محاسبه و آزموده شود.
تحلیل Aipolix: مشکل میتواند در مرز میان اجرا و کنترل باشد
نتیجه کاربردی این پژوهش برای معماری سامانههای عاملمحور روشن است. اگر بخش مجوزدهی به اطلاعاتی نیاز دارد که محیط اجرای عامل آنها را قابل اتکا در اختیارش نمیگذارد، افزودن یک دستور متنی دیگر مشکل را حل نمیکند. نقص در رابط میان بخش اجرا و بخش کنترل است.
برای بازبینی یک پلتفرم عاملمحور میتوان تصمیمهایی را که باید از هم تفکیک شوند مشخص کرد، وضعیتهای قابلدستیابی را مدل کرد و آزمود آیا دادههای قابل مشاهده هر دو وضعیتی را که نتیجه متفاوت میخواهند از هم جدا میکنند یا نه. اگر پاسخ منفی باشد، سه راه باقی میماند: اطلاعات بیشتری در اختیار کنترل قرار گیرد، دامنه وضعیتهای قابلدستیابی محدود شود، یا اختیار پشت آن دروازه کاهش یابد.
این نگاه یک نکته دیگر را هم روشن میکند. اصل حداقل دسترسی مهم است، اما کافی نیست. محدود کردن مجوزها تعیین میکند چه کارهایی اصولاً ممکناند؛ با این حال سازوکار تأیید همچنان باید بداند یک اقدام مجاز در چه شرایطی باید انجام شود.
شواهد قابل بررسیاند، اما دامنه نتیجه محدود است
مخزن عمومی شامل پیادهسازی، نمونههای آزمایشی، پیشثبت، آزمونها، دستور بازتولید و سابقه یک بازتولید مستقل است. برای یک پیشچاپ، این سطح از امکان بررسی امتیاز مهمی است.
با این حال، محیطهای اصلی ساختهشدهاند، تعداد وضعیتها محدود فرض شده و نتیجه مورد انتظار برای هر وضعیت قطعی است. سامانههای واقعی با اطلاعات ناقص، ابزارهای در حال تغییر، سیاستهای پویا و رفتار خصمانه روبهرو هستند. مقاله نشان نمیدهد که این قراردادهای مشاهده در صورت اشتباه بودن مدل یا تغییر محیط همچنان کافی میمانند.
بنابراین ارزش فوری کار، ادعای حل مسئله حکمرانی عاملها نیست. دستاورد اصلی یک آزمون مهندسی دقیقتر است: پیش از اعتماد به یک دروازه تأیید، باید مطمئن شد آن دروازه واقعاً اطلاعات لازم برای تمایزهایی را که سیاستش فرض میکند در اختیار دارد.