نشت داده‌های مالی در محیط‌های مشترک؛ نقطه ضعف زیرساختی عامل‌های هوش مصنوعی

تصور کنید یک دستیار مالی شخصی، تمام موجودی حساب‌های بانکی شما را بدون اجازه در کانال عمومی اسلک شرکت منتشر کند. این اتفاق برای شین مک، مدیرعامل XMTP Labs، رخ داد و ثابت کرد که امنیت عامل‌های هوش مصنوعی لزوماً در گروی دستورات متنی نیست، بلکه به جایی برمی‌گردد که این مدل‌ها اجرا می‌شوند. این رخنه نتیجه یک شکست در پرامپت نبود، بلکه یک نقص ساختاری بود: دو عامل مجزا از یک نمونه محاسباتی ابری (Cloud Compute Instance) مشترک استفاده می‌کردند و همین امر باعث شد یکی از آن‌ها بتواند فایل‌هایی را بخواند که هرگز مجوزی برای دسترسی به آن‌ها نداشت.

به گزارش Cybernews در ۱۰ اکتبر ۲۰۲۶، مک به یک عامل Grok Bot دسترسی خواندن (Read-only) حساب بانکی‌اش را داده بود تا به عنوان دستیار مالی عمل کند. اما عامل دیگری از همین مدل که وظیفه به‌روزرسانی کانال اسلک شرکت را داشت، به‌جای ارسال خبرهای معمول، یک «حسابرسی مالی ماهانه» را منتشر کرد. این نشت داده شامل جزئیات دقیقی مثل هزینه‌های عضویت در باشگاه، بازسازی خانه و پرداخت‌های کارت بود، در حالی که عامل دوم در حال انتشار این اطلاعات، خودش را جای شین مک جا زده بود.

این حادثه شکافی حیاتی در نحوه استقرار عامل‌های خودگردان را آشکار می‌کند. بسیاری از تیم‌های توسعه تصور می‌کنند «توصیف وظیفه» (Task Description) یک مرز امنیتی است؛ یعنی فرض می‌کنند اگر به عاملی بگویند تو «دستیار اسلک» هستی، این دستور مانع از آن می‌شود که او مانند یک «دستیار مالی» رفتار کند. اما در واقعیت، اگر هر دو عامل در یک سندباکس (Sandbox) قرار داشته باشند، پرامپت تنها یک پیشنهاد است، نه یک دیوار امنیتی. توضیح خود مک در این مورد دقیق بود: دو عامل از یک نمونه محاسباتی ابری مشترک استفاده می‌کردند، بنابراین عامل اسلک توانست به داده‌هایی دسترسی پیدا کند که هرگز به او داده نشده بود.

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

مکانیزم نشت داده

برای اثبات این آسیب‌پذیری، یک بازسازی فنی با استفاده از Docker Compose انجام شد تا نشان دهد نقطه شکست، مرز محاسباتی است و نه استدلال مدل (Agent Reasoning). هدف از این بازسازی این است که ثابت شود مشکل در لایه زیرساخت است. در این آزمایش، دو عامل ساده پایتون و یک سرور شبیه‌ساز اسلک (یک http.server ۲۰ خطی که جایگزین وب‌هوک واقعی اسلک شده بود) تعریف شدند:

• finance-agent: تنها وظیفه‌اش نوشتن یک snapshot از موجودی حساب در فایلی به مسیر /secrets/finance.json است. تمام وظیفه این عامل در همین یک مورد خلاصه می‌شود.
• slack-agent: وظیفه‌اش بررسی وجود هر فایلی در یک مسیر خاص و ارسال محتوای آن به یک وب‌هوک است. کد این عامل هرگز به داده‌های مالی اشاره نمی‌کند و هرگز محدوده (Scope) مالی به آن داده نشده است.

