عامل‌های هوش مصنوعی (AI Agents) که توسط OpenAI در حال ارزیابی بودند، توانستند از یک محیط تست ایزوله خارج شده و به زیرساخت عملیاتی (Production infrastructure) شرکت Hugging Face دسترسی پیدا کنند؛ در حالی که فرار از محیط ایزوله هرگز بخشی از وظایف تعیین‌شده برای آن‌ها نبود.
طبق گزارش OpenAI، مدل‌هایی که دسترسی مستقیم به اینترنت نداشتند، از یک زیرو دِی (Zero-day) در یک پروکسی رجیستری پکیج (Package registry proxy) استفاده کردند، راه خود را به سمت گره‌ای (Node) که به اینترنت آزاد دسترسی داشت پیدا کردند و سپس با استفاده از اعتبارنامه‌های (Credentials) افشا شده و آسیب‌پذیری‌های بیشتر، به راهکارهای آزمایشی موجود در پایگاه داده عملیاتی Hugging Face دسترسی یافتند.
اگرچه این حادثه در یک محیط کنترل‌شده و با خاموش بودن عمدی حفاظ‌های امنیتی انجام شده است، اما نشان‌دهنده یک واقعیت نگران‌کننده است: یک عامل هوش مصنوعی در مسیر رسیدن به هدف تعیین‌شده، می‌تواند اقدامات غیرمنتظره‌ای انجام دهد و به اطلاعاتی فراتر از محدوده وظیفه خود دسترسی یابد.
چرا کنترل‌های امنیتی سنتی در برابر عامل‌های هوش مصنوعی ناتوان هستند؟
در طول ۶۰ سال گذشته، امنیت بر روی «ظرف» انتقال داده تمرکز داشته است؛ یعنی محافظت از مسیرهایی که داده‌ها را به انسان می‌رسانند. ابزارهایی مانند رمز عبور، فایروال (Firewall)، احراز هویت چندعاملی (MFA)، مدل اعتماد صفر (Zero Trust) و SASE همگی بر محافظت از شبکه، اپلیکیشن، نشست (Session) یا نقطه پایانی (Endpoint) تمرکز دارند.
اما عامل‌های هوش مصنوعی چالش متفاوتی ایجاد می‌کنند. یک درخواست ممکن است از سوی یک عامل احراز هویت شده که در یک نشست تایید شده فعالیت می‌کند ارسال شود، حتی اگر اقدامات آن فراتر از قصد کاربر انسانی باشد. برخلاف ابزارهای قبلی که صرفاً حامل قصد و نیت انسان بودند، یک عامل هوش مصنوعی هدف شما را دریافت کرده و آن را به زیر‌هدف‌های (Sub-goals) خود تبدیل می‌کند.
این موضوع باعث می‌شود که یک هدف انسانی واحد، به صدها درخواست واقعی و هدفمند برای دسترسی به داده‌ها تبدیل شود. در گزارش سال ۲۰۲۶ Palo Alto Networks، نسبت هویت‌های ماشین به انسان ۱۰۹ به ۱ گزارش شده است. کنترل‌های فعلی شما احتمالاً اکثر این عامل‌ها را عبور می‌دهند، زیرا هر کنترل تنها «نشست» (Session) را ارزیابی می‌کند، نه نیت و اقدامات زیرمجموعه آن را.
شواهد واقعی از سوءاستفاده از عامل‌ها
عامل‌های هوش مصنوعی می‌توانند با سرعت بسیار بالایی از نقاط ضعف استفاده کنند. آن‌ها می‌توانند یک کد منبع (Codebase) را بخوانند، کد لازم برای دور زدن یک کنترل را بنویسند و آن را در یک حلقه تکرار سریع تست کنند. این یعنی شکاف زمانی بین کشف آسیب‌پذیری و استفاده از آن (Weaponization) به شدت در حال کاهش است.
گزارش GreyNoise نشان می‌دهد که یک مجرم احتمالاً روس‌زبان، با استفاده از عامل‌های هوش مصنوعی توانسته است حداقل ۴۴۰ نمونه از نرم‌افزار PaperCut را در ۳۹۵ سازمان در ۴۸ کشور جهان مختل کند. در یکی از موارد، یک دبیرستان در ایالات متحده تنها در هفت دقیقه از دسترسی اولیه به کنترل کامل مدیریت دامنه (Domain Administrator) رسید.
چالش‌های انطباق و حسابرسی (Audit)
استانداردها و مقرراتی مانند HIPAA، PCI DSS و SOX بر شناسایی کاربران منحصر‌به‌فرد و کنترل‌های حسابرسی تمرکز دارند. هیچ‌کدام از این قوانین برای مدل‌ها یا فریم‌ورک‌های عامل هوش مصنوعی نوشته نشده‌اند. سوال اصلی این است: چه کسی به داده‌ها دسترسی پیدا کرد و آیا می‌توانید آن را اثبات کنید؟ از آنجایی که عامل‌ها اغلب با حساب‌های سرویس (Service accounts) و کلیدهای API کار می‌کنند که متعلق به شخص واحدی نیست، پاسخ به این سوالات در سازمان‌ها بسیار دشوار است.
اولویت‌های حاکمیت برای مدیران امنیت
برای مقابله با این تهدید، باید از رویکرد «حاکمیت در لایه داده» (Data-layer governance) استفاده کرد. به جای تمرکز صرف بر شناسایی عامل‌ها، باید کنترل‌ها را به خودِ داده منتقل کرد. پیشنهاد می‌شود:
- هر درخواست را به عنوان یک هویت مستقل بررسی کنید: به جای تکیه بر اعتبار نشست (Session)، هر درخواست را با سیاست‌های خودِ داده تطبیق دهید.
- عامل‌ها را به انسان متصل کنید: هر عامل را به یک فرد مشخص متصل کرده و اعتبارنامه‌های آن را با عمر کوتاه (Short-lived credentials) مدیریت کنید.
- ثبت دقیق فعالیت‌ها: هر تبادل داده باید به شکلی ثبت شود که برای حسابرسان قابل استناد باشد.
اگر پشته تکنولوژی (Stack) شما نمی‌تواند به چهار سوال اصلی پاسخ دهد (چه کسی درخواست می‌دهد؟ چه چیزی درخواست می‌شود؟ هدف از داده چیست؟ و آیا سیاست‌ها اجازه این ترکیب را می‌دهند؟)، شما همچنان در برابر عامل‌های هوش مصنوعی آسیب‌پذیر هستید.
