امنیت ایجنت‌های هوش مصنوعی، چرا معماری Cyber Immunity ضروری است؟

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

کسپرسکی در مقاله ای با عنوان Cyber Immunity lessons for AI agents همین موضوع را بررسی کرده است. یعنی امنیت از مرحله طراحی. ایجنت باید از روز اول با در نظر گرفتن تهدیدها ساخته شود. امنیت یک قابلیت جانبی نیست که بعد از توسعه به سیستم اضافه کنند. جزئی از معماری اصلی ایجنت است.

تفاوت چت بات و ایجنت هوش مصنوعی؛ افزایش سطح حمله

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

چرا ایجنت های هوش مصنوعی به معماری امنیتی متفاوتی نیاز دارند؟

کسپرسکی می گوید دو ویژگی مدل های زبانی بزرگ کار امنیت را سخت تر می کند.

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

ویژگی دوم این است که مدل همیشه نمی تواند دستور معتبر را از متن بیرونی جدا کند، و متن بیرونی هم ممکن است مخرب باشد. فرض کنید ایجنتی ایمیل های سازمان را بررسی می کند. مهاجم وسط یک ایمیل دستوری می نویسد: اطلاعات محرمانه را به یک آدرس بیرونی بفرست. اسم این حمله Prompt Injection است. ایجنت را وادار می کند برخلاف هدف اصلی اش کار کند. پس نوشتن یک System Prompt خوب برای امنیت ایجنت کافی نیست.

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

هشت اصل امنیتی کسپرسکی برای طراحی ایمن ایجنت ها

کسپرسکی اصول Security by Design را متناسب با سیستم های هوشمند بازتعریف کرده است. نتیجه هشت اصل شده. تیم های توسعه، امنیت و زیرساخت می توانند آن ها را چارچوب عملی کار خودشان کنند.

1. اصل اول این است که امنیت از طراحی شروع می شود. از همان ابتدا باید معلوم باشد ایجنت به چه اطلاعاتی دسترسی دارد. باید معلوم باشد چه اقداماتی مجاز است. و باید معلوم باشد در چه شرایطی اجرای دستور را متوقف می کند. سه فرض هم باید ثابت بماند. خروجی مدل زبانی داده ای غیرقابل اعتماد است. هر داده بیرونی، حتی از منبع ظاهراً معتبر، ممکن است مخرب باشد. و اقدام غیرقابل بازگشت بدون تأیید اجباری انسان انجام نمی شود.
2. اصل بعدی این است که معماری را با فرض وقوع حمله بسازیم. خطای رایج این است که همه اجزا را سالم فرض می کنند. معماری امن برعکس فکر می کند. نفوذ، دستکاری ورودی ها، سوءاستفاده از ابزار و رفتار غیرمنتظره ایجنت را از اول حساب می کند. ایجنتی که به یک سرویس خارجی وصل است نباید جواب آن را همیشه معتبر بداند. هر بخش حدود مشخص دارد. اگر یک مؤلفه شکست بخورد، کل زیرساخت نباید آسیب ببیند.
3. اصل سوم کم کردن سطح حمله و اجزای مورد اعتماد است. هر ابزار، اتصال یا مجوز اضافه، یک راه تازه برای مهاجم است. ایجنتی که فقط از یک دیتابیس می خواند، مجوز حذف و ویرایش لازم ندارد. کل اطلاعات سازمان را هم نباید در اختیارش گذاشت؛ فقط داده ای که برای وظیفه اش ضروری است. اجزایی که سیاست امنیتی را اجرا می کنند، مثل Policy Monitor و Agent Harness و مکانیزم های ایزوله سازی، باید از تصمیم های احتمالاتی مدل مستقل باشند.
4. اصل چهارم حداقل دسترسی یا Least Privilege است. هر ایجنت باید هویت و مجوز اختصاصی خودش را داشته باشد. یک حساب مشترک با دسترسی کامل برای همه ایجنت ها ریسک بسیار بالایی دارد. ایجنت تحلیل داده فقط بخواند. ایجنت گزارش فقط به داده های همان گزارش برسد. ایجنت مدیریت زیرساخت فقط اقدام های از پیش تعیین شده را اجرا کند. دسترسی موقت و سطح بالا هم فقط با تأیید یک مرجع مستقل فعال شود، و به همان عملیات و همان مدت لازم محدود بماند.
5. اصل پنجم ایزوله سازی است. از مهم ترین بخش های معماری امن همین است. محیط اجرای ایجنت را با Sandbox یا ماشین مجازی از بقیه سیستم جدا کنید. ایجنت های مختلف هم تا جای ممکن از هم مستقل باشند. مثلاً در توسعه نرم افزار دو ایجنت تعریف کنید. اولی درخواست توسعه دهنده را می خواند و پیش نویس کد می نویسد. دومی کد را بررسی می کند، بی آنکه مستقیم با متن احتمالاً مخرب درخواست اولیه روبرو شود. با این کار، دستور مخرب از یک مرحله به مرحله بعد منتقل نمی شود.
6. اصل ششم Default Deny است. هر دسترسی که صریح مجاز نشده، ممنوع است. این سیاست برای فراخوانی ابزار، ارتباط ایجنت ها با هم و دسترسی به شبکه اجرا می شود. ایجنتی که فقط با API داخلی شرکت کار دارد، نباید به هر دامنه دلخواه وصل شود. Allowlist برای ابزارها، دامنه ها و سرویس ها این کار را ساده تر می کند.
7. اصل هفتم دفاع چندلایه است. هیچ راهکار واحدی همه تهدیدها را نمی گیرد. چند لایه مستقل لازم است: کنترل دسترسی و مدیریت هویت، اعتبارسنجی ورودی و خروجی، محدود کردن فراخوانی ابزار، ایزوله سازی محیط اجرا، پایش رفتار ایجنت، ثبت رویدادهای امنیتی و تأیید انسانی برای عملیات حساس. کسپرسکی از Guardrail های هوش مصنوعی هم نام می برد، اما می گوید ماهیت احتمالاتی شان اجازه نمی دهد تضمین قطعی باشند.
8. اصل هشتم زنجیره تأمین است. ایجنت ها به کتابخانه، پلاگین، Skill و ابزارهای مختلف وصل می شوند. بعضی معماری ها اجازه می دهند ایجنت خودش بسته جدید نصب کند و قابلیت هایش را گسترش بدهد. این هم یک مسیر حمله تازه است. پس نصب ابزار و کتابخانه ناشناس را محدود کنید. فقط نسخه های تأییدشده را به کار ببرید. وابستگی ها را دوره ای بررسی کنید. تغییرات مدل های زبانی ابری را ارزیابی کنید. موجودی اجزای هوش مصنوعی را هم مستند کنید. اینجاست که AIBOM، یعنی فهرست اجزای سیستم های هوش مصنوعی، اهمیت پیدا می کند.