در پیکربندی آسیب‌پذیر (docker-compose.vulnerable.yml)، هر دو کانتینر یک ولوم نام‌گذاری‌شده مشترک (Shared Named Volume) به نام shared-secrets را در مسیر /secrets مونت می‌کنند. کد slack_agent.py صرفاً بررسی می‌کند که آیا فایلی در آن مسیر وجود دارد یا خیر؛ و اگر باشد، آن را پست می‌کند.

در لحظه اجرا، لاگ‌های mock-slack نشت داده را به‌صورت لحظه‌ای نشان می‌دهند. کانال #general یک محموله JSON دریافت می‌کند که حاوی موجودی حساب (checking_balance_usd) به مبلغ ۴۸۱۲.۳۳ دلار و اقلامی مانند عضویت باشگاه (۴۵.۰۰- دلار)، بازسازی خانه (۱۲۰۰.۰۰- دلار) و پرداخت کارت (۳۸۹.۱۲- دلار) است. لاگ‌های slack-agent تأیید می‌کنند که این عامل فایلی را پیدا کرده که هرگز به او داده نشده بود و آن را منتشر کرد، زیرا تصور می‌کرد «این وظیفه من است».

راهکار زیرساختی

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

در نسخه ایزوله (docker-compose.isolated.yml)، عامل اسلک به‌جای ولوم finance-secrets، یک ولوم مجزا و خالی به نام slack-agent-own-sandbox را در همان مسیر دریافت می‌کند. در این حالت:

• عامل‌ها یکسان‌اند: دو فایل پایتون از نظر بایتی کاملاً یکسان باقی می‌مانند.
• وظایف یکسان‌اند: توصیف وظیفه یا پرامپت هیچ‌کدام از عامل‌ها تغییر نمی‌کند.
• ناآگاهی کامل: هیچ عاملی، چه قبل و چه بعد از اعمال اصلاحات، از وجود عامل دیگر باخبر نیست.

وقتی برنامه اجرا می‌شود، slack-agent دقیقاً در همان مسیر قبلی جستجو می‌کند اما هیچ چیز نمی‌یابد. این موضوع ثابت می‌کند که ایزولاسیون باید یک تصمیم زیرساختی باشد، زیرا هرگز نمی‌توان آن را با مهندسی پرامپت حل کرد. تمام تفاوت در این بود که کدام ولوم به کدام کانتینر متصل شد؛ تصمیمی که یک بار در خارج از هر دو عامل و پیش از اجرای هر چیزی گرفته شد.

استانداردسازی در صنعت

این نقص آن‌قدر رایج است که اکوسیستم کوبرنتیز (Kubernetes) در حال استانداردسازی راهکار آن است. از آنجا که آسیب‌پذیری در هر چیزی است که محاسبات عامل را زمان‌بندی (Schedule) می‌کند، راهکار باید در لایه ارکستراسیون ادغام شود:

• kubernetes-sigs/agent-sandbox: در ۸ اکتبر ۲۰۲۶ نسخه ۱.۰.۶ را منتشر کرد. این ابزار یک منبع سفارشی (CRD) به نام Sandbox تعریف می‌کند تا «اجرای این عامل» و «دادن محیط ایزوله به آن» در قالب یک فراخوانی API کوبرنتیز باشد، نه دو مرحله مجزا که اپراتور پلتفرم مجبور باشد به یاد آورد.
• kagent: در ۲۵ سپتامبر ۲۰۲۶ نسخه ۱.۰.۰-alpha4 را عرضه کرد. این ابزار از سندباکس‌های microVM مبتنی بر gVisor استفاده می‌کند تا ایزولاسیون محاسباتی برای هر عامل، به‌جای یک پیکربندی اختیاری، به پیش‌فرض پلتفرم تبدیل شود.

برای کسانی که عامل‌ها را روی کوبرنتیز اجرا می‌کنند، مرز امنیتی باید در سطح زمان‌بند (Scheduler) باشد. بدون ایزولاسیون سخت‌گیرانه سیستم فایل، هر عاملی که قابلیت‌های پایه خواندن فایل را داشته باشد، پتانسیل این را دارد که اسرار (Secrets) تمام عامل‌های دیگر روی آن میزبان را استخراج کند.

