سیستم‌های هوش مصنوعی در مقایسه با فناوری اطلاعات سنتی، بسیار دشوارتر محافظت می‌شوند؛ چه در برابر اشتباهات اپراتورها، چه مداخله‌های مخرب و چه رفتارهای ناپایدار و غیرقابل‌پیش‌بینی. این موضوع دو دلیل اصلی دارد.

اول اینکه خروجی‌های هوش مصنوعی احتمالی (Probabilistic) هستند؛ بنابراین ممکن است یک پرامپت یکسان در هر بار اجرا، پاسخ متفاوتی ایجاد کند.

دوم اینکه مدل‌های زبانی بزرگ امروزی (LLM) نمی‌توانند همیشه دستورها را از داده‌ها به‌طور قابل‌اعتماد تشخیص دهند.

با وجود مشکلات امنیتی اثبات‌شده‌ای که پیش‌تر درباره سیستم‌های هوش مصنوعی مطرح کرده‌ایم، نمی‌توان مزایای اقتصادی بالقوه استفاده از این فناوری را نادیده گرفت. به همین دلیل، بسیاری از شرکت‌ها در حال عبور از دستیارهای ساده هوش مصنوعی و حرکت به سمت عامل‌های هوش مصنوعی (AI Agents) هستند.

این عامل‌ها وظایف را به‌صورت مستقل انجام می‌دهند و مستقیماً به همان ابزارهایی دسترسی دارند که انسان‌ها استفاده می‌کنند؛ از خواندن پایگاه‌های داده گرفته تا تغییر تنظیمات در فرایندهای عملیاتی.

کارشناسان ما در مطالعه جدید خود بررسی کرده‌اند که چگونه می‌توان این ریسک‌ها را به‌صورت شفاف تعریف و تا حد امکان محدود کرد. این رویکرد از اصول مصونیت سایبری (Cyber Immunity) و امنیت از مرحله طراحی (Security by Design) الهام گرفته و آن‌ها را با شرایط عامل‌های هوش مصنوعی تطبیق می‌دهد.

اصول پایه امنیت از مرحله طراحی

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

۱. امنیت از همان مرحله طراحی، یک عامل مستقل و مهم است

اهداف و پیش‌فرض‌های امنیتی باید از همان روز نخست مشخص شوند و در تمام مراحل توسعه رعایت شوند.

برای عامل‌های هوش مصنوعی، این پیش‌فرض‌ها باید شامل سه نکته کلیدی باشند:

• مدل زبانی باید غیرقابل‌اعتماد (Untrusted) در نظر گرفته شود.

• هر نوع داده خارجی باید بالقوه مخرب تلقی شود.

• اقدامات برگشت‌ناپذیر نباید بدون تأیید اجباری انسان به‌صورت مستقل انجام شوند.

۲. سیستم با این فرض طراحی می‌شود که مورد حمله قرار خواهد گرفت

معماری سیستم باید از ابتدا بر این اساس طراحی شود که مهاجم تلاش خواهد کرد از آن سوءاستفاده کند.

۳. پایه محاسبات مورد اعتماد و سطح حمله باید حداقل باشد

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

اجرای سیاست‌های امنیتی باید کاملاً توسط اجزای قطعی (Deterministic) انجام شود؛ از جمله Policy Monitor، Agent Harness و سازوکارهای ایزوله‌سازی مانند Sandbox.

۴. اصل حداقل سطح دسترسی باید رعایت شود

هر عامل باید مجموعه اختصاصی خود از اعتبارنامه‌ها و مجوزهای دسترسی یا همان هویت (Identity) را داشته باشد که صرفاً به حداقل دسترسی لازم برای انجام وظیفه محدود شده است.

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

۵. اجزا باید از یکدیگر ایزوله باشند

در سیستم‌های مبتنی بر عامل، این موضوع یکی از پیچیده‌ترین و چندلایه‌ترین مسائل معماری است.

Agent Harness باید در یک محیط ایزوله، مانند Sandbox یا ماشین مجازی، اجرا شود و عامل‌ها نیز تا حد امکان از یکدیگر جدا نگه داشته شوند.

پردازش داده در Contextهای مورد اعتماد و غیرقابل‌اعتماد نیز باید از یکدیگر جدا باشد.

برای مثال، یک عامل Pull Request را می‌خواند و پیش‌نویس کد را ایجاد می‌کند، در حالی که عامل دیگری این کار را بررسی می‌کند، بدون اینکه متن بالقوه مخرب موجود در درخواست را مشاهده کند.

۶. قانون «ممانعت پیش‌فرض» باید حاکم باشد

سیاست‌های امنیتی باید از این قاعده پیروی کنند:

هر چیزی که صراحتاً مجاز نشده باشد، ممنوع است.

این اصل شامل فراخوانی ابزارها، تعامل میان عامل‌ها و ترافیک شبکه نیز می‌شود.

۷. دفاع چندلایه باید برقرار باشد

اقدامات امنیتی مختلف باید به‌صورت هم‌زمان عمل کرده و یکدیگر را تقویت کنند.

دفاع‌های احتمالی، مانند Guardrailهای هوش مصنوعی که نوعی «فایروال برای مدل‌های زبانی» محسوب می‌شوند یا Alignment که بیانگر درک مدل از رفتار قابل‌قبول و غیرقابل‌قبول است، نمی‌توانند هیچ تضمین رسمی امنیتی ارائه دهند.

با این حال، این سازوکارها در مجموع امنیت سیستم را افزایش می‌دهند و منبع ارزشمندی برای جمع‌آوری Telemetry هستند.

۸. زنجیره تأمین باید محافظت شود

