آژانس‌های پنج چشم: بیشتر استقرارهای AI عاملی از هم‌اکنون دسترسی‌های بیش از اندازه دارند

اشتراک‌گذاری:
آژانس‌های پنج چشم: بیشتر استقرارهای AI عاملی از هم‌اکنون دسترسی‌های بیش از اندازه دارند

در اول مه ۲۰۲۶، CISA، NSA و همتایان آن‌ها از بریتانیا، استرالیا، کانادا و نیوزیلند نخستین راهنمای امنیتی هماهنگ چندجانبه‌ی دولتی برای Agentic AI را با عنوان «پذیرش محتاطانه خدمات Agentic AI» منتشر کردند. پیام محوری این سند صریح است: سازمان‌های زیرساخت حیاتی و دفاعی در حال ارزیابی یک خطر آینده نیستند — آن‌ها هم‌اکنون Agent‌هایی را اجرا می‌کنند که سطح دسترسی‌شان از آنچه تیم‌های امنیتی خود این سازمان‌ها می‌توانند پیگیری کنند فراتر رفته است، و این راهنما از آن جهت منتشر شده که این شکاف دیگر صرفاً نظری نیست.

آنچه این سند را حتی برای سازمان‌هایی که در حوزه زیرساخت حیاتی فعالیت نمی‌کنند نیز شایسته بررسی دقیق می‌سازد، این است که این نخستین تلاش نهادهای امنیتی برای دسته‌بندی رسمی خطاهای احتمالی یک AI Agent است — در تمایز با یک برنامه کاربردی سنتی — و این دسته‌بندی‌ها دقیقاً بر اشتباهاتی منطبق می‌شوند که اکثر تیم‌های در حال استقرار Agent در حال حاضر مرتکب آن‌ها می‌شوند.

پنج دسته ریسک، و دلایل فروکاسته نشدن آن‌ها به «Prompt Injection»

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

ریسک امتیاز دسترسی به معنای نگه‌داشتن دسترسی دائمی Agent به سیستم‌ها، داده‌ها، یا اقدامات بسیار فراتر از آنچه هر وظیفه واحد نیاز دارد، است — معادل هوش مصنوعی یک حساب کاربری سرویس با دسترسی مدیریت دامنه، صرفاً به این دلیل که کسی وقت نکرده آن را محدود کند. ریسک طراحی و پیکربندی Agent‌هایی را دربرمی‌گیرد که به زنجیره ابزارها و منابع داده خارجی متصل شده‌اند، بدون اینکه کسی ترسیم کرده باشد که این اتصال‌ها در واقع چه چیزی را در معرض نمایش می‌گذارند. ریسک رفتار به این اشاره دارد که Agent کاری ناخواسته انجام می‌دهد، حتی بدون دستکاری خارجی — یک اقدام نوظهور که هیچ‌کس آن را صریحاً برنامه‌ریزی نکرده است. ریسک ساختاری به وابستگی‌های لایه‌به‌لایه‌ای مربوط می‌شود که Agent‌ها معرفی می‌کنند؛ یک ابزار یا منبع داده به خطر افتاده، به معنای Agent به خطر افتاده است. ریسک پاسخگویی دشوارترین ریسک برای رفع پس از استقرار است: وقتی یک Agent اقدام مهمی انجام می‌دهد، آیا کسی می‌تواند دلیل آن را بازسازی کند، و مسئولیت وقوع آن با کیست؟

مشکل سطح حمله به‌هم‌پیوسته

این راهنما به‌صراحت بیان می‌کند که مشکل اصلی امنیتی Agentic AI، مدل زبانی نیست — بلکه تعداد اجزایی است که یک Agent معمولاً با آن‌ها در تماس است. یک Agent پشتیبانی مشتری ممکن است با یک CRM API، یک پایگاه دانش، یک سیستم صدور بلیط و یک ابزار ایمیل در ارتباط باشد که هر کدام اعتبارنامه‌ها و نقاط خرابی خاص خود را دارند. این سند هشدار می‌دهد که این وضعیت «سطح حمله‌ای به‌هم‌پیوسته ایجاد می‌کند که عوامل مخرب می‌توانند از آن بهره‌برداری کنند»، زیرا به خطر انداختن هر یک از حلقه‌های این زنجیره می‌تواند دسترسی‌های مؤثر Agent را در تمام آن‌ها به خطر بیندازد.

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

آنچه این راهنما در عمل از شما می‌خواهد

اگر قاب‌بندی کلی را کنار بگذاریم، هسته عملیاتی این سند پنج قانون است که همه آن‌ها با ابزارهای موجود مدیریت هویت و دسترسی در حال حاضر قابل اجرا هستند:

هرگز به Agent‌ها دسترسی گسترده یا نامحدود ندهید. اگر حساب کاربری سرویس یک Agent بتواند بیش از آنچه فهرست وظایف مستند آن نیاز دارد انجام دهد، همین شکاف است که مهاجمان از آن استفاده خواهند کرد — و معمولاً این شکافی است که برای راحتی در مرحله استقرار اولیه ایجاد شده، نه یک تصمیم آگاهانه.

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

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

برای اقدامات پرتأثیر، تأیید انسانی را الزامی کنید — تراکنش‌های مالی، حذف داده، تغییرات کنترل دسترسی، و هر چیزی که هزینه‌بر یا دشوار برای بازگشت است. این راهنما این موضوع را به‌عنوان یک الزام غیرقابل مذاکره می‌داند، نه یک ویژگی اختیاری برای استقرارهای اولیه.

امنیت AI Agent را در چارچوب‌های امنیت سایبری موجود مدیریت کنید، نه به‌عنوان یک برنامه موازی و سفارشی جداگانه. Agent‌ها باید در همان فهرست دارایی‌ها، بازبینی‌های دسترسی، و دستورالعمل‌های واکنش به حوادثی ظاهر شوند که هر مؤلفه دیگر سیستم دارای اعتبارنامه و دسترسی شبکه در آن‌ها قرار می‌گیرد.

نکته کلیدی برای تیم‌هایی که این فصل Agent به محیط تولید می‌فرستند

اگر در حال استقرار یک AI Agent در محیط تولید هستید و نمی‌توانید به این سؤال پاسخ دهید که «در صورت به خطر افتادن نشست این Agent در حال حاضر، حداکثر دامنه آسیب چقدر است»، راهنمای Five Eyes می‌گوید که شما با یک مشکل امتیاز دسترسی روبه‌رو هستید، نه یک مشکل مدل. پیش از استقرار بعدی Agent خود، یک بررسی دسترسی انجام دهید: فهرستی از تمام ابزارها، API‌ها و منابع داده‌ای که Agent می‌تواند به آن‌ها دسترسی داشته باشد تهیه کنید، سپس بپرسید که آیا هر کدام با محدودترین مجوز وظیفه‌محور تعریف شده‌اند یا با یک دسترسی گسترده در سطح سرویس. همین یک تمرین، شکافی را می‌بندد که اکثر بررسی‌های پس از حادثه امسال در آن اشتراک دارند.

اشتراک‌گذاری:
راهنمای پنج چشم درباره امنیت AI عاملی | IRCNF | AIO APEX