مشکل عامل های هوش مصنوعی شخص ثالث؛ چرا ابزارهای امنیتی برای هوش مصنوعی انتخاب شده، عامل های ناخواسته را نادیده می گیرند؟

بر اساس داده های بررسی شده در گزارش «وضعیت امنیت عامل های هوش مصنوعی در سال ۲۰۲۶»، حدود ۱۲۸۰ محصول متعلق به شرکت های ثالث اکنون قابلیت های هوش مصنوعی را در خود جای داده اند. از میان این محصولات، تنها حدود ۲۸۲ مورد از سامانه ورود یکپارچه (SSO) استفاده می کنند. به این ترتیب، نزدیک به هزار محصول دیگر به طور پیش فرض از دید زیرساخت های مدیریت هویت سازمان ها پنهان می مانند؛ نه به این دلیل که عمدا مخفی شده اند، بلکه چون سامانه های مدیریت هویت فقط می توانند ابزارهایی را کنترل کنند که از طریق آنها احراز هویت می شوند؛ در حالی که بسیاری از عامل های هوش مصنوعی چنین مسیری ندارند.

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

چرا مرحله انتخاب و پذیرش هوش مصنوعی اهمیت داشت؟

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

اما عامل های هوش مصنوعی تعبیه شده در محصولات موجود می توانند از این مرحله عبور کنند. برای نمونه، قابلیت Slack Code شرکت Salesforce که در اوت ۲۰۲۶ معرفی شد، به کاربران اجازه می دهد یک عامل برنامه نویسی را در هر گفت وگو فراخوانی کنند. این عامل می تواند محتوای مشترک در گفت وگو را بخواند، کد تولید کند و درخواست ادغام کد (Pull Request) ایجاد کند.

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

سه مسیر ورود عامل های هوش مصنوعی به سازمان

مدیران امنیتی معمولا عامل های هوش مصنوعی را در دو گروه قرار می دهند: ابزارهای خریداری شده و ابزارهای ساخته شده در داخل سازمان. اما گروه سومی نیز وجود دارد که به گفته این تحلیل، بزرگ ترین بخش را تشکیل می دهد. این عامل ها از طریق به روزرسانی محصولات موجود وارد سازمان می شوند و بدون تصمیم گیری مستقل برای پذیرش هوش مصنوعی، در اختیار کاربران قرار می گیرند.

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

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

صرف نظر از اینکه عامل از کجا آمده باشد، ممکن است در نهایت به سامانه های مختلف سازمان دسترسی پیدا کند. برای مثال، عاملی که در یک نرم افزار مدیریت ارتباط با مشتری (CRM) ایجاد شده است، می تواند داده های انبار اطلاعات را بخواند و در سامانه مدیریت درخواست ها تغییر ایجاد کند. عامل دیگری که روی یک پلتفرم ابری ساخته شده، ممکن است توکن های دسترسی به Salesforce، Slack و Google Drive را در اختیار داشته باشد. بنابراین، نقطه اصلی اجرای این عامل ها لایه نرم افزارهای سازمانی است؛ لایه ای که مرزهای ثابت و مشخصی ندارد.

چهار پرسش اساسی برای ارزیابی امنیت هر عامل هوش مصنوعی

هر عامل هوش مصنوعی از دو بخش تشکیل شده است: مدل که وظیفه استدلال را بر عهده دارد و مجموعه سازوکارهای پیرامونی که مدل را به یک عامل اجرایی تبدیل می کنند. این سازوکارها مشخص می کنند عامل به چه ابزارهایی متصل است، چه عملیاتی می تواند انجام دهد و در چه زمانی اقدام می کند.

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

۱. هویت

آیا عامل در جایی ثبت شده است؟ آیا می توان مشخص کرد مسئول انسانی آن چه کسی است؟ اگر از سازمان پرسیده شود این عامل متعلق به چه کسی است، آیا فرد مشخصی مسئولیت آن را می پذیرد یا عامل بدون هویت مستقل، با هویت سازنده خود فعالیت می کند؟

۲. مجوزها

عامل اجازه انجام چه کارهایی را دارد و آیا این دسترسی ها بیش از نیاز واقعی آن هستند؟ عامل هنگام ایجاد، چه نقش ها و محدوده های دسترسی OAuth را از حساب سازنده خود به ارث برده است؟ آیا کسی آگاهانه این مجوزها را بررسی و تایید کرده است؟

۳. اتصال پذیری

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

۴. فعالیت

عامل در عمل چه کارهایی انجام می دهد و آیا این رفتارها با وظیفه مورد انتظار آن سازگارند؟ ارزیابی باید بر اساس رفتار واقعی عامل انجام شود، نه صرفا توضیحاتی که در دستور اولیه یا تنظیمات آن نوشته شده است.

حوزه اتصال پذیری، تفاوت مهم امنیت عامل های هوش مصنوعی با بسیاری از راهکارهای موجود را آشکار می کند. پرسش نامه های امنیتی فروشندگان، فیلترهای دستورها و ابزارهای بررسی مدل معمولا هر عامل را به صورت جداگانه ارزیابی می کنند؛ در حالی که دامنه دسترسی عامل به محیطی بستگی دارد که در آن فعالیت می کند.

شرکت های بزرگ نیز رویکرد خود را تغییر می دهند

پاتریک اوپه، مدیر ارشد امنیت اطلاعات جهانی JPMorgan Chase، در سال ۲۰۲۵ به صنعت نرم افزار هشدار داد که زنجیره تامین شرکت های ثالث به یک خطر سیستمی تبدیل شده است. او به حوادثی اشاره کرد که بانک را وادار کرده بود ارتباط خود را با برخی تامین کنندگان آسیب دیده محدود کند.

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

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

نهادهای قانون گذار نیز با همین فرض پیش می روند. الزامات قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) که اجرای آنها در طول سال ۲۰۲۶ مرحله به مرحله دنبال می شود، بر این اساس استوارند که سازمان بتواند سامانه های هوش مصنوعی خود را فهرست کند، مالک و مسئول هر سامانه را مشخص سازد و شواهدی از نظارت بر آن ارائه دهد. سازمانی که حتی نمی تواند عامل های فعال خود را شناسایی و شمارش کند، برای رعایت این الزامات با مشکل مواجه خواهد شد.

چرا بررسی های دوره ای دیگر کافی نیستند؟

مدیریت ۵۰ عامل هوش مصنوعی با استفاده از فایل های صفحه گسترده و بررسی های فصلی شاید امکان پذیر باشد؛ اما همین روش در مقیاس ۵۰۰ عامل کارایی خود را از دست می دهد. با توجه به سرعت اضافه شدن قابلیت های جدید به محصولات سازمانی، تعداد ۵۰۰ عامل نیز ممکن است تنها با یک به روزرسانی نرم افزاری به ۵۰۰۰ عامل تبدیل شود.

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

برخی پلتفرم های امنیتی با همین رویکرد توسعه یافته اند. یکی از نمونه هایی که در مقاله معرفی شده، پلتفرم Reco و قابلیت Reco Graph آن است. این راهکار، هویت های انسانی و غیرانسانی، برنامه ها، مجوزها و فعالیت عامل ها را در یک نمای زنده به هم متصل می کند تا سازمان بتواند به جای تمرکز صرف بر تنظیمات، دامنه واقعی دسترسی ها و ارتباطات را بررسی کند.

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