تصور کنید یک کارمند پشتیبانی با یک درخواست ساده، کل زیرساخت نرم‌افزاری شرکتش را فلج کند. این کابوس زمانی رخ داد که یک کاربر از یک عامل (Agent) — شبیه دستیاری که دستورات شما را در سیستم اجرا می‌کند — خواست تا «تمام داده‌ها» را برای نمودارهای سلامتی استخراج کند. این درخواست در ظاهر ساده بود، اما برای یک هوش مصنوعی که مفهوم «حد و مرز» را نمی‌شناسد، به معنای استخراج کامل پایگاه داده بود.
به نقل از جیم تیلور، رئیس بخش محصول و استراتژی RSA، این عامل سعی کرد کل پایگاه داده را دانلود کند. سیستم‌های امنیتی Salesforce این حجم عظیم و غیرعادی از درخواست را به عنوان یک حمله منع سرویس (DoS) شناسایی کردند و برای جلوگیری از تخریب بیشتر و حفظ پایداری سیستم، کل نمونه (Instance) شرکت را به‌صورت فوری خاموش کردند. این اتفاق نشان‌دهنده یک مرز جدید از ریسک‌های سازمانی است: عامل‌های خودمختاری که قدرت اجرایی دارند اما نمی‌دانند کجا باید متوقف شوند.
این بحران در حالی رخ می‌دهد که شرکت‌ها از چت‌بات‌های استاتیک و ساده به سمت عامل‌های پویا می‌روند؛ عامل‌هایی که دارای اعتبارنامه‌های دسترسی (Credentials) هستند و مستقیماً روی سیستم‌های ثبت داده (Systems of Record) اثر می‌گذارند. همان‌طور که در تحلیل قبلی ما درباره‌ی بحران هویت در حساب‌های سرویس مشترک اشاره کردیم، صنعت اکنون با پدیده‌ای به نام «گسترش خودمختاری» (Autonomy Sprawl) روبروست. برخلاف IT سایه (Shadow IT) قدیمی که در آن یک کارمند ممکن بود از یک ابزار SaaS غیرمجاز استفاده کند، هوش مصنوعی سایه (Shadow AI) فقط در پس‌زمینه حضور ندارد، بلکه فعال است، اقدام می‌کند و اغلب سیاست‌های شرکتی را به‌طور کامل نادیده می‌گیرد. برای مقابله با این چالش، راهکارهای عملیاتی برای بستن شکاف‌های انطباق در سازمان‌ها پیشنهاد شده است تا ریسک‌های ناشی از ابزارهای غیرمجاز کاهش یابد.
طبق گزارش Gartner، یک شرکت معمولی از لیست Global Fortune 500 تا سال ۲۰۲۸ حدود ۱۵۰ هزار عامل هوش مصنوعی را اجرا خواهد کرد؛ این یک جهش عظیم نسبت به سال ۲۰۲۵ است که در آن تعداد این عامل‌ها کمتر از ۱۵ عدد بود. با این حال، تنها ۱۳٪ از سازمان‌ها معتقدند که حاکمیت (Governance) و نظارت لازم بر این ابزارها را در جایگاه درست خود دارند. مخاطرات مالی این وضعیت بسیار بالاست؛ IBM گزارش داده است که حوادث مربوط به هوش مصنوعی سایه، به‌طور متوسط ۶۷۰ هزار دلار بیشتر از حوادث امنیتی استاندارد هزینه برمی‌دارند.
اپیدمی عامل‌های سایه
یافته‌های RSA نشان می‌دهد که ممنوعیت‌های اداری و سیاست‌های مکتوب معمولاً بی‌اثر هستند. به عنوان مثال، یک بانک جهانی با ابعاد متوسط ادعا می‌کرد که به دلیل سیاست‌های داخلی سختگیرانه، هیچ عاملی در شبکه ندارد. اما بازرسی فنی RSA نشان داد که بیش از ۴ هزار عامل در سراسر سازمان در حال فعالیت هستند. همان‌طور که تیلور اشاره کرد: «عامل‌ها تمایلی به رعایت سیاست‌ها ندارند».
این عامل‌ها یک خلأ امنیتی منحصر‌به‌فرد ایجاد می‌کنند چون برخلاف حساب‌های سرویس سنتی، پویا هستند. آن‌ها صرفاً یک حساب کاربری ساده نیستند. اگر یک وظیفه یا دستور به صورت مبهم یا بد نوشته شود، عامل هر کاری را که برای اجرای آن لازم بداند انجام می‌دهد. نکته خطرناک این است که برخلاف انسان‌ها، آن‌ها «ساعت دو صبح خسته نمی‌شوند» و با همان سرعت و شدت به اجرای دستورات ادامه می‌دهند.
علاوه بر این، عامل‌ها به مرور زمان بدون هیچ نظارتی، مجوزها، داده‌ها و دسترسی‌های بیشتری را جمع‌آوری می‌کنند. کارکنان اغلب یک عامل را برای رسیدن به یک ضرب‌الاجل (Deadline) خاص می‌سازند، اما وقتی این عامل «در دنیای واقعی رها شد»، به‌ندرت مانیتور می‌شود. سازمان‌ها مکرراً فراموش می‌کنند بررسی کنند که چه زمانی مجوزها تغییر کرده‌اند یا پس از پایان هدف عامل، آن را حذف و غیرفعال کنند.
معرفی RSA Agent ID
برای حل این مشکل، RSA پلتفرم RSA Agent ID را معرفی کرد؛ یک پلتفرم امنیت هویت عامل‌محور که برای صنایع تحت نظارت شدید مانند مالی، دولتی، بهداشت و زیرساخت‌های حیاتی طراحی شده است. این سیستم از طریق سه ماژول اصلی عمل می‌کند که هم به‌صورت مجزا و هم به عنوان بخشی از پلتفرم یکپارچه هویت RSA در دسترس هستند:
- Discover (کشف): این ماژول نقاط انتهایی (Endpoints)، دستگاه‌ها، شبکه‌ها و اپلیکیشن‌ها را به‌صورت زنده از طریق کانکتورهایی به ابزارهایی مانند CrowdStrike و Zscaler اسکن می‌کند. این ابزار هم عامل‌های مجاز و هم عامل‌های سایه و سرورهای MCP را پیدا می‌کند. هر عامل به عنوان یک هویت درجه‌یک با یک مالک مشخص، سطح ریسک و وضعیت چرخه عمر ثبت می‌شود و به ارائه‌دهندگان هویت مانند Microsoft Entra ID، Okta یا AWS IAM متصل می‌گردد. تیلور تأکید می‌کند که هر عامل حتماً باید به یک هویت انسانی متصل باشد.
- Secure (تأمین): یک درگاه (Gateway) هوش مصنوعی/MCP است که هر فراخوانی ابزار را در هر دو سطح «ابزار» و «آرگومان» با سیاست‌های تعریف شده چک می‌کند. فراخوانی‌هایی که مطابق سیاست باشند اجازه عبور دارند و موارد مخالف رد می‌شوند. فراخوانی‌های پرریسک از طریق یک کانال خارج از باند (Out-of-band) و احراز هویت شده، با استفاده از اعتبارنامه‌های ضد-فیشینگ که عامل‌ها به آن‌ها دسترسی ندارند، به مالک ثبت‌شده ارسال می‌شوند تا تایید شوند.
- Govern (حاکمیت): تمام اقدامات تحت نظارت را ثبت کرده و شواهد را با ده چارچوب رگولاتوری و صنعتی به‌صورت پیش‌فرض تطبیق می‌دهد. این داده‌ها به سیستم SIEM مشتری ارسال می‌شود. این قابلیت نیاز بازرسانی را برآورده می‌کند که خواستار لاگ‌های تغییرناپذیری هستند تا بدانند در زمان حادثه چه سیاستی حاکم بوده، چه کسی اقدام را تایید کرده و دقیقاً چه اتفاقی افتاده است.
فراتر از «انسان در حلقه»
جیم تیلور استدلال می‌کند که گردش کارهای سنتی «تایید/رد» منجر به خستگی کاربر (Fatigue) می‌شود؛ وضعیتی که در آن کاربران روزانه صدها اعلان را بدون خواندن و صرفاً با کلیک روی «بله» می‌پذیرند. او این وضعیت را نوع دیگری از حمله منع سرویس (DoS) توصیف می‌کند. به جای این مدل، RSA Agent ID از یک موتور ریسک استفاده می‌کند تا اقدامات را بر اساس سه معیار امتیازدهی کند:
۱. کاربر: آیا این رفتار برای این کاربر خاص مورد انتظار است؟
۲. اقدام: آیا عامل در حال انجام یک عملیات خواندن (Read)، نوشتن (Write) یا چیزی پرریسک‌تر است؟
۳. هدف: داده‌ها و نقطه انتهایی مورد دسترسی چقدر حساس هستند؟
برای مثال، یک عامل بازپرداخت وجه می‌تواند درخواست‌های زیر ۵۰۰ دلار را به‌طور خودکار پردازش کند. اما هر مبلغی که از این آستانه فراتر رود، تایید انسانی اجباری یا حتی تایید نفر دوم از طریق یک گردش کار داخلی را فعال می‌کند. از آنجایی که سازمان‌ها ریسک کسب‌وکار خود را بهتر می‌شناسند، مشتری تعریف می‌کند که چه چیزی «پرریسک» محسوب می‌شود و هوش مصنوعی در این مسیر پیشنهاداتی ارائه می‌دهد.
بستن حفره‌های تفویض اختیار
یکی از خطرناک‌ترین روندها در ارکستراسیون چند-عاملی، ارتقای سطح دسترسی (Privilege Escalation) از طریق تفویض اختیار است. زمانی که عامل‌ها، زیر-عامل‌هایی (Sub-agents) ایجاد می‌کنند یا وظایف را به دیگری می‌سپارند، RSA Agent ID این فرآیند را در لحظه اجرای ابزار رهگیری کرده و یک مدل «مجوز ارثی» را اعمال می‌کند.
در این مدل، یک عامل تنها می‌تواند به عامل دیگر مجوزهایی بدهد که خودش قبلاً دریافت کرده است. عامل نمی‌تواند از مجوزهای یک عامل دیگر برای دور زدن کنترل‌های امنیتی استفاده کند. اگر یک زیر-عامل سعی کند وظیفه‌ای غیرمجاز را انجام دهد، سیستم می‌پرسد چه کسی درخواست این اقدام را داده است و در صورت نبود مجوز، درخواست را رد می‌کند.
دفاع لایه‌ای و محدودیت‌ها
تیلور صادقانه درباره محدودیت‌های سیستم می‌گوید و اشاره می‌کند که این ابزار یک «گلوله نقره‌ای» یا راهکار جادویی نیست. در حالی که درگاه امنیتی می‌تواند دستورات مخرب در یک پرامپت را شناسایی کند (مانند یک تیکت پشتیبانی که از طریق Prompt Injection درخواست بازپرداخت جعلی می‌دهد)، اما نمی‌تواند جلوی کلاهبرداری را بگیرد اگر فردی از یک دستگاه سرقتی استفاده کند. او اشاره می‌کند که اگرچه مدل‌ها دارای نرده‌های حفاظتی (Guardrails) هستند، اما این‌ها کافی نیستند و همچنان به یک سیستم مجزای تشخیص کلاهبرداری نیاز است.
او همچنین درباره دور زدن درگاه (Gateway Bypass) هشدار می‌دهد؛ مثلاً زمانی که عامل‌های کدنویسی، کلیدهای API را از یک مخزن (Repository) می‌دزدند. برای مقابله با این مورد، او پیشنهاد می‌کند که درگاه‌های API، فایروال‌ها و بازرسی ترافیک باید همچنان فعال بمانند. تیلور می‌گوید: «ما نیاز نداریم امنیت را از نو اختراع کنیم، بلکه باید امنیت عامل‌محور را روی لایه‌های امنیتی موثری که از قبل وجود دارند، اضافه کنیم».
یک اصل کلیدی در طراحی، جداسازی کانال مجوزدهی از کانال ارتباطی عامل است. تیلور این را به یک امتحان تشبیه می‌کند: اگر به یک عامل بگویید فقط نمره خوب بگیرید، راحت‌ترین راه دزدیدن جواب‌هاست. با نگه داشتن کانال تایید در خارج از باند (Out-of-band)، این مسیر مسدود می‌شود.
زمان‌بندی اجرا
برای مدیران امنیت (CISO)، اولویت فوری پاسخ به سه سوال است: کدام عامل‌ها در محیط شما در حال اجرا هستند (نه فقط پروژه‌های AI رسمی)؟ چه کسی مالک آن‌هاست (کدام انسان مسئول است)؟ و آیا در صورت رفتار نادرست، می‌توانید آن‌ها را متوقف کنید؟ اکثر مدیران اجرایی در حال حاضر نمی‌توانند به این سوالات پاسخ دهند.
تیلور یک برنامه آزمایشی (Pilot) را توصیه می‌کند که در آن شرکت‌ها چند سیستم کلیدی را متصل کرده و ماژول Discover را اجرا کنند. این کار معمولاً نتایج غافلگیرکننده‌ای دارد و «مهمات داخلی» لازم برای تعیین مالکان و ساخت سیاست‌ها را فراهم می‌کند.
ماژول‌های RSA Agent ID Discover و Secure برای عرضه عمومی در ۱۶ نوامبر ۲۰۲۶ برنامه‌ریزی شده‌اند. ماژول Govern نیز در نیمه اول سال ۲۰۲۷ از راه می‌رسد.
این تغییر، نشان‌دهنده یک گذار در فلسفه امنیتی است. ما از مدیریت «حساب‌ها» به سمت مدیریت «رفتارها» حرکت می‌کنیم. هدف دیگر فقط دور نگه داشتن افراد غیرمجاز نیست، بلکه نگه داشتن عامل‌های مجاز در مرزهای تعیین‌شده است.
همان‌طور که عامل‌ها مدیریت بخش‌های بیشتری از ستون فقرات شرکت‌ها را بر عهده می‌گیرند، میدان نبرد بعدی خط لوله‌های CI/CD و DevSecOps خواهد بود. تیلور استدلال می‌کند که این بخش‌ها اکنون سطوح اصلی حمله به هویت هستند و به همان کنترل‌های سختگیرانه‌ای نیاز دارند که برای دسترسی ادمین سرورهای عملیاتی (Production) استفاده می‌شود.
گفتگو