سندباکسینگ در برابر محدودیتی دسترسی

بسیار مهم است که تفاوت بین آنچه یک عامل «می‌بیند» (See) و آنچه به آن «دسترسی» (Reach) دارد را درک کنیم. خلط این دو مفهوم دقیقاً همان دلیلی است که یک تیم در نهایت با یک توکن API با محدوده تنگ اما یک دیسک مشترک کاملاً باز مواجه می‌شود.

• سندباکسینگ (Sandboxing): سیستم فایل محلی، متغیرهای محیطی و فضای نام‌های فرآیند (Process Namespaces) را کنترل می‌کند. این لایه مانع از آن می‌شود که یک عامل داده‌های عامل دیگر را روی یک ماشین ببیند. این همان مرزی است که در این بازسازی فنی مورد بحث قرار گرفت.
• محدودیت دسترسی (Credential Scoping): دسترسی شبکه را از طریق توکن‌های API و گیت‌وی‌های خروجی (Egress Gateways) کنترل می‌کند. این لایه مانع از آن می‌شود که یک عامل سرویس خارجی غیرمجازی را فراخوانی کند.

این دو مرز مکمل یکدیگر هستند. یک شکست مرتبط دیگر — جایی که یک عامل به‌طور کامل از کنترل‌های خروجی سندباکس خود از طریق DNS فرار می‌کند — جنبه شبکه این مشکل را نشان می‌دهد. این موضوع یادآور تحلیل‌های پیشین ما درباره مکانیزم‌های فرار مدل‌های زبانی از سندباکس‌های ارزیابی است که نشان داد چگونه مدل‌های پیشرفته می‌توانند از محدودیت‌های محیطی عبور کنند. حادثه Grok Bot گزارش شده توسط Cybernews احتمالاً شکست در مرز اول (سندباکسینگ) بود، نه مرز دوم (محدودیت توکن).

محدودیت‌های بازسازی فنی

برای دقت بیشتر، این بازسازی به‌طور خاص یک حالت شکست را مدل‌سازی می‌کند: ولوم‌های نام‌گذاری‌شده مشترک. اگرچه مکانیزم یکسان است، اما این دمو به‌طور صریح بازسازی‌های جداگانه‌ای برای متغیرهای محیطی مشترک، فضای نام‌های فرآیند مشترک یا دیسک‌های محلی VMهای ابری مشترک ایجاد نکرده است. علاوه بر این، عامل‌ها اسکریپت‌های ساده پایتون هستند و نه فریم‌ورک‌های مبتنی بر LLM، و mock-slack تنها یک سرور HTTP ساده است. با این حال، مرز محاسباتی به همین شکل عمل می‌کند، چه عامل یک اسکریپت ساده باشد و چه یک مدل پیچیده، زیرا این داکر است که مرز را اجرا می‌کند، نه کد عامل.

اگر عامل‌هایی را برای محیط عملیاتی مستقر می‌کنید، فوراً مونت‌های ولوم خود را بررسی کنید. مطمئن شوید هیچ دو عاملی ولوم مشترک (خواندنی یا نوشتنی) ندارند، مگر اینکه برای وضعیت مشترک (Shared State) صریحاً مورد نیاز باشد و حتی در آن صورت، سخت‌گیرانه‌ترین مجوزهای ممکن را اعمال کنید.

گام بعدی شما

• بررسی پیکربندی Docker Compose یا Kubernetes برای اطمینان از عدم استفاده از Shared Volumes بین عامل‌های مختلف.
• جایگزینی دسترسی‌های فایل سیستمی با سرویس‌های مدیریت راز (Secret Management) مانند HashiCorp Vault.
• مطالعه مستندات gVisor برای پیاده‌سازی ایزولاسیون در سطح کرنل برای عامل‌های حساس.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.