برخی عامل‌ها می‌توانند به‌صورت مستقل Skillها، کتابخانه‌ها و سایر اجزای نرم‌افزاری را نصب کنند؛ بنابراین این قابلیت‌ها باید تحت قوانین سخت‌گیرانه قرار بگیرند.

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

سیستم‌هایی که بر پایه LLMهای ابری ساخته شده‌اند، با یک ریسک اضافی نیز مواجه‌اند: به‌روزرسانی مدل.

ممکن است یک روز، همان درخواست API توسط یک مدل زبانی متفاوت با ویژگی‌های امنیتی متفاوت پاسخ داده شود.

چالش‌های امنیت هوش مصنوعی

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

برای مثال، ممکن است تیم امنیتی تصور کند عاملی که روی رایانه یک توسعه‌دهنده اجرا می‌شود، در یک Sandbox قرار دارد و نمی‌تواند خارج از آن تغییری ایجاد کند.

اما یک مهاجم، یا حتی خود عامل، می‌تواند ده‌ها راه برای دور زدن این حفاظت ظاهراً مستحکم پیدا کند؛ از اجرای دستورات از طریق یک سرور محلی MCP که Sandbox آن را محدود نمی‌کند گرفته تا پیکربندی مجدد عامل هوش مصنوعی دیگری که روی سیستم نصب شده است.

برای پیچیده‌تر شدن شرایط، دامنه بردارهای حمله نیز بسیار گسترده است؛ از فیلدهای دلخواه در پیکربندی عامل گرفته تا رشته‌های متنی ظاهراً بی‌ضرر در فایل Skill.

یکی از مشکلات جدی که طراحان اغلب آن را دست‌کم می‌گیرند، خستگی کاربر است.

یک عامل پرمشغله ممکن است در هر دقیقه ده‌ها درخواست ایجاد کند و از کاربر بخواهد اقدامات بالقوه خطرناک را تأیید کند. پس از یک ساعت، کاربر ممکن است بدون اینکه واقعاً محتوای درخواست‌ها را بخواند، به‌صورت خودکار روی گزینه Approve کلیک کند.

به همین دلیل، تنظیم دقیق هم تعداد دفعات نمایش این درخواست‌ها و هم نحوه بیان آن‌ها اهمیت زیادی دارد.

هیچ‌کس توضیحات بیش از حد طولانی یک درخواست را نخواهد خواند. از طرف دیگر، توضیحات بیش از حد کوتاه نیز ممکن است جزئیات کلیدی موردنیاز کاربر برای تصمیم‌گیری صحیح را پنهان کند.

آسیب‌پذیری‌های موجود در عامل‌ها و ابزارهای مرتبط با آن‌ها نیز یک مشکل جدی و فوری هستند؛ مشکلی که سرعت بالای توسعه و به‌روزرسانی این دسته از نرم‌افزارها آن را تشدید می‌کند.

پلتفرم‌ها و برنامه‌های استاندارد این صنعت، مانند LangGraph، Microsoft Semantic Kernel و Claude Code، تاکنون بیش از یک بار با آسیب‌پذیری‌های بحرانی مواجه شده‌اند که برای آن‌ها وصله منتشر شده است.

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

علاوه بر این، پیاده‌سازی دقیق اقدامات امنیتی استاندارد و تثبیت‌شده در ابزارهای مورد استفاده می‌تواند در صورت حمله به عامل یا رفتار غیرمنتظره آن، میزان خسارت را به‌شدت کاهش دهد.

یکی از نمونه‌ها، استفاده از یک Allowlist سخت‌گیرانه از دامنه‌ها برای ابزار دریافت محتوای وب است؛ به‌گونه‌ای که عامل تنها بتواند به دامنه‌های مشخصی دسترسی پیدا کند.

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

نمونه قابل‌توجه این مسئله، حمله EchoLeak است. Microsoft 365 Copilot یک Allowlist مناسب و نسبتاً مؤثر برای دسترسی به سایت‌های خارجی داشت، اما مهاجمان توانستند از طریق قابلیتی در یک ابزار ثانویه و دامنه MS Teams، این محدودیت را دور بزنند.

توصیه‌های عملی برای معماران و تیم‌های امنیتی

معماران سیستم‌های هوش مصنوعی و مدیران تیم‌های مهندسی و امنیت باید امنیت عامل‌ها را از همان مرحله طراحی در نظر بگیرند.

تمرکز اصلی باید بر سازوکارهای قابل‌راستی‌آزمایی و قطعی باشد؛ از جمله ایزوله‌سازی اجزا، کنترل تعاملات و محدود نگه داشتن پایه محاسبات مورد اعتماد.

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

محدودیت‌هایی که پس از طراحی و به‌صورت اصلاحات جانبی اضافه می‌شوند می‌توانند ریسک‌ها را کاهش دهند، اما جایگزین یک معماری امن نخواهند شد.

در سطح سازمانی و عملیاتی، شرکت‌ها باید موجودی کاملی از عامل‌های خود داشته باشند، فعالیت تیم‌های امنیت و استقرار را با یکدیگر هماهنگ کنند، از محیط‌های Container محافظت کنند، زنجیره تأمین را با استفاده از AIBOM مدیریت کنند و دفاع چندلایه را به کار بگیرند.

قابلیت مشاهده و پایش (Observability) نیز نیازمند توجه ویژه است. در سیستم‌های هوش مصنوعی، این قابلیت باید شامل ثبت درخواست‌ها، پاسخ‌ها و فرایند استدلال LLM و همچنین Telemetry دقیق از میزبان‌ها و محیط‌های ابری محل اجرای Agent Harness باشد.

سخت‌ترین بخش طراحی عامل‌ها، ایجاد تعادل میان امنیت، عملکرد و کاربردپذیری است.