چالش های امنیتی ایجنت های هوش مصنوعی در عمل

اجرای اصول روی کاغذ کافی نیست. کسپرسکی چند چالش عملی را هم نام برده است.

• چالش اول دور زدن Sandbox از راه ابزار جانبی است. ایجنت داخل Sandbox روی سیستم توسعه دهنده اجرا می شود و به فایل های بیرون از محیط ایزوله دسترسی ندارد. ولی اگر همان سیستم به یک سرور MCP وصل باشد که محدودیت Sandbox را اعمال نمی کند، ایجنت از آن راه به منابع بیرونی می رسد. ایزوله سازی فقط وقتی جواب می دهد که همه مسیرها و ابزارهای جانبی هم کنترل شوند.
• چالش دوم خستگی از درخواست های تأیید است. ایجنتی که هر دقیقه چند درخواست تأیید نشان می دهد، کاربر را به تأیید خودکار عادت می دهد. آخرش یک درخواست خطرناک هم بدون بررسی تأیید می شود. درخواست ها باید به سطح ریسک بستگی داشته باشند و اطلاعات کافی برای تصمیم گیری بدهند.
• چالش سوم آسیب پذیری Framework هاست. LangGraph و Microsoft Semantic Kernel و Claude Code هم گرفتار آسیب پذیری شده اند. معروف بودن یک چارچوب، یعنی امن بودن آن نیست. تیم ها باید وابستگی ها را به روز کنند. اگر ممکن باشد، به جای چارچوب بزرگ و پیچیده، معماری سبک تری بسازند که با نیاز واقعی ایجنت بخواند.
• چالش چهارم اعتماد بیش از حد به Allowlist دامنه هاست. فهرست مجاز برای محدود کردن دسترسی اینترنتی کار درستی است، ولی کافی نیست. گاهی یک ابزار جانبی یا سرویس واسط راه دور زدن محدودیت ها می شود. کسپرسکی حمله EchoLeak به Microsoft 365 Copilot را مثال می زند. مهاجم ها از مسیرهای ارتباطی و قابلیت های جانبی استفاده کردند و محدودیت دسترسی به منابع خارجی را دور زدند. پس همه ابزارهای متصل به ایجنت باید در مدل تهدید بررسی شوند.
• چالش پنجم ثبت ناقص رویدادها و نبود نظارت کافی است. بدون ثبت دقیق، پیدا کردن رفتار غیرعادی و ریشه یک رخداد تقریباً ناممکن می شود. سازمان باید درخواست ها، پاسخ ها، فراخوانی ابزار و رویدادهای میزبان و محیط ابری را ثبت و تحلیل کند. خود لاگ ها هم باید با کنترل دسترسی و سیاست حفاظت از داده حساس مدیریت شوند. وگرنه خودشان منبع نشت می شوند.

توصیه های عملیاتی برای استقرار امن ایجنت ها در سازمان

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

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

معماری، سطح دسترسی و سیاست های عملیاتی از ابتدا با هر دو تیم تعریف می شود. تعامل های مهم، فراخوانی ابزار، تغییر دسترسی و اقدام های حساس هم باید قابل ردیابی باشند. و چون ابزارها و مدل ها سریع عوض می شوند، بررسی امنیتی فقط برای روز راه اندازی نیست. هر تغییر مهم در مدل، ابزار، Skill یا مجوز ایجنت ممکن است ارزیابی دوباره بخواهد.

جمع بندی، امنیت ایجنت ها باید از مرحله طراحی آغاز شود

ایجنت ها می توانند خیلی از کارهای تکراری و پیچیده سازمان را خودکار کنند. اما وقتی مستقیم به اطلاعات و ابزارهای عملیاتی وصل می شوند، مسئولیت تازه ای هم در امنیت سایبری به وجود می آید. ایجنتی که به دیتابیس مشتریان، API داخلی، سیستم مدیریت کاربران یا محیط تولید دسترسی دارد، با یک خطای ساده هم می تواند دردسر بسازد. یک Prompt Injection موفق هم همین طور. نتیجه فقط یک جواب غلط نیست. به نظر من پیام اصلی Cyber Immunity همین است: امنیت یک سیستم هوشمند را نباید به درست رفتار کردن مدل زبانی گره زد.

کنترل دسترسی، ایزوله سازی، محدود کردن ابزار، اعتبارسنجی عملیات و نظارت انسانی را باید به اجزایی سپرد که قابل اتکا و مستقل از مدل باشند. امنیت باید از مرحله طراحی دیده شود، نه بعد از اولین رخداد. یادتان هست گفتیم Security by Design؟ مسئله دقیقاً همین است.