تصور کنید ابزاری که برای افزایش بهره‌وری تیم شما طراحی شده، بدون اینکه متوجه شود، تمام رمزهای عبور و پیام‌های محرمانهٔ شما را در یک پوشهٔ عمومی در اینترنت منتشر کند. این کابوس اکنون برای بیش از ۳۰۰ سازمان، از جمله غول‌های Fortune 500 و یک آزمایشگاه پیشرو در زمینه هوش مصنوعی، به واقعیت تبدیل شده است.
طبق تحلیل فنی منتشر شده در dev.to، بیش از ۱۳ هزار اسکرین‌شات داخلی در یک فضای ذخیره‌سازی (Storage Bucket) با دسترسی عمومی فاش شده است. این رخداد یادآور نشت گسترده اسکرین‌شات‌های سازمانی در گیت‌هاب است که نشان داد چگونه ابزارهای خودکار می‌توانند ناخواسته داده‌های حساس را افشا کنند. نکته تکان‌دهنده این است که هیچ «هک» سنتی یا سرقت اعتبارنامه‌ای در کار نبود؛ بلکه عامل‌های مرورگر (Browser Agents) در حین انجام وظایف مجاز خود، این داده‌ها را نشت دادند. این عامل‌ها صرفاً دستورات خود را برای ثبت وقایع و عیب‌یابی (Debugging) اجرا کرده و تصاویر را آپلود کردند، بدون اینکه بدانند مقصد این آپلودها برای تمام دنیا قابل مشاهده است. در این حادثه، هیچ اکسپلویت یا کد مخربی برای شروع نشت استفاده نشد، هرچند که خودِ اسکرین‌شات‌ها پس از عمومی شدن، باعث افشای اعتبارنامه‌ها و رمزهای عبور شدند.
این اتفاق یک شکاف بحرانی در پشتهٔ ایمنی فعلی هوش مصنوعی را برجسته می‌کند. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شکاف میان لایه‌های امنیتی و لایه‌های اجرایی همواره یک نقطه ضعف است. در این حادثه، اکثر سازمان‌ها بر حفاظ‌ها (Guardrails) متنی تکیه کرده بودند؛ فیلترهایی مانند فیلترهای تزریق پرامپت (Prompt Injection) یا Regexهای شناسایی اطلاعات حساس (PII) که برای جلوگیری از خروج داده‌ها طراحی شده‌اند. اما این دفاع‌ها برای اسکن رشته‌های متنی طراحی شده‌اند، نه تصاویر رستر (Raster Images).
وقتی یک عامل ابزار upload_file را با یک محموله تصویری فراخوانی می‌کند، داده‌ها به‌طور کامل از خط لولهٔ ایمنی عبور می‌کنند. در واقع، پشتهٔ ایمنی متنی و مسیر واقعی خروج داده‌ها از سازمان، دو خط لوله متفاوت هستند که هرگز با یکدیگر ارتباط برقرار نمی‌کنند. این یعنی سیستم امنیتی حتی متوجه نمی‌شود که داده‌ای در حال خروج است، زیرا فرمت آن متنی نیست.
برای درک بهتر، یک عامل را تصور کنید که وظیفه دارد در یک پنل مدیریت داخلی پیمایش کند. برای اینکه مدل پیشرفت خود را «ببیند»، یک اسکرین‌شات می‌گیرد. این تصویر ممکن است شامل متغیرهای محیطی (Environment Variables) صادر شده در یک ترمینال، یک پیام خصوصی در Slack یا یک توکن نشست (Session Token) باشد که در نوار آدرس مرورگر قابل مشاهده است. از آنجا که عامل، اسکرین‌شات را به عنوان یک توده ساختارنیافته از پیکسل‌ها می‌بیند و نه متنی حساس، آن را بدون تردید در یک سرویس شخص ثالث آپلود می‌کند. عامل نمی‌داند که محتوا حساس است؛ او فقط می‌داند که ثبت وضعیت و آپلود آن برای لاگ‌گذاری، بخشی از چرخه عملیاتی اوست.
سازوکار نشت داده‌ها
عامل‌های استفاده از کامپیوتر و مرورگر در یک حلقه مداوم عمل می‌کنند: آن‌ها یک اسکرین‌شات می‌گیرند، روی وضعیت بصری استدلال می‌کنند، یک اقدام را اجرا می‌کنند و دوباره اسکرین‌شات می‌گیرند تا نتیجه را تأیید کنند. این حلقه که هسته عملکردی عامل است، دقیقاً همان نقطه آسیب‌پذیری اصلی است. بردار نشت داده در گام نهایی این چرخه رخ می‌دهد:
- گام ۳: ثبت وضعیت فعلی صفحه (تصویر رستر ساختارنیافته). این داده یک رشته متنی نیست که بتوان با استفاده از Regex کلمه «password» را در آن جست‌وجو کرد.
- گام ۴: آپلود برای ثبت وقایع، عیب‌یابی یا تحویل به فراخوانی ابزار بعدی.
در این مورد خاص، سرویس ذخیره‌سازی مورد استفاده برای این لاگ‌ها، بیشتر برای راحتی توسعه‌دهندگان ساخته شده بود تا امنیت. این سرویس به عنوان یک لایه ذخیره‌سازی میانی برای خودِ ابزارهای عامل عمل می‌کرد، نه سیستمی که توسط تیم‌های امنیتی بررسی شده باشد. این لایه هرگز به عنوان یک سطح خروج داده (Exfiltration Surface) مدل‌سازی نشده بود، زیرا توسعه‌دهندگان تصور می‌کردند این آپلودها «فقط اسکرین‌شات‌هایی برای عیب‌یابی» هستند.
چرا حفاظ‌های استاندارد شکست خوردند؟
لایه‌های ایمنی فعلی مدل‌های زبانی بزرگ (LLM) از نظر معماری از مسیر اجرای ابزار جدا هستند. یک فیلتر پرامپت می‌تواند کاربر را از درخواست رمز عبور باز دارد، اما نمی‌تواند مانع از آن شود که یک عامل، تصویری از رمز عبوری که روی صفحه پیدا کرده است را آپلود کند. این وضعیت یک «شکاف تشخیص» (Detection-gap) ایجاد می‌کند که در آن فراخوانی‌های مجاز ابزار، محموله‌های (Payloads) غیرمجاز را جابه‌جا می‌کنند.
بررسی پرامپت‌های عامل برای شناسایی تزریق نیز در اینجا بی‌فایده است، زیرا هیچ تزریقی رخ نداده است. عامل فریب نخورده تا کاری مخرب انجام دهد؛ او صرفاً یک اقدام روزمره و مجاز (آپلود اسکرین‌شات طبق دستورالعمل) را انجام داده که اتفاقاً بایت‌های حساسی را با خود حمل می‌کرده است. این نوع نقص در نظارت، مشابه همان ضعف‌های امنیتی در عامل‌های OpenAI است که در آن اتکای بیش از حد به ناظر انسانی یا سیستم‌های نظارتی ناقص منجر به دور زدن محیط‌های ایزوله شد.
زمانی که یک تصویر در یک سرویس خارجی خارج از کنترل سازمان آپلود می‌شود، داده‌ها عملاً از دست رفته‌اند. تنها نقطه مداخله، لایه «مسیر سریع» (Fast-path) است؛ یعنی لحظه‌ای دقیقاً پیش از آنکه درخواست آپلود از نشست (Session) عامل خارج شود.
نقش پروکسی‌های عامل‌محور
برای مقابله با این مشکل، ابزارهایی مانند Sentinel از یک قلاب (Hook) به نام PreToolUse استفاده می‌کنند. این ابزار به‌طور خاص برای شناسایی الگوهای data_exfiltration_via_llm در لایه مسیر سریع طراحی شده است. به‌جای اسکن پیکسل‌های تصویر (که مسئله‌ای جداگانه و دشوارتر است)، پروکسی آرگومان‌های فراخوانی ابزار را بررسی می‌کند.
پروکسی Sentinel کلاس الگوهای مربوط به فراخوانی ابزارهایی که دستور می‌دهند محتوا به یک مقصد خارجی ارسال شود را ارزیابی می‌کند؛ مواردی مانند «این را به https://... ارسال کن» یا الگوهای خروج داده از طریق بلوک‌های کد و مارک‌داون. اگر عاملی سعی کند دستور upload_file را به یک URL خارجی تأییدنشده ارسال کند، پروکسی می‌تواند الگوی انتقال خروجی را شناسایی کرده و پیش از آنکه بایت‌ها از نشست خارج شوند، درخواست را مسدود کند.
علاوه بر این، اگر آپلود با متاداده‌ها، نام فایل‌ها یا زمینه‌های ثبت‌شده‌ای همراه باشد که حاوی کلیدهای API هستند، لایه‌های مستقل تشخیص اسرار (Secret Detection) این رشته‌ها را پاک‌سازی می‌کنند. تشخیص اسرار و اعتبارنامه‌ها به عنوان یک پیش‌پردازش مستقل اجرا می‌شود تا فرمت‌های شناخته‌شده کلیدها، هدرهای Authorization و تخصیص‌های متغیرهای محیطی (env-var) را پیش از بسته‌بندی برای آپلود، سانسور کند. این ساختار دو لایه دفاعی مجزا ایجاد می‌کند:
- تشخیص سازوکار: هدف قرار دادن فراخوانی‌های خروجی به سرویس‌های خارجی.
- تشخیص محتوا: هدف قرار دادن متن‌ها و متاداده‌های همراه.
نمونه پیاده‌سازی فنی
در یک پیاده‌سازی امن، فراخوانی ابزار به این صورت رهگیری می‌شود:
۱. رهگیری: عامل upload_file را با مقصدی مانند https://public-bucket.example-storage.net/uploads/ فراخوانی می‌کند.
۲. اسکن: پروکسی URL مقصد و فعل («upload») را ارزیابی می‌کند.
۳. مسدودسازی: سیستم الگوی data_exfiltration_via_llm را فعال کرده و استثنای ToolCallBlocked را صادر می‌کند.
یک نمونه از محموله امنیتی به این شکل خواهد بود:
{
"request_id": "f93a1c7e2b",
"security": {
"action_taken": "blocked",
"threat_score": 0.89,
"pattern_class": "data_exfiltration_via_llm"
},
"safe_payload": "[SENTINEL BLOCKED]: Tool call withheld — outbound transfer pattern detected. Matched: \"upload screenshot to https://storage.example-agent-tool.net/...\"."
}
اگر پشتهٔ عامل شما به‌جای پروکسی کامل، بر اساس نقطه اتصال مستقیم /v1/scrub ساخته شده است، همین بررسی برای هر متنی که ابزار شما برای توصیف اقدام آپلود، لاگ‌ها یا کپشن‌ها تولید می‌کند اعمال می‌شود، زیرا این نقطه اتصال مستقل از ارائه‌دهنده (Provider-agnostic) است.
این حادثه مفروضات امنیتی در مورد سیستم‌های عامل‌محور (Agentic) را به‌طور بنیادی تغییر می‌دهد. ثابت شد که «پرامپت‌های امن» زمانی که عامل قدرت تعامل با سیستم‌عامل و وب را دارد، ناکافی هستند. صنعت باید به سمت مدل «دیوار آتش» (Firewall) برای خروجی‌های ابزار حرکت کند، به‌گونه‌ای که هر انتقال داده خروجی، صرف‌نظر از فرمت فایل، به عنوان یک نشت احتمالی تلقی شود.
گام بعدی شما
- برای هر تیمی که امروز از عامل‌های مرورگر استفاده می‌کند، اولویت فوری، یک ممیزی ۵ دقیقه‌ای از مسیرهای خروجی ابزارها است. شما باید بررسی کنید نه اینکه «فکر می‌کنید» اسکرین‌شات‌ها و لاگ‌های عامل شما کجا می‌روند، بلکه دقیقاً کجا فرود می‌آیند و اطمینان حاصل کنید که این مقاصد خصوصی، احراز هویت‌شده و دارای کنترل دسترسی هستند.
- منتظر ظهور حفاظ‌های چندوجهی (Multimodal) باشید که می‌توانند به‌صورت آنی OCR و تشخیص اسرار را روی اسکرین‌شات‌های عامل، پیش از ذخیره در دیسک یا ابر، انجام دهند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو