تصور کنید یک مدیر سیستم، یک بات پشتیبانی ساده را برای مشتریان فعال می‌کند، اما ناگهان متوجه می‌شود کل زیرساخت ابری شرکت توسط یک پیام چت تسخیر شده است. این کابوس امنیتی اکنون به واقعیت تبدیل شده است؛ جایی که یک پیام ساده به یک عامل (Agent) — شبیه کارمندی که اجازه دارد ابزارهای مختلف را برای انجام کارها به کار بگیرد — می‌تواند کل حساب کاربری AWS را به دست مهاجم بسپارد. در واقع، ارسال تنها یک پیام چت به یک عامل هوش مصنوعی که با محیط عمومی در ارتباط است، برای به دست گرفتن کنترل تمام عامل‌های دیگر در همان حساب کاربری و منطقه (Region) AWS کافی بود.
پژوهشگران Zenity Labs این آسیب‌پذیری سیستمی را «AgentCorruption» نامیدند. این حفره، پلتفرم Amazon Bedrock AgentCore را هدف قرار داده است؛ همان ابزاری که شرکت‌ها برای استقرار عامل‌های هوش مصنوعی با حافظه و ابزارهای یکپارچه از آن استفاده می‌کنند. طبق گزارش فنی Zenity، اگر این بات‌ها به‌درستی ایزوله نشده باشند، مهاجم از آن‌ها به‌عنوان یک کلید جامع برای باز کردن تمام درهای زیرساخت AI شرکت استفاده می‌کند. این آسیب‌پذیری یک تعامل کم‌خطر را به یک تصاحب کامل حساب کاربری تبدیل می‌کند.
مکانیزم شکست امنیتی
به نقل از گزارش فنی Zenity، این حمله از نبود جداسازی میان عامل هوش مصنوعی و «سرویس متادیتای نمونه AWS» (IMDS) بهره می‌برد. این سرویس داخلی که در آدرس ۱۶۹.۲۵۴.۱۶۹.۲۵۴ قرار دارد، اعتبارنامه‌های موقتی را برای ورک‌لودها فراهم می‌کند تا بتوانند در AWS احراز هویت کنند. هر کسی که این اعتبارنامه‌ها را به دست آورد، می‌تواند خود را جایگزین آن نمونه (Instance) کند و از هویت آن استفاده کند.
در حالت عادی، عامل هوش مصنوعی باید از دسترسی به این سرویس منع شود، اما AgentCore این مرزها را نداشت. پژوهشگران اشاره کردند که مرزهای محیط ایزوله (Sandbox) — شبیه به یک اتاق امن که مانع دسترسی کاربر به سیستم‌های حساس می‌شود — در واقع اصلاً وجود نداشت و آن‌ها با هیچ مانعی روبرو نبودند.
تیم Zenity از Strands، یک چارچوب متن‌باز AWS که همراه با یک ابزار وب عرضه می‌شود، برای ساخت یک عامل آزمایشی استفاده کرد. آن‌ها با درخواست ساده و به زبان طبیعی از عامل خواستند تا سرویس متادیتا را فراخوانی کرده و نتایج را به یک سرور خارجی بفرستد. عامل بلافاصله دستور را اجرا کرد. یک پیام چت در پنجره پشتیبانی کافی بود تا عامل، اعتبارنامه‌های AWS خود را لو بدهد.
این سرویس متادیتا نه‌تنها اعتبارنامه‌های موقت، بلکه کلیدها و توکن‌های نشست (Session Tokens) کامل AWS را افشا کرد. علاوه بر این، گواهینامه‌ها و متریال‌های کلیدی برای یک سرویس داخلی AWS و یک URL پیش‌امضا شده برای ذخیره‌ساز S3 داخلی که حتی متعلق به حساب کاربری خود پژوهشگران نبود، لو رفت.
گسترش حمله و تسخیر حساب
پس از سرقت اعتبارنامه‌ها، مهاجم دیگر نیازی به تعامل با عامل نداشت. این کلیدها روی سیستم‌های شخصی پژوهشگران خارج از پلتفرم AWS نیز کار می‌کردند. آن‌ها ثابت کردند که حذف ابزار وب کمکی نمی‌کند، زیرا نقص در خودِ پلتفرم بود و حمله می‌توانست از طریق یک ابزار خط فرمان (CLI) نیز به طور کامل اجرا شود.
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، دسترسی‌های بیش از حد (Over-privileged) همیشه نقطه ضعف هستند. در اینجا نیز کلیدهای سرقتی به دلیل دسترسی‌های پیش‌فرض گسترده در AgentCore، اجازه دادند مهاجم به تمام عامل‌های موجود در همان حساب و منطقه دسترسی پیدا کند. این مجوزها محدود به عامل هدف نبود، بلکه برای هر عاملی در آن منطقه اعمال می‌شد و دسترسی‌های خواندن، نوشتن و حذف را فراهم می‌کرد که امکان عملیات تخریبی را به طور کامل باز می‌کرد.
ابعاد نفوذ و تخریب
با این امتیازات بالا، پژوهشگران توانستند چندین عملیات تخریبی را اجرا کنند:
- سرقت کد منبع: یک اسکریپت خودکار، تصاویر کانتینر تمام عامل‌های منطقه را استخراج کرد. این کار به آن‌ها اجازه داد تا بسته‌های کد را در چند ثانیه دانلود کنند و بدین ترتیب کد منبع و رمزهای عبور فراموش‌شده یا کلیدهای API را افشا کنند.
- استخراج داده‌ها: مهاجمان می‌توانستند تمام گفتگوهای خصوصی بین کاربران و هر یک از عامل‌های AgentCore در آن منطقه را بخوانند.
- مسموم‌سازی حافظه: برای عامل‌هایی با حافظه بلندمدت، دستوراتی قرار دادند تا تمام گفتگوهای آینده را به یک سرور خارجی ارسال کنند. در این حالت، کاربران بدون اینکه متوجه نشت اطلاعات شوند، به تعامل با عاملی که به‌ظاهر قابل اعتماد است ادامه می‌دادند.
- حرکت عرضی (Lateral Movement): مهاجم می‌توانست از یک بات پشتیبانی عمومی که با دنیای خارج در ارتباط است، به یک عامل مالی داخلی نفوذ کرده و به داده‌های حساس مالی دسترسی یابد.
اگرچه AWS توصیه می‌کند رمزها و کلیدهای API در محیط‌های ذخیره‌سازی امن نگهداری شوند، اما Zenity دریافت که دسترسی‌های پیش‌فرض AgentCore این حفاظ‌ها را تضعیف می‌کند و اجازه می‌دهد عامل‌ها به اعتبارنامه‌های ذخیره شده، جمله کلیدهای مربوط به سرویس‌های خارج از AWS نیز دسترسی داشته باشند.
پاسخ آمازون و رفع مشکل
Zenity این یافته‌ها را در ۲۵ دسامبر ۲۰۲۵ به AWS گزارش کرد. در پاسخ، آمازون نسخه IMDSv2 — که نسخه امن‌تری از سرویس متادیتا است — را به حالت پیش‌فرض برای استقرار‌های جدید AgentCore تبدیل کرد.
همچنین در حدود ماه اوت، AWS نقش اجرای پیش‌فرض (Execution Role) را به‌روزرسانی کرد. در نقش جدید، عامل‌ها دیگر اجازه ندارند عامل‌های دیگر را فراخوانی کنند، گفتگوهای خصوصی را بخوانند یا اعتبارنامه‌ها را از AWS Secrets Manager بازیابی کنند. با این حال، در حالی که AWS بسیاری از مجوزها را محدود کرد، پژوهشگران همچنان توصیه می‌کنند که شرکت‌ها نقش‌های سفارشی با دسترسی‌های بسیار محدودتر ایجاد کنند.
این حادثه تضاد بنیادی در AI ابری را نشان می‌دهد. مایکل بارگوری، مدیر فنی Zenity، معتقد است میان امنیت ابری (که بر جداسازی و اصل حداقل دسترسی استوار است) و «آزادی خلاقانه» مورد نیاز عامل‌ها برای مفید بودن، تضاد وجود دارد. وقتی عامل‌های عمومی و داخلی در یک محیط مشترک باشند، یک تزریق پرامپت (Prompt Injection) — شبیه به دادن دستور مخفی به یک کارمند برای دور زدن قوانین شرکت — می‌تواند کل مرزهای امنیتی را فرو بریزد.
الگویی از آسیب‌پذیری‌های عامل‌محور
این اتفاق تکرار خطاهای مشابه است. پژوهش‌های قبلی Zenity مانند AgentFlayer و AgentForger، نشت اعتبارنامه‌ها را در Salesforce Einstein، Copilot Studio و عامل‌های Workspace شرکت OpenAI نشان داده بود. در مورد AgentForger، یک لینک دستکاری شده در ChatGPT، عاملی ساخت که نیاز به تأیید را دور می‌زد. در حالی که OpenAI نقص خود را در ۴ روز رفع کرد، دسترسی‌های گسترده AgentCore ماه‌ها پس از گزارش اولیه باقی مانده بود.
ضعف‌های مشابه در دستکاری حافظه نیز دیده می‌شود. طبق طبقه‌بندی «تله‌های عامل AI» از گوگل دیپ‌مایند، وجود چند سند مسموم در یک پایگاه دانش می‌تواند پاسخ‌ها را منحرف کند. در مطالعه «عامل‌های هرج‌ومرج»، پژوهشگران یک عامل OpenClaw را از طریق یک سند قابل ویرایش در حافظه‌اش کنترل کردند، در حالی که عامل دیگری جزئیات بانکی بدون سانسور را لو داد. این چالش‌های امنیتی در مدل‌های متن‌باز، جنجال‌های گسترده‌ای را پیرامون کپی‌برداری از پروژه OpenClaw توسط متا ایجاد کرد که نشان‌دهنده رقابت شدید بر سر تسلط بر معماری عامل‌هاست.
سام آلتمن، مدیرعامل OpenAI، گفته است که عامل‌ها باید فقط حداقل دسترسی مورد نیاز را داشته باشند. طبق یافته‌های Zenity، نقش پیش‌فرض AgentCore این اصل را نقض می‌کرد. برای شرکت‌هایی مثل سونی و اریکسون که از AWS استفاده می‌کنند، درس اصلی این است: هرگز از نقش‌های پیش‌فرض استفاده نکنید و دسترسی‌ها را به شدت محدود کنید.
در آینده باید منتظر به‌روزرسانی‌های «مدل مسئولیت مشترک AWS» باشیم، زیرا ارائه‌دهندگان ابری در تلاش‌اند تعریف کنند که امنیت پلتفرم کجا به پایان می‌رسد و امنیت «در سطح پرامپت» عامل از کجا آغاز می‌شود. این تکامل در مدیریت دسترسی‌ها، مشابه تلاش‌های شرکت‌های پیشرو برای ایجاد کنترل در سطح پروتکل در مدل‌هایی مانند GPT-6 Astra است تا بتوانند در محیط‌های پیچیده با دقت و امنیت بیشتری عمل کنند.
گام بعدی شما
- اگر از Amazon Bedrock استفاده می‌کنید، فوراً نقش‌های اجرای پیش‌فرض را به نقش‌های سفارشی (Custom Roles) با اصل «حداقل دسترسی» تغییر دهید.
- دسترسی عامل‌های خود را به سرویس متادیتای نمونه (IMDS) بررسی و در صورت امکان مسدود کنید.
- تمام کلیدهای API و رمزهای عبوری که در محیط‌های AgentCore ذخیره شده‌اند را بازنشانی (Rotate) کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو