جیک ویلیامز، پژوهشگر امنیت، این هفته چارچوب CUSTODY را رونمایی کرد که به سازمانها راهی برای تعیین مجوزها و محدودیتهای صریح در زمان اجرا برای عاملهای هوش مصنوعی که در شبکههای سازمانی فعالیت میکنند، میدهد. این ابزار از این جهت اهمیت دارد که برخلاف نرمافزارهای سنتی، عاملهای هوش مصنوعی میتوانند بهطور پویا دادهها را فراخوانی کنند، سرویسها را فرا بخوانند و مدلها را تغییر دهند—همه اینها بدون یک سیاست شفاف و قابل اجرا انجام میشود—و شکافی را باقی میگذارد که مهاجمان از هماکنون شروع به بهرهبرداری از آن کردهاند.
چرا عاملهای هوش مصنوعی به یک حصار نیاز دارند
پشتههای هوش مصنوعی سازمانی اکنون شامل چتباتها، موتورهای توصیهگر، تصمیمگیرندگان خودگردان و دهها عامل پسزمینه هستند که دادهها را از APIهای داخلی یا سرویسهای شخص ثالث استخراج میکنند. مجموعههای امنیتی موجود بر دیوارههای آتش محیطی، حفاظت از نقاط انتهایی و بخشبندی شبکه تمرکز دارند، اما فاقد یک روش استاندارد برای بیان این موضوع هستند که: «این عامل مجاز است سوابق مشتریان را بخواند اما اجازه نوشتن در پایگاه داده مالی را ندارد.» نبود چنین کنترلهای زمان اجرایی پیش از این منجر به حوادثی شده است که در آنها از عاملهای هکشده برای استخراج غیرمجاز دادهها یا تخریب وزنهای مدل استفاده شده است.
چگونه CUSTODY این شکاف را پر میکند
CUSTODY یک زبان مبتنی بر قانون معرفی میکند که توصیف میکند یک عامل هوش مصنوعی پس از اتصال به شبکه، مجاز به انجام چه کارهایی است. سیاستها میتوانند موارد زیر را مشخص کنند:
- دسترسی به منابع – کدام پایگاههای داده، ذخیرهسازهای فایل یا APIها را عامل میتواند پرسوجو (query) کند.
- محدودیتهای عملیاتی – اینکه آیا عامل فقط میتواند بخواند، یا اجازه نوشتن، حذف یا اجرای وظایف پاییندستی را نیز دارد.
- بافت اجرا – محدودیتهایی بر محیط محاسباتی، مانند سهمیههای CPU یا جداسازی کانتینر.
در زمان اجرا، این چارچوب فراخوانیهای عامل را رهگیری کرده و آنها را با مجموعه سیاستهای تعیینشده بررسی میکند و هر عملیاتی را که خارج از محدودههای تعریفشده باشد، مسدود میسازد. این کار مانع از آن میشود که یک عامل ربودهشده بدون کنترل در محیط سازمانی پرسه بزند.
اتصال CUSTODY به پشتههای موجود
این چارچوب در کنار ابزارهای امنیتی فعلی قرار میگیرد. میتواند به پلتفرمهای محبوب ارکستراسیون، زمانهای اجرای کانتینر و درگاههای API متصل شود، اما مراحل دقیق بسته به پلتفرم زیربنایی عامل متفاوت است. سازمانها باید موجودی هوش مصنوعی خود را شناسایی کنند، فایلهای سیاست را برای هر کلاس از عاملها بنویسند و لایه اعمال قوانین را قبل از استقرار کامل آزمایش کنند. مقیاسپذیری این سیاستها برای دهها عامل، مستلزم یک تلاش عملیاتی اختصاصی برای بهروز نگه داشتن قوانین همگام با تکامل مدلها خواهد بود.
هشدارها و انتقادات
منتقدان خاطرنشان میکنند که CUSTODY سیاستها را بهطور خودکار تولید نمیکند؛ تیمهای امنیتی باید آنها را بهصورت دستی تدوین کنند که میتواند بسیار پرزحمت باشد. همچنین خطر بار اضافی بر عملکرد (performance overhead) وجود دارد، بهویژه اگر هر فراخوانی بهصورت بیدرنگ (real-time) بازرسی شود، مخصوصاً برای سرویسهای استنتاج با توان عملیاتی بالا. در نهایت، اثربخشی این چارچوب به پذیرش گسترده بستگی دارد؛ اگر پلتفرم هوش مصنوعی یک فروشنده نتواند قلابهای (hooks) لازم را ارائه دهد، ممکن است کنترلهای CUSTODY دور زده شوند.
آنچه باید در آینده زیر نظر داشت
- پاسخ فروشندگان – اینکه آیا ارائهدهندگان اصلی پلتفرمهای هوش مصنوعی، قلابهای سازگار با CUSTODY را در خود تعبیه میکنند یا موتورهای سیاست زمان اجرای خود را ارائه میدهند.
- استانداردسازی – هرگونه حرکت به سمت مشخصات استاندارد در سطح صنعت برای مجوزهای عامل هوش مصنوعی میتواند CUSTODY را به یک معیار پیشفرض (de-facto baseline) تبدیل کند.
- بازخورد جامعه – پذیرندگان اولیه، پیچیدگی سیاستها در دنیای واقعی و تأثیر عملکرد را آشکار خواهند کرد که باعث شکلگیری نسخههای آینده میشود.
سازمانهایی که به عاملهای هوش مصنوعی متکی هستند، باید همین حالا CUSTODY را ارزیابی کنند، جایگاه آن را در پشته امنیتی خود مشخص کنند و پیش از برخورد موج بعدی حملات مبتنی بر هوش مصنوعی با شبکههایشان، اجرای آزمایشی سیاستها را آغاز کنند.