در بسیاری از معماری‌های امنیتی برای عامل‌های هوش مصنوعی، وقتی موتور سیاست‌گذاری یک عمل را مجاز اعلام می‌کند، مسئله کنترل تقریباً تمام‌شده فرض می‌شود. مقاله‌ای تازه از پژوهشگران Chengdu Havenlon Security Technology این فرض را زیر سؤال می‌برد. پیشنهاد آن‌ها با نام EBL-Core میان «مجاز بودن یک عمل در لحظه تصمیم‌گیری» و «اختیار واقعی برای اجرای همان عمل» فاصله می‌گذارد.

این تفاوت برای عامل‌هایی مهم است که می‌توانند پول جابه‌جا کنند، زیرساخت را تغییر دهند، نرم‌افزار منتشر کنند، اطلاعات حفاظت‌شده را افشا کنند یا روی سامانه‌های فیزیکی اثر بگذارند. ممکن است یک عمل هنگام بررسی مجاز باشد، اما تا زمان اجرا نسخه سیاست، شواهد، شرایط محیط یا حتی محتوای دقیق عمل تغییر کرده باشد. EBL-Core می‌خواهد این وابستگی‌ها را صریح و قابل‌آزمون کند.

مجوز تصمیم با اختیار اجرا یکی نیست

EBL-Core کار خود را از جایی آغاز می‌کند که یک جزء مورد اعتماد، درخواست را به نیت ساخت‌یافته تبدیل کرده است. سپس همان نیت به یک عمل کاملاً مشخص، سیاست‌های حاکم، الزام‌های مربوط به شواهد، شواهد موجود، شرایط محیط و زمان پیوند داده می‌شود.

خروجی این مرحله چیزی است که نویسندگان آن را Execution Release Contract یا ERC می‌نامند. ERC ثبت می‌کند که چه تصمیمی گرفته شده و تحت چه شرایطی می‌توان بعداً اختیار اجرا را صادر کرد، اما خودش مجوز اجرایی نیست. اگر ERC معتبر و نتیجه آن ALLOW باشد، سامانه می‌تواند یک مجوز اجرای محدود به همان عمل صادر کند. هنگام استفاده از این مجوز، مرحله‌ای جداگانه دوباره بررسی می‌کند که شرایط هنوز برقرار است.

نکته اصلی همین جداسازی است. تصمیم مثبت نباید به اجازه‌ای قابل‌استفاده برای عملیات مشابه یا شرایط بعدی تبدیل شود.

تغییر شرایط باید مجوز قبلی را بی‌اعتبار کند

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

این رویکرد از بررسی یک توکن امضاشده سخت‌گیرانه‌تر است. یک توکن ممکن است از نظر رمزنگاری معتبر باشد، اما تصمیمی را نمایندگی کند که به‌دلیل تغییر شرایط دیگر نباید اجرا شود. در EBL-Core تازگی اطلاعات و تداوم شرایط بخشی از مرز اجراست.

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

آزمایش‌ها فقط قابلیت اجرای قرارداد را نشان می‌دهند

پژوهشگران یک نمونه اجرایی برای سناریوی انتقال مالی منتشر کرده‌اند. گزارش اعتبارسنجی آن نشان می‌دهد هر ۳۴ بردار آزمون ایستا و هر ۱۵ آزمون چرخه عمر نتیجه مورد انتظار را داشته‌اند. در ۱۰۰ آزمایش هم‌زمانی که در هر کدام ۳۲ تلاش برای استفاده از یک مجوز انجام شده، فقط یک تلاش موفق بوده و تنها یک اثر آزمایشی ثبت شده است. ۱۰۰ رقابت هم‌زمان میان لغو و استفاده از مجوز نیز به وضعیت نهایی معتبر رسیده‌اند.

این نتایج نشان می‌دهند قواعد پیشنهادی را می‌توان در نرم‌افزار پیاده کرد و آزمود. اما به معنی آماده بودن EBL-Core برای حفاظت از بانک، زیرساخت تولید یا سامانه فیزیکی واقعی نیست. خود نویسندگان صریحاً می‌گویند آزمایش آن‌ها درستی برداشت از نیت انسان، صحت شواهد، عبور همه مسیرهای اجرا از این مرز یا صحت اثر خارجی را ثابت نمی‌کند.

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

تأیید یک عمل نباید به اختیار دائمی تبدیل شود

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

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

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

EBL-Core جایگزین موتورهای مجوزدهی موجود نیست

مقاله قصد ندارد Cedar، Rego، XACML، سامانه‌های مبتنی بر قابلیت یا پایشگرهای زمان اجرا را کنار بگذارد. پیشنهاد اصلی، تعریف یک قرارداد مشترک برای چگونگی کنار هم قرار گرفتن این اجزا در مرز نهایی اجراست.

این محدودیت مهم است. EBL-Core ادعا نمی‌کند یک قالب تازه برای مجوز، مسئله امنیت عامل‌ها را حل می‌کند. در عوض مجموعه‌ای از شرایط قابل‌آزمون تعریف می‌کند: آیا نیت، عمل، سیاست، شواهد و شرایط به هم متصل شده‌اند؟ آیا مسیر تصمیم قابل‌بررسی است؟ آیا سیاست پایین‌تر نمی‌تواند محدودیت بالاتر را حذف کند؟ و آیا مجوز فقط یک‌بار و در شرایط فعلی قابل‌استفاده است؟

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

Sources
- https://arxiv.org/abs/2609.11596
- https://arxiv.org/src/2609.11596v1/anc/results/validation-summary.json