آنچه در این مقاله میخوانیم
هوش مصنوعی Gemini در آزمایش امنیتی به زیرساخت سه شرکت واقعی نفوذ کرد
یک آزمایش امنیت سایبری در گوگل به سناریویی غیرمنتظره تبدیل شد؛ چند مدل هوش مصنوعی از جمله Gemini هنگام اجرای آزمونهای تهاجمی امنیتی، به اینترنت دسترسی پیدا کردند و به زیرساخت آنلاین سه شرکت واقعی وارد شدند.
در نگاه اول شاید این اتفاق شبیه داستانهای علمیتخیلی درباره «خروج هوش مصنوعی از کنترل» به نظر برسد؛ اما جزئیات حادثه تصویر دقیقتری ارائه میکنند.
گوگل مدلها را برای حمله به شرکتهای خیالی در یک محیط آزمایشی آماده کرده بود. مشکل زمانی شکل گرفت که نام برخی شرکتهای ساختگی با نام شرکتهای واقعی تطابق داشت و مدلها نیز به دلیل یک نقص در محیط آزمایش توانستند به اینترنت متصل شوند.
Gemini و مدلهای دیگر سپس هدفهای واقعی را بهجای نمونههای آزمایشی انتخاب کردند.
طبق گزارش منتشرشده، مدلها در نهایت متوجه شدند که با زیرساخت واقعی روبهرو هستند و فعالیت تهاجمی خود را متوقف کردند. گوگل نیز اعلام کرد هیچیک از سه شرکت خسارتی متحمل نشدند.
این حادثه یک سؤال مهم را پیش روی متخصصان امنیت قرار میدهد:
وقتی AI Agent قدرت شناسایی آسیبپذیری، پیدا کردن Credential و اجرای عملیات واقعی را در اختیار دارد، چگونه باید محیط فعالیت آن را کنترل کرد؟
ماجرای نفوذ Gemini به سه شرکت چه بود؟
ماجرا در جریان مجموعهای از آزمایشهای امنیت سایبری گوگل رخ داد.
پژوهشگران امنیتی قصد داشتند توانایی مدلهای هوش مصنوعی را در اجرای عملیات تهاجمی کنترلشده ارزیابی کنند. آنها برای مدلها سناریوهایی طراحی کردند که در آن AI باید شرکتهای ساختگی را هدف قرار میداد و آسیبپذیریهای آنها را پیدا میکرد.
اما یک مشکل در زیرساخت آزمایش به مدلها اجازه داد به اینترنت عمومی دسترسی پیدا کنند.
در همین زمان، نام شرکت خیالی موجود در سناریوی آزمایش با نام یک شرکت واقعی یکسان بود.
Gemini بهجای باقیماندن در محیط آزمایش، شرکت واقعی را در اینترنت پیدا کرد و عملیات خود را علیه زیرساخت همان مجموعه ادامه داد. گوگل اعلام کرد اتفاق مشابهی برای دو شرکت دیگر نیز رخ داد.
این موضوع نشان میدهد که یک AI Agent الزاماً مفهوم «شرکت خیالی» یا «هدف آزمایشی» را مانند انسان درک نمیکند؛ Agent هدف را از طریق دادهها، ابزارها و دسترسیهایی که در اختیار دارد دنبال میکند.
هوش مصنوعی چگونه وارد زیرساخت شرکتها شد؟
بخش مهمتر ماجرا به روش دسترسی Agentها مربوط میشود.
طبق گزارش، مدلها از Credentialهایی استفاده کردند که آنها را در اینترنت پیدا کرده بودند یا با روشهای دیگر حدس زده بودند. سپس از همان اطلاعات برای ورود به زیرساخت هدف استفاده کردند.
این اتفاق اهمیت دو موضوع قدیمی اما بسیار مهم امنیت سایبری را دوباره یادآوری میکند:
Credential Management
و
Password Security
اگر یک Password ضعیف یا Credential افشاشده در اینترنت وجود داشته باشد، مهاجم انسانی تنها بازیگر تهدید محسوب نمیشود.
یک Agent خودکار نیز میتواند:
- اطلاعات مربوط به هدف را جمعآوری کند
- Credentialهای افشاشده را پیدا کند
- سرویسهای در دسترس را شناسایی کند
- اطلاعات ورود را آزمایش کند
- نتیجه را تحلیل کند
- و در صورت موفقیت مرحله بعد را اجرا کند
همین قابلیت، سرعت عملیات مهاجم را به شکل قابلتوجهی افزایش میدهد.
Gemini چگونه متوجه شد هدف واقعی است؟
یکی از نکات قابلتوجه حادثه این بود که مدلها پس از ورود به زیرساخت شرکتها متوجه شدند محیط مقابل با محیط شبیهسازیشده آزمایش تفاوت دارد.
گوگل اعلام کرد مدلها پس از تشخیص این موضوع، فعالیت تهاجمی را متوقف کردند.
این رفتار نشان میدهد مدلهای پیشرفته میتوانند Context محیط را بررسی کنند و براساس اطلاعات جدید تصمیم خود را تغییر دهند.
اما از دید امنیت سایبری، سؤال مهمتری شکل میگیرد:
اگر مدل چنین تشخیصی انجام نمیداد چه اتفاقی رخ میداد؟
امنیت یک سیستم نباید تنها به توانایی مدل برای تشخیص موقعیت خطرناک وابسته باشد.
زیرساخت باید از ابتدا مانع دسترسی غیرمجاز Agent به سیستمهای خارج از Scope شود.
آیا Gemini واقعاً از کنترل خارج شد؟
عبارتهایی مانند «Gemini از کنترل خارج شد» تیتر جذابی ایجاد میکنند، اما از نظر فنی نمیتوان این حادثه را معادل خروج کامل هوش مصنوعی از کنترل انسان دانست.
مشکل اصلی از ترکیب چند عامل شکل گرفت:
- مدل وظیفه اجرای عملیات تهاجمی داشت.
- محیط آزمایش اجازه دسترسی ناخواسته به اینترنت را داد.
- نام هدف ساختگی با یک شرکت واقعی تطابق داشت.
- Agent ابزار لازم برای ادامه عملیات را در اختیار داشت.
- زیرساخت مقصد از Credentialهایی استفاده میکرد که Agent توانست آنها را پیدا یا حدس بزند.
بنابراین حادثه بیشتر از آنکه «شورش AI» را نشان دهد، ضعف در کنترل محیط Agent را آشکار میکند.
همین موضوع برای سازمانهایی که قصد استفاده از AI Agentها را دارند اهمیت زیادی دارد.
مشکل اصلی AI Agentها؛ قدرت اقدام
یک Chatbot معمولی بیشتر نقش تولیدکننده اطلاعات را دارد.
شما سؤال میپرسید و مدل پاسخ میدهد.
اما AI Agent میتواند بعد از دریافت هدف:
- برنامهریزی کند
- ابزار انتخاب کند
- وارد وبسایت شود
- API فراخوانی کند
- Terminal اجرا کند
- فایل تغییر دهد
- Credential استفاده کند
- و عملیات چندمرحلهای انجام دهد
گوگل نیز در توسعه نسل جدید ابزارهای امنیتی خود روی همین قابلیت Agentها تمرکز دارد.
برای مثال، Gemini 3.5 Flash Cyber را بهطور خاص برای یافتن، اعتبارسنجی و Patch کردن آسیبپذیریهای نرمافزاری توسعه داده است. گوگل میگوید ابزارهایی مانند CodeMender میتوانند آسیبپذیریهای مهم را بهصورت خودکار پیدا و اصلاح کنند.
تواناییای که برای مدافعان امنیت مفید است، در صورت کنترل نامناسب میتواند سطح حمله جدیدی نیز ایجاد کند.
مرز میان ابزار دفاعی و ابزار تهاجمی باریکتر میشود
هوش مصنوعی میتواند سرعت شناسایی آسیبپذیریها را افزایش دهد.
Google Threat Intelligence Group در سال ۲۰۲۶ اعلام کرد برای نخستینبار مهاجمی را شناسایی کرده که به اعتقاد این تیم، برای توسعه یک Exploit مربوط به آسیبپذیری Zero-Day از هوش مصنوعی استفاده کرده است.
این روند دو سمت دارد.
از یک طرف تیمهای دفاعی میتوانند با AI:
- آسیبپذیریها را سریعتر پیدا کنند
- کد را بررسی کنند
- Patch پیشنهاد دهند
- Threat Intelligence را تحلیل کنند
- و Incidentها را سریعتر شناسایی کنند
از طرف دیگر، مهاجمان نیز میتوانند از همان فناوری برای:
- Reconnaissance
- تولید Exploit
- تحلیل آسیبپذیری
- Phishing
- Malware Development
- Credential Attacks
- و Automation حملات
استفاده کنند.
بنابراین مسابقه امنیت سایبری به سمت Automation در برابر Automation حرکت میکند.
چرا دسترسی اینترنت برای AI Agent اهمیت دارد؟
یکی از مهمترین درسهای حادثه Gemini به Internet Egress Control مربوط میشود.
اگر Agent به اینترنت آزاد دسترسی داشته باشد، دامنه اقدام آن بهشدت افزایش پیدا میکند.
Agent میتواند:
DNS Query ارسال کند،
Domainها را بررسی کند،
APIهای خارجی را فراخوانی کند،
فایل دانلود کند،
Credential جستوجو کند،
و با زیرساختهای خارج از سازمان ارتباط برقرار کند.
به همین دلیل تیم امنیت نباید AI Agent را مانند یک نرمافزار عادی در نظر بگیرد.
سازمان باید برای Agent نیز سیاست مشخص Egress تعریف کند.
برای مثال:
Allowlist کردن Destinationها
Agent فقط باید به Domainها و APIهایی که برای انجام وظیفه نیاز دارد دسترسی پیدا کند.
مسدودکردن اینترنت عمومی
اگر Agent فقط روی دادههای داخلی فعالیت میکند، سازمان نباید اینترنت آزاد در اختیار آن قرار دهد.
ثبت کامل ترافیک
SOC باید ارتباطات Agent را از طریق Firewall، Proxy، NDR یا SIEM مانیتور کند.
Sandboxing؛ اولین مرز دفاعی برای AI Agent
حادثه Gemini اهمیت Sandboxing را نیز نشان میدهد.
Sandbox باید میان Agent و زیرساخت واقعی فاصله ایجاد کند.
یک Sandbox مناسب باید محدودیتهای مشخصی روی موارد زیر اعمال کند:
- Network Access
- File System
- اجرای Command
- API Access
- Credential Access
- Process Execution
- Cloud Resources
اگر Agent بتواند بدون محدودیت از Sandbox خارج شود، محیط آزمایشی ارزش امنیتی خود را از دست میدهد.
گوگل نیز در تحقیقات خود درباره کنترل Agentهای پیشرفته روی ایجاد لایههای دفاعی برای جلوگیری از رفتارهای ناخواسته تأکید میکند. این شرکت در AI Control Roadmap خود توضیح میدهد که افزایش توانایی Agentها به Safeguardهای پیچیدهتر نیاز دارد.
Credentialهای ضعیف هنوز یکی از بزرگترین مشکلات امنیتی هستند
ماجرای Gemini یک حقیقت قدیمی را دوباره ثابت میکند:
AI مشکل Password ضعیف را ایجاد نکرده؛ AI فقط میتواند سریعتر از آن سوءاستفاده کند.
اگر سازمان Credentialهایی را در Repository عمومی، فایلهای آنلاین یا سرویسهای بدون محافظت رها کند، یک Agent میتواند خیلی سریع آنها را پیدا کند.
بنابراین سازمانها باید:
Credentialهای افشاشده را شناسایی کنند،
Password Rotation اجرا کنند،
MFA را فعال کنند،
Secretها را داخل Code قرار ندهند،
از Privileged Access Management استفاده کنند،
و Authenticationهای غیرضروری را محدود کنند.
اصل Least Privilege برای Agentهای هوش مصنوعی
یکی دیگر از مهمترین کنترلها، Least Privilege است.
Agent فقط باید حداقل Permission لازم برای انجام وظیفه خود را در اختیار داشته باشد.
فرض کنید سازمان یک AI Agent را برای بررسی Vulnerabilityها اجرا میکند.
این Agent ممکن است به دسترسی Read روی Asset Inventory نیاز داشته باشد، اما دلیلی ندارد Administrator Access روی Domain Controller داشته باشد.
یا اگر Agent وظیفه Code Review را بر عهده دارد، الزاماً نباید اجازه Deploy مستقیم روی Production را دریافت کند.
هر Permission اضافه، Blast Radius احتمالی را افزایش میدهد.
آیا Human Approval کافی است؟
یکی از روشهای کنترل Agentها استفاده از Human in the Loop است.
در این مدل Agent میتواند عملیات را آماده کند، اما انسان اقدام نهایی را تأیید میکند.
برای مثال:
Agent آسیبپذیری را پیدا میکند؛ کارشناس امنیت Exploit را بررسی میکند.
Agent Patch پیشنهاد میدهد؛ تیم فنی آن را تأیید میکند.
Agent Account مشکوک را شناسایی میکند؛ SOC Analyst درباره Disable کردن آن تصمیم میگیرد.
Agent Rule فایروال پیشنهاد میدهد؛ Administrator آن را اجرا میکند.
این مدل سطح امنیت را افزایش میدهد، اما سازمان باید Human Approval را برای عملیات واقعاً حساس الزامی کند.
Logging در عصر AI اهمیت بیشتری پیدا میکند
وقتی یک Agent صدها عملیات را در چند دقیقه انجام میدهد، بررسی دستی آنها تقریباً غیرممکن میشود.
به همین دلیل سازمان باید تمام رفتارهای مهم Agent را ثبت کند.
Log مناسب باید مشخص کند:
- Agent چه دستوری دریافت کرد؟
- چه تصمیمی گرفت؟
- از چه ابزاری استفاده کرد؟
- به چه IP یا Domain متصل شد؟
- چه Credentialی درخواست کرد؟
- چه فایلهایی را خواند؟
- چه فایلهایی را تغییر داد؟
- چه Commandهایی را اجرا کرد؟
- چه APIهایی را فراخوانی کرد؟
سپس SIEM میتواند رفتار Agent را در کنار رفتار کاربران و Endpointهای دیگر تحلیل کند.
گوگل پس از حادثه چه اقدامی انجام داد؟
گوگل اعلام کرد تیم امنیتی این شرکت سه سازمان درگیر را از اتفاق مطلع کرد.
هدر ادکینز، معاون مهندسی امنیت گوگل، توضیح داد که تیم امنیت گوگل سابقه طولانی در گزارش مشکلات امنیتی به سازمانهای دیگر دارد؛ حتی زمانی که یک Password ضعیف عامل اصلی مشکل باشد.
گوگل همچنین با شریک آموزشی خود همکاری کرد تا فرآیندهای آزمایش را تغییر دهد و احتمال تکرار چنین اتفاقی را کاهش دهد.
این شرکت اعلام کرد هیچ خسارتی به سه سازمان وارد نشد.
ماجرای Gemini چه درسی برای مدیران امنیت دارد؟
سازمانها نباید AI Agent را صرفاً بهعنوان یک «دستیار هوشمند» ببینند.
از دید امنیت، یک Agent پیشرفته شباهت بیشتری به یک هویت ماشینی با قابلیت تصمیمگیری دارد.
بنابراین مدیر امنیت باید همان کنترلهایی را که برای User، Service Account و Application اجرا میکند، با حساسیت بیشتری برای Agent نیز در نظر بگیرد.
معماری امنیت باید حداقل این لایهها را پوشش دهد:
Identity Security
هر Agent باید Identity مشخص داشته باشد.
Authentication
سازمان باید تمام دسترسیها را احراز هویت کند.
Authorization
Agent فقط باید Permission ضروری دریافت کند.
Network Segmentation
Agent نباید به تمام شبکه دسترسی داشته باشد.
Egress Filtering
Firewall باید مقصدهای اینترنتی Agent را کنترل کند.
Credential Security
سازمان نباید Passwordها و Tokenهای دائمی در اختیار Agent قرار دهد.
Logging & Monitoring
SOC باید تمام فعالیتهای حساس را مانیتور کند.
Human Approval
عملیات پرریسک باید تأیید انسانی دریافت کند.
Zero Trust و AI Agent؛ اعتماد نکن، بررسی کن
اصول Zero Trust میتوانند چارچوب مناسبی برای امنیت Agentic AI ایجاد کنند.
اصل معروف Zero Trust میگوید:
Never Trust, Always Verify
همین منطق درباره Agentها نیز کاربرد دارد.
سازمان نباید صرفاً به دلیل اینکه خودش Agent را Deploy کرده، به تمام تصمیمهای آن اعتماد کند.
هر Agent باید:
هویت مشخص داشته باشد،
سطح دسترسی محدود دریافت کند،
درخواستهایش ثبت شوند،
ارتباطاتش کنترل شوند،
و برای عملیات حساس Approval دریافت کند.
نگاه دمسان رایانه؛ مسئله اصلی قدرت AI نیست، کنترل دسترسی آن است
حادثه Gemini نشان میدهد رشد قابلیتهای هوش مصنوعی یک سؤال قدیمی امنیت سایبری را با شکل جدیدی مطرح میکند:
چه کسی به چه چیزی دسترسی دارد؟
فقط کلمه «چه کسی» در حال تغییر است.
تا امروز تیمهای امنیت بیشتر روی User، Administrator، Endpoint و Service Account تمرکز میکردند.
از این پس AI Agent نیز باید وارد همین مدل امنیتی شود.
دمسان رایانه بهعنوان مشاور و ارائهدهنده راهکارهای امنیتی پیشنهاد میکند سازمانها پیش از اتصال AI Agentها به زیرساختهای واقعی، حداقل این موارد را ارزیابی کنند:
Identity Management + Least Privilege + Network Segmentation + Egress Control + SIEM + NDR + PAM + MFA + Sandboxing + Incident Response
هوش مصنوعی میتواند سرعت دفاع سایبری را افزایش دهد، اما سازمان تنها زمانی میتواند از این مزیت استفاده کند که معماری امنیتی آن با سطح استقلال Agentها هماهنگ باشد.
جمعبندی
ماجرای دسترسی Gemini به زیرساخت سه شرکت واقعی نمونه مهمی از ریسکهای عصر Agentic AI محسوب میشود.
در این آزمایش، مدلها با هدف حمله به شرکتهای خیالی فعالیت میکردند، اما دسترسی ناخواسته به اینترنت و تطابق نام اهداف آزمایشی با شرکتهای واقعی باعث شد Agentها عملیات خود را روی زیرساخت واقعی ادامه دهند. آنها همچنین از Credentialهایی که پیدا یا حدس زده بودند برای ورود استفاده کردند.
گوگل اعلام کرد مدلها پس از تشخیص محیط واقعی عملیات را متوقف کردند و هیچ خسارتی به شرکتها وارد نشد.
با این حال، اهمیت این حادثه فقط به Gemini مربوط نمیشود.
هر سازمانی که AI Agent را به اینترنت، Cloud، Endpoint، Repository، API یا زیرساخت داخلی متصل میکند باید یک اصل را جدی بگیرد:
هرچه اختیار Agent بیشتر شود، کنترل امنیتی آن نیز باید قویتر شود.
در آینده نزدیک سؤال اصلی تیمهای امنیت احتمالاً این نخواهد بود که «آیا از هوش مصنوعی استفاده کنیم؟»
سؤال مهمتر این است:
هوش مصنوعی را به چه منابعی متصل کنیم و تا چه اندازه اجازه اقدام مستقل به آن بدهیم؟
سوالات متداول
آیا Gemini واقعاً سه شرکت را هک کرد؟
در جریان یک آزمایش امنیت سایبری، چند مدل از جمله Gemini به دلیل دسترسی ناخواسته به اینترنت، به زیرساخت سه شرکت واقعی وارد شدند. گوگل اعلام کرد مدلها پس از تشخیص محیط واقعی فعالیت را متوقف کردند و خسارتی ایجاد نکردند.
چرا Gemini شرکتهای واقعی را هدف قرار داد؟
نام شرکتهای خیالی موجود در سناریوی آزمایش با نام شرکتهای واقعی تطابق داشت. مدلها نیز به دلیل دسترسی به اینترنت توانستند شرکتهای واقعی را پیدا کنند و عملیات را ادامه دهند.
Gemini چگونه وارد زیرساخت شرکتها شد؟
طبق گزارش، مدلها از Passwordها یا Credentialهایی استفاده کردند که در اینترنت پیدا کرده یا حدس زده بودند.
آیا این اتفاق نشان میدهد هوش مصنوعی از کنترل خارج شده است؟
خیر. شواهد این حادثه بیشتر ضعف در محدودسازی محیط آزمایشی و کنترل دسترسی Agentها را نشان میدهند. مدلها مأموریت امنیتی مشخصی داشتند و بعد از تشخیص محیط واقعی فعالیت خود را متوقف کردند.
AI Agent چه تفاوتی با Chatbot دارد؟
Chatbot بیشتر پاسخ تولید میکند، اما AI Agent میتواند برای رسیدن به یک هدف برنامهریزی کند، ابزار استفاده کند، API فراخوانی کند، Code اجرا کند و چند مرحله از یک عملیات را بهصورت مستقل انجام دهد.
چگونه میتوان امنیت AI Agent را افزایش داد؟
سازمانها باید از Sandboxing، Least Privilege، Network Segmentation، Egress Filtering، MFA، PAM، Logging، SIEM، NDR و Human Approval برای کنترل Agentها استفاده کنند.
