AI Agent Sandbox چیست؟ آموزش ساخت Sandbox امن برای اجرای Shell و دسترسی فایل Agent روی VPS

وقتی یک AI Agent فقط متن تولید می‌کند، بخش زیادی از نگرانی‌های امنیتی به محدودیت‌های معمول API برمی‌گردد. اما وقتی Agent بتواند دستورهای Shell اجرا کند، فایل بسازد، پروژه را تغییر دهد، پکیج نصب کند یا به شبکه دسترسی داشته باشد، شرایط کاملاً متفاوت می‌شود. در این حالت دیگر کافی نیست Agent را روی یک VPS نصب کنیم؛ باید برای اجرای آن یک محیط ایزوله و کنترل‌شده ایجاد کنیم.

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

در این مقاله یک معماری عملی برای اجرای Agentهای دارای Shell روی سرور مجازی لینوکس می‌سازیم و توضیح می‌دهیم چگونه با Docker، کاربر غیر root، محدودیت منابع، فایل‌سیستم موقت و محدودسازی شبکه، یک Sandbox کاربردی ایجاد کنیم. این مقاله درباره نصب یک Agent خاص نیست؛ تمرکز آن روی امن‌سازی Runtime اجرای Agent است.

AI Agent Sandbox دقیقاً چیست؟

AI Agent Sandbox یک محیط اجرای محدودشده برای Agent است. Agent به جای اینکه مستقیماً روی سیستم‌عامل اصلی VPS دستور اجرا کند، عملیات خود را داخل یک محیط جدا انجام می‌دهد.

برای مثال فرض کنید Agent وظیفه دارد یک پروژه Python را بررسی کند. بدون Sandbox ممکن است Agent چنین کارهایی انجام دهد:

اگر این Agent مستقیماً روی Host اجرا شود، مرز میان «محیط کاری Agent» و «سرور اصلی» بسیار کم می‌شود. اما در Sandbox می‌توان تعیین کرد Agent فقط یک دایرکتوری مشخص را ببیند، چه مقدار RAM و CPU مصرف کند و آیا اصلاً اجازه ارتباط شبکه داشته باشد یا خیر.

چرا اجرای Agent روی VPS بدون Sandbox خطرناک است؟

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

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

Sandbox چه چیزهایی را باید محدود کند؟

یک Sandbox مناسب برای Agent فقط به معنی «اجرای برنامه داخل Docker» نیست. بهتر است چند لایه کنترل را هم‌زمان در نظر بگیرید.

معماری پیشنهادی AI Agent Sandbox روی VPS

برای یک سرویس Self-Hosted یا Agent شخصی، معماری ساده زیر می‌تواند نقطه شروع مناسبی باشد:

در این معماری Agent تصمیم می‌گیرد چه ابزاری لازم دارد، اما اجرای واقعی عملیات حساس از طریق Sandbox انجام می‌شود. به این ترتیب Agent مستقیماً مالک Host نیست.

آموزش ساخت Sandbox برای Agent با Docker

Docker برای شروع گزینه مناسبی است، زیرا می‌توان Container را با محدودیت CPU، RAM، تعداد Processها، Capabilityها و دسترسی فایل اجرا کرد. Docker همچنین به‌صورت پیش‌فرض از پروفایل Seccomp استفاده می‌کند که بخشی از System Callها را محدود می‌کند. :contentReference[oaicite:0]{index=0}

مرحله اول: ساخت Workspace

ابتدا یک Workspace اختصاصی برای اجرای Agent بسازید:

sudo mkdir -p /opt/agent-sandbox/workspace
sudo chown -R 1000:1000 /opt/agent-sandbox/workspace

این مسیر قرار است تنها بخشی از فایل‌سیستم Host باشد که Agent اجازه مشاهده یا تغییر آن را دارد.

مرحله دوم: ساخت Image مخصوص Sandbox

یک Image ساده برای اجرای دستورات Agent ایجاد کنید:

cat > /opt/agent-sandbox/Dockerfile <<'EOF'
FROM ubuntu:24.04

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    bash \
    python3 \
    python3-pip \
    git \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN useradd -m -u 1000 agent

USER agent
WORKDIR /workspace

CMD ["/bin/bash"]
EOF

