تصور کنید یک عامل هوش مصنوعی با دسترسی کامل به دیتابیسهای حساس شرکت، بهدلیل یک دستور مخفی در یک ایمیل، تمام اطلاعات مشتریان را برای یک سرور خارجی ارسال کند. این کابوس امنیتی، دلیل اصلی جذب ۱۲۵ میلیون دلار سرمایه توسط Zenity در دور سری C است تا بتواند یک نقطه کور بحرانی در هوش مصنوعی سازمانی را هدف قرار دهد: توانایی عاملهای خودگردان برای اجرای اقدامات غیرمجاز.
به گزارش منابع صنعتی، این جذب سرمایه که توسط Norwest رهبری شد، مجموع سرمایهی افشاششدهی این شرکت را پس از دور سری B در اکتبر ۲۰۲۴ به حداقل ۱۸۰ میلیون دلار رساند. در این دور، سرمایهگذاران جدیدی چون Qumra Capital، SoftBank Vision Fund 2، Hitachi Ventures و LG Technology Ventures به جمع سهامداران پیوستند. همچنین حامیان قبلی از جمله Vertex Ventures، Third Point Ventures, DTCP و Intel Capital نیز در این مرحله مشارکت داشتند.
در حالی که موج اول هوش مصنوعی مولد بر چتباتهایی متمرکز بود که متنها را خلاصه میکردند یا دادهها را بازیابی مینمودند، صنعت اکنون به سمت «عاملها» (Agents) حرکت میکند؛ موجوداتی دیجیتال که نهتنها حرف میزنند، بلکه میتوانند واقعاً کار انجام دهند. این انتقال، یک شکاف امنیتی عظیم ایجاد میکند. این روند با پیشبینیهای بلندمدت همسو است، چرا که مارک زاکربرگ معتقد است میلیاردها عامل هوشمند تا سال ۲۰۳۱ وارد بازار خواهند شد و این حجم از گسترش، نیاز به زیرساختهای امنیتی را دوچندان میکند. عاملهای هوش مصنوعی سطح متفاوتی از ریسک را معرفی میکنند، زیرا میتوانند بر اساس مجوزهای اعطایی خود اقدام کنند. یک عامل با دسترسیهای بیش از حد میتواند بدون نظارت انسانی، به دیتابیسهای داخلی دسترسی پیدا کند، APIهای برنامهنویسی را فراخوانی کند، کدها را اجرا نموده، رکوردها را بهروزرسانی کند یا گردشهای کاری (Workflows) را در چندین سیستم سازمانی به طور همزمان فعال کند.
ریشهٔ ریسک در لایهٔ عامل
این تغییر رویکرد، مشکل امنیتی را از این سطح که «آیا مدل پاسخی نامناسب تولید میکند یا خیر»، فراتر میبرد. سازمانها اکنون با یک چالش «حکمرانی» (Governance) روبرو هستند: آنها باید دقیقاً بدانند کدام عاملها مستقر شدهاند، چه کسی آنها را کنترل میکند، به چه اطلاعاتی دسترسی دارند و مجاز به انجام چه اقداماتی هستند.
طبق اعلام Zenity، یک آسیبپذیری بحرانی در اینجا وجود دارد: عامل میتواند دقیقاً همانطور که طراحی شده رفتار کند و در عین حال باعث ایجاد یک حادثه امنیتی شود. این اتفاق زمانی میافتد که عامل با اطلاعات دستکاریشده مواجه شود یا دستورات یک مهاجم را به عنوان بخشی از یک وظیفه قانونی تفسیر کند. Zenity این وضعیت را به عنوان یک مشکل در «لایه عامل» (Agent-layer) توصیف میکند.
همانطور که در تحلیلهای قبلی ما دربارهی پروتکل زمینهٔ مدل (Model Context Protocol) اشاره کردیم که هدفش ایمنسازی تعاملات عاملها است، Zenity استدلال میکند که ابزارهای امنیتی سنتی ناکافی هستند. اکثر پلتفرمهای امنیتی ابری تنها زیرساخت را میبینند و سیستمهای مدیریت هویت (Identity) تنها رمزهای عبور را مدیریت میکنند؛ اما هیچکدام از اینها «قصد» (Intent) خاص پشت یک توالی از فراخوانیهای ابزار هوش مصنوعی یا نقش مورد نظر عامل را درک نمیکنند.
معماری امنیتی Zenity
پلتفرم Zenity برای جلوگیری از نفوذ، بر سه ستون اصلی استوار است. تمرکز این سیستم بهجای بررسی صرف پرامپتها و پاسخها، بر پیکربندی عامل، مجوزها، ابزارهای متصل، حافظه و اقدامات در زمان اجرا (Runtime) است:
- مشاهدهپذیری (Observability): این سیستم بهطور خودکار تمامی عاملهای فعال در یک سازمان را شناسایی و فهرست میکند. این فهرست شامل عاملهای جاسازی شده در پلتفرمهای نرمافزاری به عنوان سرویس (SaaS)، عاملهای توسعهیافته داخلی که در محیطهای ابری اجرا میشوند و ابزارهای محلی نصب شده روی دستگاههای کارکنان است. این قابلیت به تیمهای امنیتی تصویری بهروز از مالک، پیکربندی و رفتار هر عامل در زمان اجرا میدهد؛ این موضوع حیاتی است زیرا امروزه کارکنان بدون طی کردن بررسیهای امنیتی متداول، عاملهای جدیدی خلق میکنند.
- مدیریت وضعیت امنیتی (Security Posture Management): لایه حکمرانی Zenity، پیکربندیها و مجوزها را پیش از آنکه عامل وارد محیط عملیاتی (Production) شود، ارزیابی میکند. این کار باعث شناسایی عاملهای «بیشدسترسی» (Over-privileged) و ادغامهای ناامنی میشود که ممکن است به عامل اجازه دهد فراتر از نقش تعیینشده عمل کند. پلتفرم این کنترلها را با تغییرات احتمالی عامل در طول زمان، بهطور مستمر چک میکند.
- تشخیص و پاسخ (Detection and Response): در زمان اجرا، پلتفرم مسیر اجرای عامل، از جمله فراخوانیهای ابزار، دسترسی به حافظه و استفاده از دادهها را تحلیل میکند. سیستم میتواند یک اقدام را در لحظه اجازه دهد، اصلاح کند یا مسدود نماید. این رویکرد تفاوت بین یک درخواست عادی و درخواستی که تحت تأثیر محتوای مخرب است را تشخیص میدهد و محدودیتهای «فیلتر پرامپت» را برطرف میکند؛ جایی که یک نتیجه خطرناک ممکن است از توالی چند اقدام تکتک بیضرر حاصل شود.
یکپارچهسازی اکوسیستمهای پراکنده
به نقل از گزارش unite.ai، هدف Zenity ایجاد یک لایه امنیتی واحد در سه محیط متمایز و پراکنده است. این یک چالش فنی بزرگ است زیرا تلهمتری و معماری یک Copilot در SaaS با یک عامل ابری سفارشی تفاوتهای اساسی دارد.
محیطهای SaaS:
پشتیبانی از عاملهای مرتبط با پلتفرمهایی نظیر Microsoft 365 Copilot، Microsoft Copilot Studio، ChatGPT Enterprise و Salesforce (CRM) Agentforce. این سیستمها به عاملها دسترسی به اسناد تجاری، رکوردهای مشتریان و ارتباطاتی میدهند که سازمانها بهطور کامل میزبان یا کنترلکننده آنها نیستند.
عاملهای ابری سفارشی:
پوشش عاملهایی که با استفاده از سرویسهایی مانند AWS Bedrock، Azure AI Foundry و Google Vertex AI ساخته شدهاند. Zenity نظارت میکند که این عاملها دقیقاً کدام ابزارها و سرویسهای ابری را فراخوانی میکنند و سیاستهای امنیتی را هم در مرحله توسعه و هم در مرحله اجرا اعمال میکند.
عاملهای مبتنی بر دستگاه:
این دسته شامل دستیاران کدنویسی، اپلیکیشنهای دسکتاپ و مرورگرهای عاملمحور (Agentic Browsers) است. از آنجا که این ابزارها در محیط احراز هویتشدهی کاربر (کارمند) عمل میکنند، بهطور بالقوه دسترسی به فایلهای محلی، نشستهای مرورگر و سرویسهای متصل را به ارث میبرند.
افشای حملات «بدون کلیک» (Zero-Click)
بخش Zenity Labs نشان داد که سامانههای خودکار چگونه میتوانند از طریق محتوای غیرقابلاعتماد دستکاری شوند. در پژوهشی با نام «AgentFlayer»، زنجیرههای حمله «بدون کلیک» (Zero-click) و «یک کلیک» (One-click) در پلتفرمهای هوش مصنوعی سازمانی مورد بررسی قرار گرفت. این نمایشها ثابت کرد که دستورات مخرب ارسال شده از طریق ایمیلها، اسناد، تیکتهای پشتیبانی یا ابزارهای همکاری تیمی میتوانند باعث شوند عاملها اطلاعات را افشا کرده یا از ابزارهای متصل سوءاستفاده کنند.
در آزمایش جدیدتری، محققان مرورگر عاملمحور Comet متعلق به Perplexity را هدف قرار دادند. آنها دریافتند دستورات مخفی گنجانده شده در یک دعوتنامه تقویم (Calendar invitation) میتواند مرورگر را در حالی که در حال انجام یک وظیفه روتین است، تحت تأثیر قرار دهد. در یک سناریوی خاص، عاملِ آلوده شده به گاوصندوق وب 1Password که باز بود هدایت شد و اعتبارنامهها (Credentials) را از طریق درخواستهای وب معمولی ارسال کرد. این نوع آسیبپذیریها در ابزارهای مرورگر، مشابه مواردی است که شرکت Bloom Security نیز با جذب ۲۰ میلیون دلار سرمایه برای مقابله با ریسکهای مشابه در افزونههای مرورگر و عاملها وارد میدان شد.
این تحقیق، علت مشکل را عدم تفکیک کافی بین «قصد کاربر» و «محتوای شخص ثالث» که عامل با آن مواجه میشود، دانست. چون عامل در یک نشست مرورگر احراز هویتشده عمل میکرد، از دسترسیهایی استفاده کرد که کاربر بهطور قانونی اعطا کرده بود. این ثابت میکند که فیلتر کردن پرامپت کافی نیست و امنیت باید در مرزِ «اقدام» (Action) اعمال شود.
رشد تجاری و جایگاه در بازار
رشد Zenity نشاندهندهی فوریت این مشکل است. این شرکت گزارش میدهد که درآمدش در هر یک از دو سال گذشته سه برابر شده و در مسیر آن است که امسال نیز مجدداً سه برابر شود. پایگاه مشتریان آن عمدتاً سازمانهای Fortune 500 و Global 2000 است که در صنایع تحت نظارت و سختگیرانه فعالیت میکنند، از جمله:
- خدمات مالی
- بهداشت و درمان
- داروسازی
- تولید صنعتی
- انرژی
Zenity که در حال حاضر بیش از ۲۳۰ کارمند دارد، مراکز تحقیق و توسعه (R&D) خود را در تلآویو و توابع عملیاتی و ورود به بازار (Go-to-market) را در نیویورک مستقر کرده است. تزریق سرمایه ۱۲۵ میلیون دلاری جدید برای تسریع در توسعه محصول، گسترش Zenity Labs و تقویت حضور در اروپا و منطقه آسیا-پاسیفیک استفاده خواهد شد. همچنین این مبلغ به شرکت اجازه میدهد تا از تعداد رو به رشدی از چارچوبهای متنوع عاملها پشتیبانی کند. این موج سرمایهگذاری در این حوزه گسترده است و سرمایهگذاری ۱۹۰ میلیون دلاری ThreatLocker برای مهار عاملهای هوش مصنوعی نیز نشاندهنده رقابت شدید برای تسلط بر امنیت این لایه است.
این گسترش کمتر از دو سال پس از دور سرمایegبه نهادی قبلی رخ میدهد. در آن زمان، Zenity بر امنیت اپلیکیشنهای Low-code و No-code تأکید داشت. جایگاه فعلی شرکت نشاندهنده یک تکامل است: کارکنانی که زمانی اپلیکیشنهای تجاری ساده میساختند، اکنون میتوانند عاملهایی خلق کنند که قادر به تصمیمگیری و اداره سیستمهای متصل هستند.
ظهور یک دستهبندی امنیتی جدید
این جذب سرمایه نشان میدهد که «امنیت عامل» (Agent Security) در حال تبدیل شدن به یک دستهبندی مستقل در امنیت سایبری است، نه صرفاً ویژگیای در محصولات موجود ابری، هویتی یا Endpoint. استدلال برای یک دستهبندی اختصاصی این است که ابزارهای سنتی تنها بخشی از فعالیت را میبینند: پلتفرمهای ابری زیرساخت را بازرسی میکنند و سیستمهای هویت مجوزها را مدیریت میکنند، اما هیچکدام نمیفهمند که زنجیرهای از فراخوانی ابزارها چگونه با هدف اصلی کاربر مرتبط است.
با این حال، Zenity با چالشی بزرگ روبروست: باید ثابت کند کنترلهای مبتنی بر «قصد» (Intent-based) میتوانند در چارچوبهایی که بهسرعت تغییر میکنند، بدون ایجاد تأخیر (Latency) غیرقابلقبول یا مسدود کردن کارهای قانونی عمل کنند. همچنین باید سازمانها را متقاعد کند که یک پلتفرم مجزا بخرند، بهجای آنکه به کنترلهایی تکیه کنند که توسط ارائهدهندگان بزرگی مثل مایکروسافت یا گوگل اضافه میشوند.
همانطور که عاملها از فاز «آزمایشی» به سمت کنترل فرآیندهای تجاری حساس و دسترسی به دادههای محرمانه حرکت میکنند، نیاز به مکانیزمی برای شناسایی عاملهای موجود، محدود کردن اقدامات آنها و مداخله پیش از تبدیل یک اقدام ناخواسته به یک نفوذ امنیتی، به یک اولویت در سطح هیئتمدیره سازمانها تبدیل شده است.
گام بعدی شما
- بررسی دسترسیهای granted به عاملهای AI در سازمان خود و حذف دسترسیهای اضافی (Principle of Least Privilege).
- مطالعه مستندات Zenity Labs برای شناسایی نقاط ضعف در جریانهای کاری عاملمحور.
- ارزیابی ابزارهای مانیتورینگ Runtime بهجای تکیه صرف بر فیلترهای ورودی.
اما پذیرش این ابزارها توسط سازمانها با چالش تأخیر (Latency) در پاسخدهی مدلها روبروست؛ بررسی میکنیم که چگونه بهینهسازی استنتاج میتواند این مانع را بردارد.
گفتگو