RSA پلتفرم Agent ID را برای شناسایی و مهار عامل‌های هوش مصنوعی معرفی کرد

امنیت عامل‌های هوش مصنوعی به یکی از چالش‌های تازه سازمان‌ها تبدیل شده است؛ RSA در جریان کنفرانس The AI Conference در سان‌فرانسیسکو از پلتفرم Agent ID رونمایی کرد تا عامل‌های هوش مصنوعی را در محیط‌های سازمانی شناسایی، کنترل و پایش کند. این محصول برای صنایعی مانند بانکداری، دولت، سلامت و زیرساخت‌های حیاتی طراحی شده است؛ حوزه‌هایی که عامل‌های خودکار می‌توانند به سامانه‌های حساس و داده‌های مهم دسترسی داشته باشند.

به گفته RSA، عامل‌های هوش مصنوعی برخلاف حساب‌های خدماتی سنتی، پویا هستند و می‌توانند برای اجرای یک وظیفه از ابزارها و مجوزهای مختلف استفاده کنند. همین توانایی، در کنار رشد سریع استفاده از عامل‌ها، شناسایی مسئول هر عامل و محدودکردن دامنه فعالیت آن را به مسئله‌ای جدی برای تیم‌های امنیتی تبدیل کرده است. Jim Taylor، رئیس و مدیر ارشد محصول و راهبرد RSA، در گفت‌وگو با MarkTechPost گفت بسیاری از سازمان‌ها نمی‌دانند چه عامل‌هایی در محیط آن‌ها فعال‌اند یا در صورت بروز مشکل چگونه باید آن‌ها را متوقف کنند.

چرا امنیت عامل‌های هوش مصنوعی به مسئله هویت تبدیل شده است؟

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

Taylor می‌گوید کارکنان گاهی برای انجام یک کار فوری عامل‌هایی می‌سازند، اما پس از آن ممکن است کسی سراغ دسترسی‌ها و وضعیت عامل نرود. در نتیجه، سازمان نه‌تنها ممکن است از گسترش مجوزها بی‌خبر بماند، بلکه نداند چه کسی باید مسئولیت رفتار عامل را بپذیرد یا آن را غیرفعال کند.

اعدادی که در گزارش MarkTechPost آمده، فاصله میان گسترش عامل‌ها و آمادگی مدیریتی را نشان می‌دهد. Gartner پیش‌بینی کرده است که یک شرکت معمولی از میان ۵۰۰ شرکت بزرگ جهان تا سال ۲۰۲۸ حدود ۱۵۰ هزار عامل هوش مصنوعی داشته باشد؛ در حالی که این تعداد در سال ۲۰۲۵ کمتر از ۱۵ عامل برآورد شده بود. همچنین، طبق همین گزارش، تنها ۱۳ درصد سازمان‌ها معتقدند سازوکار مناسبی برای حاکمیت عامل‌ها دارند.

نمونه‌ای که Taylor نقل می‌کند، نشان می‌دهد سیاست رسمی لزوماً تصویر کاملی از وضعیت واقعی نیست. یک بانک جهانی متوسط به RSA گفته بود استفاده از عامل‌ها را ممنوع کرده و عامل فعالی ندارد؛ اما بررسی RSA بیش از ۴ هزار عامل را در محیط آن سازمان شناسایی کرد. این نمونه به عامل‌هایی اشاره دارد که خارج از فرایندهای رسمی فناوری اطلاعات به‌کار گرفته شده‌اند و از آن‌ها با عنوان «هوش مصنوعی سایه» یاد می‌شود. طبق داده‌ای که گزارش به IBM نسبت می‌دهد، رخدادهای مرتبط با هوش مصنوعی سایه به‌طور متوسط ۶۷۰ هزار دلار بیشتر از رخدادهای معمول هزینه دارند.

سه ماژول برای کشف، کنترل و ثبت فعالیت

RSA Agent ID از سه ماژول تشکیل شده است که می‌توانند جداگانه یا در قالب پلتفرم Unified Identity Platform شرکت به‌کار گرفته شوند. بخش Discover شبکه، دستگاه‌ها، برنامه‌ها و نقاط پایانی را بررسی می‌کند. این ماژول از اتصال به ابزارهایی مانند CrowdStrike و Zscaler استفاده می‌کند تا عامل‌ها و سرورهای MCP را پیدا کند؛ چه استفاده از آن‌ها مورد تأیید سازمان باشد و چه پنهان مانده باشد.

MCP یا Model Context Protocol، پروتکلی است که می‌تواند ارتباط مدل‌های هوش مصنوعی با ابزارها و منابع بیرونی را ممکن کند. پس از شناسایی هر عامل، Discover آن را در جایگاه یک هویت مستقل ثبت می‌کند و برایش مالک انسانی، سطح ریسک و وضعیت چرخه عمر در نظر می‌گیرد. این اطلاعات می‌توانند به ارائه‌دهندگان هویت موجود در سازمان، از جمله Microsoft Entra ID، Okta و AWS IAM، پیوند بخورند. منظور از مالک، فردی است که پاسخ‌گوی استفاده و وضعیت عامل باشد، نه صرفاً کسی که آن را ساخته است.