cd /opt/agent-sandbox
sudo docker build -t iranica-agent-sandbox:1.0 .

مرحله سوم: اجرای Container با محدودیت منابع

اکنون Container را طوری اجرا کنید که Agent فقط منابع مشخصی داشته باشد:

sudo docker run --rm -it \
  --name agent-sandbox \
  --memory=1g \
  --cpus=1.5 \
  --pids-limit=128 \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=256m \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  -v /opt/agent-sandbox/workspace:/workspace:rw \
  iranica-agent-sandbox:1.0

این ترکیب چند لایه مهم ایجاد می‌کند. Container به ۱ گیگابایت RAM محدود شده، تعداد Processها محدود است، تمام Linux Capabilityها حذف شده‌اند و Root Filesystem نیز Read-Only است.

چرا نباید کل / سرور را به Agent Mount کنیم؟

یکی از اشتباهات رایج در ساخت Agent Sandbox این است که برای راحتی، مسیرهای زیادی از Host داخل Container Mount شوند.

مثلاً این کار از نظر امنیتی بسیار خطرناک است:

-v /:/host

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

قاعده بهتر: فقط همان Workspace مورد نیاز Task را Mount کنید و تا حد امکان Mountها را Read-Only نگه دارید.

کنترل دسترسی فایل در AI Agent Sandbox

دسترسی فایل یکی از مهم‌ترین قسمت‌های Sandbox است. اگر Agent برای اصلاح یک پروژه فقط به مسیر /workspace نیاز دارد، نباید به کل Home یا مسیرهای حساس سیستم دسترسی داشته باشد.

Docker Socket چرا برای Agent خطرناک است؟

یکی از بدترین اشتباهات معماری این است که فایل /var/run/docker.sock را به Container Agent بدهیم.

-v /var/run/docker.sock:/var/run/docker.sock

Docker Socket یک Interface مدیریتی برای Docker Daemon است. دادن چنین دسترسی‌ای می‌تواند مرز میان Container و زیرساخت Docker Host را بسیار ضعیف کند. بنابراین برای یک Agent معمولی، این دسترسی باید ممنوع باشد مگر اینکه معماری دقیق و مدل تهدید شما چنین دسترسی‌ای را ضروری کرده باشد.

محدود کردن شبکه Agent

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

برای Agentهایی که اصلاً به اینترنت نیاز ندارند، می‌توان شبکه را خاموش کرد:

sudo docker run --rm -it \
  --network=none \
  --memory=1g \
  --cpus=1.5 \
  --pids-limit=128 \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  -v /opt/agent-sandbox/workspace:/workspace:rw \
  iranica-agent-sandbox:1.0

اگر Agent به اینترنت نیاز دارد، بهتر است به جای دسترسی نامحدود، یک لایه Proxy یا Allowlist برای مقصدهای مجاز در نظر گرفته شود.

آیا Docker به‌تنهایی Sandbox کاملاً امن است؟

خیر. Docker یک لایه ایزوله‌سازی مهم است، اما برای اجرای کد کاملاً غیرقابل اعتماد نباید به یک کنترل منفرد تکیه کرد. Docker از امکاناتی مانند Namespaces، Capabilities و Seccomp استفاده می‌کند و Rootless Mode نیز امکان اجرای Daemon و Container بدون Root را فراهم می‌کند. :contentReference[oaicite:1]{index=1}

برای Workloadهایی که ریسک بیشتری دارند، می‌توان Sandbox را یک لایه بالاتر برد و از تکنولوژی‌هایی مانند gVisor استفاده کرد. gVisor یک لایه دفاعی اضافه میان Container و Linux Kernel ایجاد می‌کند و برای Workloadهایی که نیاز به Isolation بیشتری دارند طراحی شده است. :contentReference[oaicite:2]{index=2}

Bubblewrap و nsjail برای Agentهای CLI

اگر هدف شما اجرای یک CLI Agent یا ابزار مشخص است، همیشه لازم نیست یک Container کامل برای هر Process ایجاد کنید. Bubblewrap می‌تواند با استفاده از Linux Namespaceها یک محیط فایل‌سیستم محدود ایجاد کند و امکان تعیین دقیق مسیرهای قابل مشاهده را فراهم می‌کند. :contentReference[oaicite:3]{index=3}

