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