پارادوکس امنیت هوش مصنوعی؛ چگونه هوش مصنوعی سایه به بزرگ‌ترین نقطه کور سازمان‌ها تبدیل شد
پذیرش هوش مصنوعی در سازمان‌ها دیگر منتظر آن نمانده است که سازوکارهای حاکمیتی خود را با آن هماهنگ کنند. کارکنان همین حالا از هوش مصنوعی مولد برای نوشتن کد، خلاصه‌سازی اسناد، تحلیل داده‌ها، تهیه پیش‌نویس ارتباطات و خودکارسازی کارهای روزمره استفاده می‌کنند؛ اغلب از طریق ابزارها و حساب‌هایی که تیم‌های امنیتی دید کاملی نسبت به آن‌ها ندارند. چیزی که ابتدا یک نگرانی مدیریتی و حاکمیتی بود، اکنون به یک مسئله قابل اندازه‌گیری امنیتی تبدیل شده است؛ مسئله‌ای که پیامدهای آن در هزینه‌های رخنه، رویدادهای از دست رفتن داده و شکاف میان هوش مصنوعی تأییدشده و شیوه واقعی کار افراد دیده می‌شود.
سازمان‌هایی که سطح بالایی از استفاده از هوش مصنوعی سایه دارند، به‌طور میانگین با هزینه‌های رخنه امنیتی حدود ۶۷۰ هزار دلار بیشتر از سازمان‌هایی با استفاده کم یا بدون استفاده از هوش مصنوعی سایه مواجه شدند. یک مورد از هر پنج سازمان بررسی‌شده اعلام کرده است که رخنه‌ای مرتبط با هوش مصنوعی سایه داشته است. در میان سازمان‌هایی که یک حادثه امنیتی مرتبط با هوش مصنوعی را تجربه کرده‌اند، ۹۷ درصد فاقد کنترل‌های مناسب دسترسی به هوش مصنوعی بودند. هم‌زمان، ۶۳ درصد از سازمان‌های آسیب‌دیده یا هیچ سیاست حاکمیتی برای هوش مصنوعی نداشتند یا هنوز در حال تدوین آن بودند؛ در حالی که تنها ۳۴ درصد از سازمان‌هایی که چنین سیاست‌هایی داشتند، به‌طور منظم استفاده از هوش مصنوعی غیرمجاز را بررسی می‌کردند.
در همین حال، میزان استفاده بسیار سریع‌تر از حاکمیت سازمانی در حال رشد است. گزارش ابر و تهدید ۲۰۲۶ شرکت نت‌اسکوپ نشان داد تعداد افرادی که در یک سازمان متوسط از برنامه‌های هوش مصنوعی مولد مبتنی بر نرم‌افزار به‌عنوان خدمت (SaaS) استفاده می‌کنند، طی یک سال سه برابر شده است، در حالی که حجم درخواست‌های ورودی به این ابزارها شش برابر افزایش یافته است. نزدیک به نیمی از کاربران هوش مصنوعی مولد (۴۷ درصد) همچنان از برنامه‌های شخصی هوش مصنوعی استفاده می‌کنند و سازمان متوسط هر ماه ۲۲۳ مورد نقض سیاست داده مرتبط با هوش مصنوعی ثبت کرده است.
تیم‌های امنیتی نیز درگیر همین الگو هستند. نظرسنجی شرکت مایندگارد از بیش از ۵۰۰ متخصص امنیت سایبری نشان داد ۲۴ درصد آن‌ها استفاده غیررسمی از هوش مصنوعی، مانند حساب‌های شخصی ChatGPT یا افزونه‌های تأییدنشده مرورگر، را گزارش کرده‌اند؛ در حالی که تنها ۳۲ درصد گفته‌اند سازمانشان به‌طور فعال استفاده از هوش مصنوعی را زیر نظر دارد. پژوهش مؤسسه SANS که در ژوئیه ۲۰۲۶ منتشر شد، نشان می‌دهد فشارها با سرعت زیادی در حال افزایش است: استفاده از هوش مصنوعی در امنیت سایبری طی یک سال از ۵۰ به ۷۸ درصد رسیده، اما بیش از نیمی از پاسخ‌دهندگان گفته‌اند چارچوب رسمی ممیزی برای پشتیبانی از مسئولیت‌های حاکمیتی هوش مصنوعی وجود ندارد.
حل مشکل هوش مصنوعی سایه دشوار است، زیرا در بیشتر سازمان‌ها این مسئله صرفاً نتیجه بی‌توجهی کارکنان به سیاست‌ها نیست. افراد به دلیل افزایش سرعت کار خود به سراغ هوش مصنوعی می‌روند. زمانی که ابزارهای تأییدشده، قوانین روشن درباره مدیریت داده، کنترل‌های هویتی و نظارت با همین سرعت فراهم نشوند، کاربران خودشان این خلأ را پر می‌کنند.
مشکل همچنین فراتر از استفاده پنهان رفته است. پژوهش رخنه‌های سال ۲۰۲۶ نشان داد یک‌چهارم رخنه‌های مخرب با کمک هوش مصنوعی انجام شده‌اند؛ رقمی که نسبت به سال قبل ۵۶ درصد افزایش یافته و هزینه این رخنه‌ها به‌طور میانگین حدود ۶ میلیون دلار بوده است؛ یعنی نزدیک به یک میلیون دلار بیشتر از میانگین جهانی هزینه رخنه. بیش از یک‌پنجم سازمان‌ها نیز اعلام کردند رخنه‌ای داشته‌اند که یک مدل یا برنامه هوش مصنوعی را هدف قرار داده است؛ ۹۲ درصد از این سازمان‌ها کنترل‌های مناسب دسترسی به هوش مصنوعی نداشتند.
بنابراین پرسش امنیتی دیگر این نیست که آیا سازمان‌ها از هوش مصنوعی استفاده خواهند کرد یا نه؛ آن‌ها همین حالا استفاده می‌کنند. پرسش واقعی این است که آیا این استفاده با حرکت هوش مصنوعی از یک ابزار مشورتی به سامانه‌ای که می‌تواند از طرف افراد اقدام کند، همچنان قابل مشاهده، محدود و پاسخ‌گو باقی می‌ماند یا خیر.
وقتی هوش مصنوعی فراتر از جعبه ورود درخواست حرکت می‌کند
هوش مصنوعی سایه بخش قابل مشاهده مشکل است. تغییر بزرگ‌تر زمانی آغاز می‌شود که سامانه‌های هوش مصنوعی به داده‌های سازمانی متصل شوند و توانایی استفاده از ابزارها را پیدا کنند.
کنترل‌های سنتی امنیت سایبری همچنان اهمیت دارند. مدیریت هویت، حداقل سطح دسترسی، توسعه امن، طبقه‌بندی داده، نظارت و پاسخ به رخداد همچنان پایه‌های اصلی هستند. تحلیل سال ۲۰۲۶ مؤسسه NIST درباره امنیت عامل‌های هوش مصنوعی نیز به همین نتیجه رسیده است: اصول آشنای امنیتی همچنان کاربرد دارند، اما باید برای سامانه‌هایی تطبیق داده شوند که خروجی مدل‌ها می‌تواند مستقیماً بر اقدامات نرم‌افزاری اثر بگذارد.
این موضوع مرز اعتماد را تغییر می‌دهد. یک برنامه معمولی ورودی دریافت می‌کند و منطقی را اجرا می‌کند که توسعه‌دهندگان آن را تعریف کرده‌اند. اما یک عامل هوش مصنوعی دستورهای زبان طبیعی را تفسیر می‌کند، محتوای ایمیل‌ها، اسناد، وب‌سایت‌ها، مخازن و دیگر سامانه‌ها را مصرف می‌کند و ممکن است تصمیم بگیرد در مرحله بعد از کدام ابزار استفاده کند. اگر عامل بتواند اطلاعات حساس را بازیابی کند یا سامانه‌های خارجی را تغییر دهد، تفاوت میان داده و دستور به مسئله‌ای حیاتی امنیتی تبدیل می‌شود.
این هسته اصلی مشکل تزریق درخواست است. یک دستور مخرب که درون یک سند، صفحه وب، تیکت یا ایمیل پنهان شده باشد، ممکن است توسط مدل به‌عنوان بخشی از همان زمینه‌ای پردازش شود که برای اجرای دستورهای قانونی استفاده می‌کند. OWASP همچنان تزریق درخواست را یکی از مهم‌ترین خطرهای امنیتی مدل‌های زبانی بزرگ می‌داند و راهنمایی‌های ۲۰۲۶ این سازمان تمرکز را به کل سامانه‌های عامل‌محور گسترش داده است؛ از جمله ربایش هدف، سوءاستفاده از ابزار، سوءاستفاده از هویت و سطح دسترسی، مسموم‌سازی حافظه و زمینه و رفتار ناامن میان عامل‌ها.
بنابراین سؤال عملی فقط این نیست که «آیا می‌توان مدل را فریب داد؟» مدل‌ها همچنان با ورودی‌های خصمانه و مبهم مواجه خواهند شد. سؤال مهم‌تر این است که «اگر مدل فریب خورد، سامانه چه کاری می‌تواند انجام دهد؟»
یک چت‌بات که پاسخ نادرست تولید می‌کند، یک نوع مشکل ایجاد می‌کند. اما عاملی که به ایمیل، فضای ذخیره‌سازی ابری، کد منبع، APIهای داخلی، اعتبارنامه‌ها یا سامانه‌های تولیدی دسترسی دارد، مسئله‌ای کاملاً متفاوت ایجاد می‌کند. NIST به‌طور فزاینده بر همین موضوع تمرکز کرده است؛ از جمله اینکه عامل‌ها چگونه باید شناسایی، احراز هویت، مجازسازی، به یک فرد مسئول مرتبط و هنگام اقدام ممیزی شوند. راهنمای اوت ۲۰۲۶ این مؤسسه بیان می‌کند که استقرار عامل‌های هوش مصنوعی همان الگوی آشنای امنیتی را تکرار می‌کند: ارزش فوری محصول پیش از ایجاد زیرساخت هویتی لازم برای کنترل آن.
روش مفیدی برای درک این ریسک، بررسی هم‌زمان سه قابلیت است: توانایی پردازش محتوای غیرقابل اعتماد، دسترسی به داده‌ها یا سامانه‌های حساس و امکان تغییر وضعیت یا ارتباط خارجی. هیچ‌کدام از این قابلیت‌ها ذاتاً ناامن نیستند؛ اما ترکیب آن‌ها بدون مرزهای قوی می‌تواند مسیری از یک ورودی مخرب تا یک اقدام مهم و اثرگذار ایجاد کند.
نمونه قابل توجهی از اهمیت سامانه پیرامون مدل، نه فقط خود مدل، در مورد Moltbook دیده شد. در فوریه ۲۰۲۶، پژوهشگران Wiz دریافتند شبکه اجتماعی پرطرفدار برای عامل‌های هوش مصنوعی دارای یک پیکربندی نادرست در بخش پشتیبان Supabase بوده است. نبود امنیت سطح ردیف (Row Level Security) باعث شد دسترسی خواندن و نوشتن بدون احراز هویت به داده‌های تولیدی فراهم شود و حدود ۱.۵ میلیون توکن احراز هویت عامل‌ها، ۳۵ هزار نشانی ایمیل، پیام‌های خصوصی و رکوردهای دیگر در معرض خطر قرار گیرد.
نتیجه این رخداد تنها افشای داده نبود. این اعتبارنامه‌ها می‌توانستند برای جعل هویت عامل‌ها استفاده شوند، اطلاعات خصوصی در دسترس قرار گیرد و محتوای زنده تغییر کند. Wiz اعلام کرد مشکل را گزارش کرده و Moltbook ظرف چند ساعت آن را برطرف کرده است. کلید عمومی Supabase که در رابط کاربری قابل مشاهده بود، خود آسیب‌پذیری نبود؛ چنین کلیدهایی برای قرار گرفتن در برنامه‌های سمت کاربر طراحی شده‌اند. شکست واقعی، نبود سیاست مجوزدهی پایگاه داده در پشت آن بود. همین جزئیات، حادثه را آموزنده‌تر می‌کند. Moltbook قربانی یک سوءاستفاده پیچیده جدید از هوش مصنوعی نشد؛ بلکه به دلیل یک خطای معمول کنترل دسترسی در برنامه‌ای که با سرعتی فوق‌العاده ساخته شده بود، آسیب‌پذیر شد. سازنده این پلتفرم گفته بود بخش زیادی از آن با کمک هوش مصنوعی و روش «کدنویسی شهودی» ساخته شده است. هوش مصنوعی مسیر تبدیل ایده به محصول را سریع‌تر کرد، اما معماری امن، کنترل دسترسی یا آزمایش مناسب را تضمین نکرد.
این یکی از تنش‌های اصلی امنیت هوش مصنوعی است: هوش مصنوعی می‌تواند زمان لازم برای ساخت نرم‌افزار و خودکارسازی کارها را کاهش دهد، اما هم‌زمان زمان موجود برای شناسایی تصمیم‌های ناامن پیش از رسیدن به محیط تولید را نیز کمتر می‌کند. توسعه سریع ارزشمند است، اما توسعه سریع و ناامن فقط بدهی امنیتی را سریع‌تر ایجاد می‌کند.
پذیرش امن هوش مصنوعی چگونه است؟
راه‌حل این نیست که هر ابزار هوش مصنوعی را به یک اندازه خطرناک بدانیم یا با ممنوعیت کامل پاسخ دهیم. چنین رویکردی معمولاً کارکنان را بیشتر به سمت استفاده پنهانی سوق می‌دهد و بهره‌وری عملیاتی را به‌شدت کاهش می‌دهد. یک برنامه امنیتی عملی باید با پذیرش این واقعیت آغاز شود که کارکنان و واحدهای کسب‌وکار همین حالا از هوش مصنوعی استفاده می‌کنند؛ سپس باید آن‌قدر دید و کنترل ایجاد شود که استفاده معمولی برای بهره‌وری از فعالیت واقعاً پرخطر جدا شود.
نخستین گام، ایجاد دیدپذیری است. تیم‌های امنیتی به فهرستی نیاز دارند که شامل خدمات رسمی هوش مصنوعی، حساب‌های شخصی مورد استفاده، افزونه‌های مرورگر، قابلیت‌های هوش مصنوعی تعبیه‌شده در محصولات SaaS، مدل‌های داخلی، عامل‌ها، درگاه‌های مدل و یکپارچه‌سازی‌هایی مانند سرورهای MCP باشد. داده‌های شبکه، DNS، پراکسی، نقاط پایانی، هویت و DLP می‌تواند بخش زیادی از این فعالیت‌ها را آشکار کند، اما کشف فنی باید با گفت‌وگو با کاربران و تیم‌های کسب‌وکار همراه شود. هدف، نظارت صرف نیست؛ هدف درک نیاز واقعی افراد و فراهم کردن مسیرهای امن‌تر برای استفاده‌های مشروع است.
پس از آن، کنترل‌ها باید بر اساس ریسک تعیین شوند، نه نام برندها. یک چت‌بات که درباره اسناد عمومی پاسخ می‌دهد، نباید همان رفتاری را دریافت کند که عاملی با امکان خواندن سوابق مشتریان و اجرای تراکنش‌ها دارد. طبقه‌بندی ریسک باید حساسیت داده‌ها، میزان اعتمادپذیری ورودی‌ها، ابزارها و سامانه‌هایی که هوش مصنوعی به آن‌ها دسترسی دارد، امکان نوشتن یا ارتباط خارجی، مدت نگهداری وضعیت و میزان برگشت‌پذیری اقدامات را در نظر بگیرد.
با عامل‌محور شدن سامانه‌ها، هویت اهمیت ویژه‌ای پیدا می‌کند. هر عامل باید هویت مشخص، اختیار محدود، مالک انسانی یا خدماتی قابل شناسایی و اعتبارنامه‌هایی قابل چرخش یا لغو داشته باشد. دسترسی گسترده و دائمی زمانی که عامل فقط برای یک وظیفه مشخص به چند مجوز محدود نیاز دارد، قابل توجیه نیست. کارهای NIST در حوزه هویت بر ضرورت اعمال احراز هویت، مجوزدهی، واگذاری اختیار، حداقل دسترسی، قابلیت ممیزی و عدم انکارپذیری برای عامل‌های نرم‌افزاری تأکید دارد.
حفاظت از داده نیز باید به خود تعامل با هوش مصنوعی نزدیک‌تر شود. سازمان‌ها باید بدانند نه فقط کاربران به کدام سرویس هوش مصنوعی مراجعه می‌کنند، بلکه چه اطلاعاتی به آن وارد و از آن خارج می‌شود. کد منبع حساس، داده مشتری، اعتبارنامه‌ها، اطلاعات تحت مقررات و مالکیت فکری باید تا حد امکان در لایه‌های مرورگر، API، نقطه پایانی و برنامه مدیریت شوند. داده‌های نت‌اسکوپ دلیل اهمیت این موضوع را نشان می‌دهد: نقض سیاست‌های داده مرتبط با هوش مصنوعی دو برابر شده، در حالی که استفاده سریع‌تر رشد کرده و نیمی از سازمان‌های بررسی‌شده هنوز سیاست‌های قابل اجرا برای حفاظت از داده در برنامه‌های هوش مصنوعی مولد ندارند.
برای سامانه‌های هوش مصنوعی توسعه‌یافته در داخل سازمان، چرخه توسعه امن نیز باید به‌روزرسانی شود. اسناد بازیابی‌شده، خروجی ابزارها، پاسخ‌های مدل و محتوای خارجی همگی باید بالقوه غیرقابل اعتماد در نظر گرفته شوند. خروجی مدل نباید بدون اعتبارسنجی و بررسی سیاست‌ها مستقیماً به اجرای کد، پرس‌وجوی SQL، فرمان‌های شل، ارتباطات خارجی یا اقدامات حیاتی کسب‌وکار منتقل شود. همین اصل درباره کد تولیدشده توسط هوش مصنوعی نیز صدق می‌کند: سرعت توسعه نیاز به بازبینی معماری، مدیریت اسرار، کنترل وابستگی‌ها، آزمایش و حداقل دسترسی را از بین نمی‌برد.
پاسخ به رخداد نیز باید تغییر کند. بررسی یک حادثه ممکن است نیازمند پاسخ به پرسش‌هایی باشد که در دستورالعمل‌های سنتی وجود ندارند: کدام درخواست یا محتوای خارجی بر عامل اثر گذاشت؟ چه ابزارهایی را فراخوانی کرد؟ از کدام اعتبارنامه‌ها استفاده کرد؟ چه داده‌ای بازیابی شد؟ چه وضعیتی تغییر کرد؟ خروجی آن به کدام عامل‌ها یا سامانه‌های دیگر رسید؟ سازمان‌ها به گزارش‌هایی نیاز دارند که پاسخ به این پرسش‌ها را ممکن کند و باید بتوانند در صورت رفتار مشکوک، سریع اعتبارنامه‌های عامل یا قابلیت‌های آن را لغو کنند.
حاکمیت، ساختار سازمانی پیرامون این کنترل‌های فنی را فراهم می‌کند. چارچوب مدیریت ریسک هوش مصنوعی NIST همچنان پایه‌ای مفید است و ISO/IEC 42001 رویکردی مبتنی بر سیستم مدیریت قابل صدور گواهی برای اداره هوش مصنوعی در سازمان ارائه می‌دهد. راهنمای جدید OWASP درباره مدل‌های زبانی بزرگ و سامانه‌های عامل‌محور، از جمله استاندارد کنترل عامل که در سپتامبر ۲۰۲۶ منتشر شد، نشان می‌دهد تمرکز از ایمن‌سازی درخواست‌ها و مدل‌های منفرد به مدیریت هویت، ابزارها، مجوزها، حافظه و اقدامات سامانه‌های هوش مصنوعی تغییر کرده است.
مقررات نیز در همین مسیر در حال حرکت هستند، هرچند زمان‌بندی‌ها همچنان تغییر می‌کنند. در اتحادیه اروپا، بیشتر مقررات قانون هوش مصنوعی از اوت ۲۰۲۶ اجرایی شدند، در حالی که الزامات سامانه‌های پرخطر مستقل بعداً به ۲ دسامبر ۲۰۲۷ و هوش مصنوعی پرخطر تعبیه‌شده در محصولات تحت مقررات به ۲ اوت ۲۰۲۸ منتقل شد. ایالت کلرادو نیز اجرای قانون هوش مصنوعی خود را به ۱ اوت ۲۰۲۷ منتقل کرد. درس مهم برای مدیران امنیت این نیست که برنامه خود را حول یک مهلت قانونی بسازند؛ بلکه قابلیت حاکمیتی باید پیش از الزام بعدی، پرسش مشتری یا رخداد امنیتی وجود داشته باشد.
مهم‌تر از همه، حاکمیت خوب باید استفاده از هوش مصنوعی تأییدشده را آسان‌تر کند، نه دشوارتر. اگر کارکنان حساب‌های امن سازمانی، قوانین روشن درباره داده‌های قابل اشتراک، ابزارهای مفید و رسمی و مسیر سریع برای ارزیابی کاربردهای جدید داشته باشند، انگیزه کمتری برای دور زدن امنیت خواهند داشت. حاکمیت باید توانمندساز باشد، نه مانع.
پارادوکس
این بحث دوباره به پارادوکس اصلی هوش مصنوعی سازمانی بازمی‌گردد.
هوش مصنوعی هم‌زمان که سطح حمله را گسترش می‌دهد، به یکی از ارزشمندترین ابزارهای موجود برای مدافعان امنیتی تبدیل شده است. پژوهش IBM در سال ۲۰۲۶ نشان داد رخنه‌های مخرب مبتنی بر هوش مصنوعی هزینه بیشتری از میانگین جهانی دارند، اما سازمان‌هایی که استفاده گسترده‌ای از هوش مصنوعی و خودکارسازی در امنیت دارند، حدود ۱.۹۳ میلیون دلار هزینه رخنه کمتری نسبت به سازمان‌های بدون این قابلیت‌ها متحمل می‌شوند. SANS نیز نشان داد تیم‌های امنیتی به‌سرعت هوش مصنوعی را در آزمون نفوذ، بررسی، پاسخ و امنیت برنامه‌ها به کار می‌گیرند.
بنابراین رد کردن هوش مصنوعی راهبرد امنیتی واقع‌بینانه‌ای نیست. این کار بسیاری از دستاوردهای دفاعی سازمان‌ها را نیز از بین می‌برد. هدف بهتر، جدا کردن خودکارسازی مفید از اختیار کنترل‌نشده است.
این موضوع نیازمند آن است که مدیران امنیت، هوش مصنوعی را بخشی از مدل عملیاتی سازمان بدانند، نه فقط یک دسته دیگر از خدمات SaaS. هیئت‌مدیره و مدیران اجرایی باید دید و مالکیت ریسک هوش مصنوعی را داشته باشند. مدیران ارشد امنیت اطلاعات به قابلیت‌های کشف، هویت، حفاظت از داده و پاسخ به رخداد برای عامل‌ها نیاز دارند. تیم‌های فناوری اطلاعات باید خدمات رسمی و مناسبی ارائه کنند که بتوانند با ابزارهایی که کارکنان در غیر این صورت خودشان انتخاب می‌کنند رقابت کنند. تیم‌های حقوقی و انطباق نیز باید الزامات در حال تغییر را به قوانین عملی تبدیل کنند، بدون اینکه هر آزمایش را به فرایندی چندماهه تبدیل کنند.
سازمان‌هایی که این مسیر را به‌خوبی مدیریت می‌کنند، سریع‌ترین یا محدودکننده‌ترین سازمان‌ها نخواهند بود. آن‌ها سازمان‌هایی خواهند بود که استفاده از هوش مصنوعی را در جایی که ریسک قابل قبول است آسان، در جایی که اثرگذاری بالا دارد دشوار برای سوءاستفاده، و در همه جا قابل مشاهده می‌کنند.
پذیرش هوش مصنوعی اتفاق افتاده است. انتخاب واقعی این است که سازمان‌ها آن را آگاهانه مدیریت کنند یا اجازه دهند مرزهای پیرامون داده‌ها، هویت‌ها و سامانه‌هایشان با هر درخواست، یکپارچه‌سازی و عامل جدید به‌تدریج تغییر کند.