nsjail نیز امکاناتی مانند Namespace، cgroups، محدودیت منابع و Seccomp-BPF را در اختیار قرار می‌دهد و برای سناریوهای Process Isolation قابل استفاده است. :contentReference[oaicite:4]{index=4}

این ابزارها انعطاف زیادی دارند، اما یک نکته مهم وجود دارد: خود ابزار به‌تنهایی Policy امنیتی کامل نیست. تنظیمات Namespace، Mount، Network و Syscall باید متناسب با Threat Model شما طراحی شوند.

مدیریت Secretها و API Keyها در Sandbox

یکی از نقاطی که در طراحی Agent Sandbox معمولاً نادیده گرفته می‌شود، Secret Management است. حتی اگر فایل‌سیستم کاملاً ایزوله باشد، قرار دادن API Key داخل Environment Container می‌تواند باعث شود Agent آن را بخواند.

برای مثال، اگر Agent به یک API Key برای استفاده از سرویس خارجی نیاز دارد، بهتر است به جای قرار دادن Secret در Workspace، از یک Secret Manager یا Proxy استفاده شود. در معماری‌های حساس‌تر می‌توان درخواست Agent را از طریق یک سرویس واسط ارسال کرد تا خود Agent هرگز Secret اصلی را مشاهده نکند.

مدیریت چرخه عمر Sandbox

برای Agentهای موقت، بهتر است Sandbox نیز موقت باشد. یعنی بعد از پایان Task، Container و Workspace موقت حذف یا پاک‌سازی شوند.

یک معماری مناسب می‌تواند این چرخه را داشته باشد:

Logging؛ Agent باید قابل مشاهده باشد

Sandbox بدون Logging می‌تواند عیب‌یابی را دشوار کند. اگر Agent دستوری اجرا کرد که نتیجه نامطلوب داشت، باید بتوانید متوجه شوید چه دستوری اجرا شده، چه Processهایی ایجاد شده‌اند و چه خطایی رخ داده است.

برای محیط‌های حرفه‌ای، بهتر است حداقل این موارد ثبت شوند:

Sandbox برای Agentهای Coding چه شکلی است؟

یکی از کاربردهای مهم این معماری، Coding Agent است. فرض کنید Agent باید یک پروژه را بررسی کند، تست‌ها را اجرا کند و چند فایل را اصلاح کند.

در این سناریو Workspace پروژه را در اختیار Sandbox قرار می‌دهیم، اما مسیرهای حساس سیستم را خارج از محیط نگه می‌داریم. Agent می‌تواند Git، Python، Node.js یا ابزارهای مورد نیاز پروژه را اجرا کند، ولی دسترسی مستقیم به Host ندارد.

این مدل برای تیم‌های برنامه‌نویسی، سرویس‌های SaaS مبتنی بر Agent و پلتفرم‌هایی که به کاربران اجازه اجرای کد می‌دهند اهمیت زیادی دارد.

چک‌لیست امنیتی قبل از Production

چه زمانی Docker کافی نیست؟

اگر Agent فقط روی پروژه شخصی شما کار می‌کند و ورودی کاملاً تحت کنترل است، یک Container محدودشده می‌تواند نقطه شروع مناسبی باشد. اما وقتی کاربران مختلف می‌توانند Prompt یا Code وارد کنند، سطح ریسک تغییر می‌کند.

برای سرویس SaaS عمومی که کاربران ناشناس می‌توانند Agent را وادار به اجرای کد کنند، بهتر است معماری به سمت چند لایه Isolation حرکت کند. در چنین شرایطی گزینه‌هایی مانند gVisor یا MicroVM می‌توانند به‌عنوان لایه دفاعی اضافه بررسی شوند. gVisor مشخصاً برای ایجاد یک لایه ایزوله میان Container و Kernel میزبان طراحی شده است. :contentReference[oaicite:5]{index=5}

تفاوت AI Agent Sandbox با نصب Agent روی VPS

جمع‌بندی؛ Sandbox بخش مهم معماری Agentهای دارای Shell است

منابع فنی پیشنهادی برای مطالعه بیشتر:

🔹 Docker Rootless Mode

🔹 Docker Seccomp

🔹 gVisor Production Guide

🔹 Bubblewrap

🔹 Google nsjail