وقتی یک AI Agent فقط متن تولید می‌کند، اجرای آن روی یک کاربر معمولی شاید تفاوت زیادی ایجاد نکند. اما وقتی Agent به Shell، فایل‌های سرور، اینترنت، Docker، Git، دیتابیس یا API دسترسی پیدا می‌کند، موضوع کاملاً متفاوت می‌شود.
یک Agent می‌تواند دستور اجرا کند، فایل بسازد یا حذف کند، پکیج نصب کند و به سرویس‌های دیگر متصل شود. بنابراین اگر همان پردازش با کاربر root اجرا شود، یک خطای ساده، Prompt Injection یا ابزار بیش‌ازحد قدرتمند می‌تواند دامنه خسارت را بسیار بزرگ‌تر کند.
⚠️ نکته مهم: مشکل اصلی این نیست که «AI حتماً مخرب است». مسئله این است که مدل ممکن است دستور اشتباه تولید کند، ورودی آلوده دریافت کند یا توسط داده‌ای که از اینترنت، فایل یا کاربر گرفته شده تحت تأثیر قرار بگیرد. بنابراین امنیت Agent باید بر پایه Least Privilege، Isolation و محدودسازی ابزارها طراحی شود.
چرا اجرای AI Agent با Root خطرناک است؟
کاربر root در لینوکس تقریباً اختیار کاملی روی سیستم دارد. Agentی که با این سطح دسترسی اجرا می‌شود، در صورت اجرای یک دستور نامناسب می‌تواند به بخش‌هایی از سرور دسترسی پیدا کند که اصلاً برای انجام وظیفه‌اش لازم نیست.
این مسئله برای Agentها اهمیت بیشتری دارد، چون برخلاف یک برنامه سنتی ممکن است مسیر اجرای آن‌ها به ورودی طبیعی زبان، فایل‌های خارجی، خروجی ابزارها، صفحات وب، ایمیل‌ها یا محتوای بازیابی‌شده از منابع مختلف وابسته باشد.
OWASP در راهنمای امنیت AI Agent نیز روی Least Privilege، محدودسازی ابزارها، اعتبارسنجی Tool Callها، Sandbox و کنترل دسترسی تأکید می‌کند.
یک اشتباه کوچک با Root چه تفاوتی ایجاد می‌کند؟
فرض کنید Agent قرار است فقط فایل‌های یک پروژه را بررسی کند. اگر Agent با یک کاربر محدود اجرا شود، خطایی مانند حذف یک فایل معمولاً به همان محدوده دسترسی محدود می‌شود. اما اگر همان Agent با Root اجرا شده باشد، احتمال دسترسی به تنظیمات سیستم، سرویس‌ها، فایل‌های حساس و سایر پروژه‌ها نیز وجود دارد.
به همین دلیل باید بین توانایی Agent و دسترسی Agent تفاوت قائل شویم. یک مدل قدرتمند لزوماً نباید دسترسی قدرتمند داشته باشد.
خطرهای اصلی اجرای Agent با دسترسی Root
🔹 حذف یا تغییر فایل‌های سیستم: Agent ممکن است فایل‌هایی خارج از پروژه را تغییر دهد.
🔹 تغییر تنظیمات سرویس‌ها: امکان تغییر سرویس‌های حیاتی مانند SSH، وب‌سرور یا فایروال افزایش پیدا می‌کند.
🔹 دسترسی به Secretها: فایل‌های محیطی، کلیدهای SSH و Credentialهای سرویس‌ها ممکن است در دسترس Agent قرار بگیرند.
🔹 نصب نرم‌افزار ناخواسته: Agent می‌تواند پکیج یا ابزارهایی را نصب کند که برای وظیفه اصلی لازم نیستند.
🔹 تغییر Firewall: یک دستور اشتباه می‌تواند پورت‌های ناخواسته باز یا قوانین امنیتی را حذف کند.
🔹 دسترسی به سایر پروژه‌ها: اگر چند سرویس روی VPS قرار داشته باشند، جداسازی آن‌ها دشوارتر می‌شود.
🔹 خروج اطلاعات: Agentی که دسترسی شبکه و فایل دارد، ممکن است اطلاعات حساس را به یک مقصد خارجی ارسال کند.
Prompt Injection چرا در Agentهای دارای Shell جدی‌تر است؟
در یک چت معمولی، Prompt Injection ممکن است باعث پاسخ نامناسب یا نادقیق شود. اما Agentی که ابزار اجرایی دارد می‌تواند پیام یا داده آلوده را به یک عمل واقعی روی سیستم تبدیل کند.
برای مثال، تصور کنید Agent یک فایل README یا یک صفحه وب را برای انجام وظیفه خود می‌خواند. اگر داخل آن محتوای مخربی وجود داشته باشد که Agent را به اجرای دستور دیگری ترغیب کند، امنیت سیستم دیگر فقط به Prompt اصلی وابسته نیست.
به همین دلیل OWASP توصیه می‌کند محتوای خارجی مانند صفحات وب، اسناد، ایمیل‌ها و خروجی ابزارها به‌عنوان داده غیرقابل اعتماد در نظر گرفته شوند و کنترل دسترسی در لایه اجرای ابزار اعمال شود، نه فقط با دستور متنی داخل System Prompt.
⚠️ یک اصل مهم: اگر Agent بتواند Shell اجرا کند، نباید فرض کنید که Prompt شما همیشه می‌تواند جلوی اجرای دستور خطرناک را بگیرد. کنترل امنیتی باید بیرون از مدل و در سطح سیستم‌عامل، Container، ابزار اجرا و مجوزها نیز وجود داشته باشد.
Root، کاربر معمولی یا Container؟
برای انتخاب معماری مناسب، ابتدا باید مشخص کنید Agent دقیقاً چه کاری انجام می‌دهد. یک Agent که فقط فایل‌های پروژه را تحلیل می‌کند، به دسترسی بسیار کمتری از Agentی نیاز دارد که باید سرویس Docker را مدیریت کند.
| روش اجرا | سطح دسترسی | ریسک | کاربرد مناسب |
|---|---|---|---|
| Root | تقریباً کامل | بسیار بالا | فقط موارد کاملاً کنترل‌شده |
| کاربر اختصاصی | محدود به منابع مشخص | متوسط تا پایین | اکثر Agentهای کاربردی |
| Container | محدود به محیط اجرا | پایین‌تر با تنظیم صحیح | Agentهای دارای اجرای کد |
| Sandbox / VM | ایزوله | مناسب برای ریسک بالا | Agentهای ناشناخته یا خودکار |
نکته مهم این است که Container به‌تنهایی تضمین امنیت نیست. تنظیمات اشتباه Volume، Network، Capability یا اجرای Container با Root می‌تواند سطح ایزولیشن مورد انتظار را کاهش دهد.
ساخت کاربر اختصاصی برای AI Agent در لینوکس
اگر Agent فقط باید روی یک پروژه کار کند، اولین قدم عملی این است که برای آن یک کاربر جداگانه ایجاد کنید.
sudo adduser aiagent sudo mkdir -p /opt/ai-agent sudo chown -R aiagent:aiagent /opt/ai-agent
حالا فایل‌های پروژه Agent را داخل مسیر مشخص قرار دهید و سرویس را با همان کاربر اجرا کنید. این کار باعث می‌شود Agent برای انجام وظیفه خود مجبور نباشد به کل فایل‌سیستم دسترسی داشته باشد.
بررسی کاربر اجرای Agent
whoami id pwd
خروجی whoami باید نشان دهد که برنامه با کاربر اختصاصی اجرا شده است، نه root.
برای Agent فقط Permission لازم را بدهید
یکی از اشتباهات رایج این است که کاربر اختصاصی ساخته می‌شود، اما سپس مالکیت کل سیستم یا مسیرهای حساس به آن داده می‌شود. چنین کاری عملاً بخش مهمی از مزیت Least Privilege را از بین می‌برد.
اگر Agent فقط باید روی /opt/ai-agent کار کند، همان مسیر را در اختیار آن قرار دهید. اگر نیاز به خواندن یک پوشه دیگر دارد، ابتدا مشخص کنید چرا و سپس همان مسیر را به شکل محدود در اختیار Agent قرار دهید.
🔹 مسیر پروژه را مشخص کنید.
🔹 دسترسی Write را فقط جایی بدهید که واقعاً لازم است.
🔹 دسترسی به /etc، کلیدهای SSH و Secretهای سیستم را محدود کنید.
🔹 Credentialهای سرویس‌های دیگر را در محیط Agent قرار ندهید.
🔹 برای عملیات حساس از تأیید انسانی استفاده کنید.
آیا دادن sudo به AI Agent مشکل را حل می‌کند؟
خیر. دادن sudo بدون محدودیت می‌تواند همان مشکل Root را با یک مرحله واسط ایجاد کند.
اگر Agent بتواند هر زمان که خواست sudo اجرا کند، کاربر غیرRoot عملاً مرز امنیتی بسیار ضعیفی خواهد داشت. اگر واقعاً Agent به یک دستور مدیریتی نیاز دارد، بهتر است دسترسی آن به عملیات مشخص و محدود شود.
اصل Allowlist بهتر از Wildcard است
به جای اینکه Agent بتواند هر فرمانی را اجرا کند، ابزار اجرایی باید تا حد امکان مجموعه مشخصی از عملیات را بپذیرد. این موضوع مخصوصاً برای Agentهای دارای Shell اهمیت دارد.
برای نمونه، Agentی که فقط وضعیت سرویس را بررسی می‌کند، نباید به‌صورت پیش‌فرض مجوز نصب پکیج، حذف فایل یا تغییر Firewall داشته باشد.
Agent نباید به تمام Secretهای سرور دسترسی داشته باشد
یکی از خطرناک‌ترین سناریوها قرار دادن همه Credentialها در محیط Agent است. فایل‌هایی مانند .env، کلیدهای SSH، Tokenهای API، Credential دیتابیس و تنظیمات Cloud باید تا حد امکان از محیط Agent جدا باشند.
اگر Agent برای یک عملیات خاص به Credential نیاز دارد، بهتر است دسترسی به آن Credential محدود، زمان‌دار و مخصوص همان عملیات باشد.
⚠️ اشتباه رایج: اجرای Agent از داخل Home کاربر اصلی سرور و قرار دادن کلیدهای SSH، فایل‌های Cloud CLI و تمام فایل‌های پروژه در همان محیط. Agent باید یک محیط کاری مشخص و حداقل Credential لازم را داشته باشد.
محدود کردن دسترسی شبکه Agent
امنیت فقط به فایل‌ها و Permissionهای لینوکس محدود نمی‌شود. اگر Agent بتواند آزادانه به اینترنت متصل شود، در صورت رفتار ناخواسته امکان ارسال درخواست به مقصدهای مختلف را نیز خواهد داشت.
بنابراین برای Agentهای حساس بهتر است مشخص شود که آیا واقعاً به اینترنت نیاز دارند یا خیر. در صورت نیاز، می‌توان دسترسی شبکه را به سرویس‌ها و مقصدهای موردنیاز محدود کرد.
| نوع Agent | دسترسی فایل | دسترسی شبکه | Isolation پیشنهادی |
|---|---|---|---|
| تحلیل کد | پروژه مشخص | حداقلی | User + Container |
| اجرای تست | Workspace | در صورت نیاز | Container |
| Agent دارای Shell | محدود | Allowlist | Sandbox |
| Agent مدیریت سرور | حداقلی | کنترل‌شده | محیط مدیریتی جدا |
سرور مناسب برای اجرای امن AI Agent چه ویژگی‌هایی دارد؟
اگر قصد اجرای AI Agent، RAG، ابزارهای Shell یا سرویس‌های هوش مصنوعی روی VPS را دارید، امنیت فقط به نرم‌افزار Agent مربوط نیست. بهتر است محیط اجرا منابع کافی، دسترسی مدیریتی مناسب و امکان جداسازی سرویس‌ها را داشته باشد.
در ایرانیکاسرور می‌توانید مشخصات سرور مجازی را متناسب با نیاز Agent انتخاب کنید؛ مخصوصاً زمانی که Agent به RAM، CPU، NVMe یا فضای جداگانه برای اجرای Containerها نیاز دارد.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
اجرای Agent داخل Docker؛ آیا کافی است؟
Docker می‌تواند یک لایه مهم برای جداسازی Agent ایجاد کند، اما نباید آن را معادل امنیت کامل بدانیم. نحوه Mount کردن Volumeها، دسترسی شبکه، Capabilityها، Socket داکر و کاربری که داخل Container اجرا می‌شود اهمیت زیادی دارد.
برای مثال، اگر Socket اصلی Docker بدون محدودیت در اختیار Agent قرار بگیرد، Agent ممکن است بتواند از مسیر Docker به منابع بیشتری از محیط مورد انتظار دسترسی پیدا کند.
بنابراین هدف این نیست که فقط بگوییم «Agent داخل Docker است». هدف باید ایجاد یک محیط محدود، قابل مشاهده و قابل حذف باشد.
نمونه ساختار منطقی برای Agent
Host VPS ├── Reverse Proxy ├── AI Agent Container │ ├── /workspace │ ├── محدودیت CPU/RAM │ ├── Network محدود │ └── User غیر Root ├── Database └── سایر سرویس‌ها
در این مدل، Agent به جای اینکه مستقیماً مالک سرور باشد، داخل یک محدوده مشخص فعالیت می‌کند. این همان رویکردی است که برای Agentهای دارای اجرای کد یا Shell ارزش بیشتری پیدا می‌کند.
محدودیت منابع؛ جلوگیری از Agentهای بی‌پایان
یک Agent ممکن است وارد Loop شود، یک ابزار را چندین بار اجرا کند یا پردازش سنگینی را بدون پایان ادامه دهد. این مسئله فقط امنیتی نیست و می‌تواند CPU، RAM، Disk و هزینه API را نیز تحت تأثیر قرار دهد.
🔹 سقف تعداد Tool Callها را تعیین کنید.
🔹 برای اجرای Agent محدودیت CPU و RAM در نظر بگیرید.
🔹 تعداد Retryها را محدود کنید.
🔹 برای Agentهای طولانی‌مدت Timeout داشته باشید.
🔹 مصرف Disk و Logها را زیر نظر بگیرید.
ثبت Log برای تمام عملیات Agent
اگر Agent دستور اجرا می‌کند، باید بتوانید بعداً بفهمید چه ابزاری، چه زمانی، با چه ورودی و با چه نتیجه‌ای اجرا شده است.
ثبت Log به‌خصوص زمانی اهمیت دارد که Agent به منابع واقعی سرور دسترسی دارد. بدون Log مناسب، بررسی یک تغییر ناخواسته یا رفتار غیرعادی بسیار دشوار خواهد شد.
در عین حال، نباید Credential، Token و اطلاعات حساس را بدون محافظت داخل Log ذخیره کنید.
چه زمانی Human-in-the-Loop ضروری است؟
هر عملیات Agent یکسان نیست. خواندن یک فایل با حذف دیتابیس، تغییر Firewall یا انتشار یک نسخه جدید روی Production از نظر ریسک یکسان نیست.
برای عملیات با اثر بالا بهتر است Agent فقط پیشنهاد عملیات را تولید کند و اجرای نهایی پس از تأیید انسان انجام شود.
⚠️ عملیات‌هایی که بهتر است بدون تأیید مستقیم انجام نشوند:
🔹 حذف دیتابیس یا فایل‌های مهم
🔹 تغییر قوانین Firewall
🔹 تغییر تنظیمات SSH
🔹 تغییر Credentialها
🔹 اجرای Migrationهای غیرقابل بازگشت
🔹 ارسال اطلاعات حساس به سرویس خارجی
یک معماری امن‌تر برای AI Agent روی VPS
اگر بخواهیم همه اصول را کنار هم قرار دهیم، معماری مناسب معمولاً چیزی شبیه این خواهد بود:
User ↓ AI Agent ↓ Policy / Tool Gateway ↓ Allowed Tools ↓ Restricted Container / Sandbox ↓ Limited Workspace ↓ Controlled Network ↓ VPS Infrastructure
در چنین معماری، مدل مستقیماً صاحب سیستم نیست. بین تصمیم Agent و اجرای عملیات، چند لایه کنترل قرار می‌گیرد.
چک‌لیست امنیتی قبل از اجرای Agent روی VPS
✅ Agent با کاربر Root اجرا نمی‌شود.
✅ برای Agent یک User اختصاصی ساخته شده است.
✅ دسترسی فایل‌ها فقط به Workspace موردنیاز محدود شده است.
✅ Agent به Credentialهای غیرضروری دسترسی ندارد.
✅ Toolها با Allowlist یا Policy محدود شده‌اند.
✅ دسترسی شبکه Agent بررسی شده است.
✅ برای اجرای کد از Sandbox یا Container استفاده شده است.
✅ CPU، RAM، Disk و تعداد اجرای Agent محدود شده‌اند.
✅ عملیات پرریسک نیاز به تأیید انسانی دارند.
✅ Log و Monitoring برای عملیات Agent فعال است.
در تنظیم امنیت Agent روی VPS مشکل دارید؟
اگر نمی‌دانید برای Agent خود چه سطحی از Permission، Isolation، Docker، Network یا منابع سرور مناسب است، قبل از اجرای آن روی محیط اصلی بهتر است ساختار سرویس بررسی شود.
ایرانیکاسرور می‌تواند برای بررسی و کانفیگ سرور، تنظیم محیط اجرای سرویس و رفع مشکلات فنی کنار شما باشد.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
منابع و استانداردهای امنیتی برای مطالعه بیشتر
برای طراحی دقیق‌تر معماری امنیتی Agent، مطالعه منابع رسمی امنیت AI و Agentic AI مفید است. راهنمای OWASP AI Agent Security موضوعاتی مانند Tool Abuse، Privilege Escalation، Prompt Injection، Data Exfiltration، Memory Poisoning و Least Privilege را بررسی می‌کند.
برای درک بهتر حملات Prompt Injection نیز می‌توانید راهنمای رسمی OWASP LLM Prompt Injection Prevention را مطالعه کنید.
در Agentهای برنامه‌نویسی و ابزارهای دارای Shell نیز توصیه‌های OWASP Secure Coding with AI درباره Sandbox، محدودسازی ابزارها، Credentialهای موقت و محدودیت منابع کاربردی است.
جمع‌بندی؛ Agent قدرتمند به معنی Permission قدرتمند نیست
اجرای AI Agent با Root معمولاً انتخاب مناسبی برای یک محیط Production نیست؛ چون در صورت خطای مدل، سوءاستفاده از ابزار، Prompt Injection یا پیکربندی اشتباه، دامنه اثر حادثه بسیار بزرگ‌تر می‌شود.
راهکار بهتر این است که Agent را با کاربر اختصاصی، Permission حداقلی، Workspace محدود، Toolهای Allowlistشده، Network کنترل‌شده و در صورت نیاز Container یا Sandbox اجرا کنید.
مهم‌ترین اصل این مقاله ساده است: به Agent فقط همان دسترسی‌ای را بدهید که برای انجام وظیفه‌اش لازم دارد؛ نه بیشتر.
دیدگاه‌ها
0 دیدگاه برای این مطلب ثبت شده است.