ماژول Secure وظیفه کنترل درخواست‌ها را دارد. این بخش مانند یک دروازه میان عامل و ابزارهای مورد استفاده‌اش قرار می‌گیرد و هر فراخوانی ابزار را با سیاست‌های سازمان می‌سنجد. بررسی می‌تواند تا سطح ابزار و آرگومان‌های درخواست انجام شود؛ یعنی سامانه فقط به نام ابزار بسنده نمی‌کند و جزئیات عملی را که عامل می‌خواهد انجام دهد نیز ارزیابی می‌کند. درخواست مجاز پذیرفته می‌شود، درخواست ناسازگار با سیاست رد می‌شود و اقدام‌های پرخطر برای بررسی به مالک عامل ارجاع داده می‌شوند.

ماژول سوم، Govern، برای ثبت و گزارش‌دهی طراحی شده است. این بخش اقدام‌های تحت کنترل را ثبت می‌کند، شواهد را به ۱۰ چارچوب مقرراتی و صنعتی متصل می‌سازد و آن‌ها را به سامانه SIEM سازمان می‌فرستد. SIEM ابزاری برای گردآوری و تحلیل رویدادهای امنیتی است. هدف از این ثبت‌ها آن است که سازمان بتواند در زمان بررسی یک رخداد نشان دهد چه سیاستی اجرا می‌شده، چه کسی تصمیم را تأیید کرده و عامل چه اقدام‌هایی انجام داده است.

نمونه‌ای از پیامد یک درخواست مبهم

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

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

RSA می‌گوید عامل‌های فرعی نیز نمی‌توانند دسترسی بیشتری از عامل اصلی به دست آورند. اگر عاملی وظیفه‌ای را به عامل دیگری بسپارد، Agent ID در زمان اجرای ابزار بررسی می‌کند که عامل واگذارکننده چه مجوزهایی دارد. بر اساس این مدل، عامل فرعی فقط می‌تواند از اختیاراتی استفاده کند که به عامل بالادستی داده شده است؛ نمی‌تواند مجوزهای عامل دیگری را به ارث ببرد یا از زنجیره واگذاری برای افزایش دسترسی استفاده کند.

تأیید انسانی هدفمند و دفاع چندلایه

در نگاه RSA، فرستادن هر درخواست برای تأیید انسانی راه‌حل مناسبی نیست. Taylor هشدار داده است که اگر کارکنان روزانه با انبوهی از پیام‌های تأیید روبه‌رو شوند، ممکن است عادت کنند همه را بپذیرند. به‌جای این رویکرد، موتور ارزیابی ریسک Agent ID رفتار معمول کاربر، نوع اقدام و حساسیت داده یا سامانه مقصد را بررسی می‌کند. تنها درخواست‌هایی که از آستانه خطر تعیین‌شده عبور کنند به انسان ارجاع داده می‌شوند.

برای نمونه، سازمان می‌تواند اجازه دهد عامل بازپرداخت‌های کمتر از ۵۰۰ دلار را خودکار انجام دهد، اما پرداخت‌های بالاتر را نیازمند تأیید مالک یا تأییدکننده دوم کند. معیار «پرخطر» را خود سازمان تعیین می‌کند و به گفته Taylor، پیشنهادهای کمکی مبتنی بر هوش مصنوعی می‌توانند در تنظیم سیاست‌ها نقش داشته باشند. تأییدها نیز از کانالی جدا از کانال خود عامل انجام می‌شوند و بر اساس توضیحات RSA، از روش‌های احراز هویت مقاوم در برابر فیشینگ استفاده می‌کنند؛ بنابراین عامل نباید به مسیر تأیید انسانی دسترسی داشته باشد.

با این حال، RSA محصول خود را جایگزین همه ابزارهای امنیتی نمی‌داند. Taylor در پاسخ به سناریوهایی مانند درخواست بازپرداخت جعلی یا سرقت کلیدهای API گفت کنترل‌های Agent ID باید در کنار سامانه‌های تشخیص تقلب، دروازه‌های API، دیواره‌های آتش و بازرسی ترافیک قرار گیرند. API کلیدی است که به یک برنامه اجازه می‌دهد با سرویس دیگری ارتباط برقرار کند. به گفته او، این پلتفرم قرار نیست همه لایه‌های امنیتی را از نو بسازد؛ هدف، افزودن کنترل‌های ویژه عامل‌ها به دفاع‌های موجود است.

این نگاه برای خطوط CI/CD و فرایندهای DevSecOps نیز اهمیت دارد. این فرایندها ابزارهای ساخت، آزمایش و انتشار نرم‌افزار را به هم پیوند می‌دهند و می‌توانند در صورت دسترسی نامناسب، به مسیر سوءاستفاده از هویت و اعتبارنامه تبدیل شوند. Taylor معتقد است این محیط‌ها باید با همان جدیتی کنترل شوند که دسترسی مدیریتی به سرورهای عملیاتی کنترل می‌شود.

طبق اعلام RSA، ماژول‌های Discover و Secure در ۱۶ نوامبر ۲۰۲۶ به‌صورت عمومی عرضه می‌شوند و Govern در نیمه نخست ۲۰۲۷ به آن‌ها می‌پیوندد. Taylor به مدیران امنیت اطلاعاتی که می‌خواهند محصول را ارزیابی کنند پیشنهاد کرده است ابتدا سه پرسش را پاسخ دهند: چه عامل‌هایی واقعاً در محیط فعال‌اند، چه انسانی مسئول هرکدام است و آیا سازمان می‌تواند در صورت لزوم آن‌ها را متوقف کند؟ او اجرای آزمایشی با اتصال چند سامانه کلیدی و فعال‌کردن قابلیت کشف را نقطه شروع می‌داند.

این خبر برای چه کسانی اهمیت دارد

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

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