Sandbox ایجنت هوش مصنوعی محیطی است که اجرای ابزار و کد را در محدوده‌ای مشخص نگه می‌دارد. اگر ایجنت اجازه اجرای فرمان دارد، ممکن است بسته نصب کند، فایل بخواند یا به شبکه وصل شود. محدوده واقعی این اختیار را مجوزهای محیط تعیین می‌کنند. یک جمله در پرامپت یا وجود یک کانتینر، به‌تنهایی همه این مسیرها را کنترل نمیکند.
این راهنما برای کسی است که با ایجنت کدنویسی کار میکند یا محصولی می‌سازد که کد کاربران را اجرا خواهد کرد. ابتدا تفاوت محیط توسعه و اجرای کد نامطمئن را روشن می‌کنیم، سپس کنترل‌های لازم و یک فرمان آزمایشی محدود را بررسی می‌کنیم. برای انتخاب زیرساخت نیز جای پلتفرم ابری پاستا و API مدل‌های هوش مصنوعی را در این معماری توضیح می‌دهیم.
چه چیزی را از چه چیزی جدا می‌کنیم؟
پیش از نام ابزار، بنویسید کدام داده و عمل باید بیرون از دسترس کد بماند. در توسعه شخصی، نگرانی اصلی شاید پوشه‌های دیگر لپ‌تاپ و کلیدهای حساب باشد. در محصول چندکاربره، کد یک کاربر نباید به داده یا اجرای کاربر دیگر برسد. در یک سامانه سازمانی، دسترسی به شبکه داخلی و سرویس‌های دارای اعتبارنامه نیز اهمیت دارد.
این سناریوها پاسخ یکسان ندارند. محیطی که برای اجرای تست مخزن خودتان مناسب است، ممکن است برای اجرای ناشناس کد کافی نباشد. اگر مالک کد را نمی‌شناسید، وابستگی‌های آن را بررسی نکرده‌اید یا ورودی از منبع عمومی می‌آید، آن را صرفاً به دلیل تولیدشدن با AI قابل اعتماد ندانید. تولیدکننده کد، جای ارزیابی مجوز اجرای آن را نمیگیرد.
تفاوت دستور، مجوز و جداسازی
فایل AGENTS.md می‌تواند بگوید تست‌ها کجا هستند یا کدام پوشه نباید تغییر کند. این دستور برای هدایت کار مفید است. اما اگر همان فرایند از نظر سیستم مجوز حذف فایل را دارد، متن به‌تنهایی جلوی عمل را نمیگیرد. محدودیت قابل اتکا باید در فایلسیستم، هویت فرایند یا محیط اجرای ابزار برقرار باشد.
نمونه روشن آن Pi است. مستندات امنیت Pi توضیح می‌دهد ابزارها با مجوز فرایند اجرا می‌شوند و اعتماد به پروژه، Sandbox اجرای فرمان نیست. در راهنمای Pi و API پاستا می‌توانید اتصال مدل را ببینید؛ برای تعیین اختیار ابزارها، این مقاله را در کنار آن بخوانید.
| لایه | پرسش اصلی | روش بررسی |
|---|---|---|
| دستور ایجنت | چه کاری از ایجنت خواسته شده است؟ | بررسی متن راهنما و رفتار مشاهده‌شده |
| مجوز ابزار | کدام عمل اجازه اجرا دارد؟ | تلاش کنترل‌شده برای عمل مجاز و ممنوع |
| جداسازی اجرا | اگر کد برخلاف انتظار رفتار کرد به کجا می‌رسد؟ | آزمون فایل، شبکه، فرایند و منابع |
چرا کانتینر معمولی پاسخ کامل مسئله نیست؟
طبق توضیح امنیت Docker، جداسازی به چند لایه از جمله قابلیتهای هسته و تنظیمات کانتینر وابسته است. کانتینرها معمولاً هسته میزبان را به اشتراک می‌گذارند. نوع اجرا، مجوزها و اتصال به میزبان اهمیت دارند. برای تهدیدهای قویتر، ممکن است به runtime جدا، ماشین مجازی یا طرح تخصصی دیگری نیاز باشد.
دو کانتینر با تصویر یکسان می‌توانند سطح دسترسی بسیار متفاوتی داشته باشند. یکی بدون شبکه و با فایلسیستم فقط‌خواندنی اجرا میشود؛ دیگری پوشه خانه میزبان را قابل نوشتن دارد و Docker socket را دریافت کرده است. نام Docker یا Kubernetes، جزئیات همین تنظیمات را از تصمیم امنیتی حذف نمیکند. خروجی یک بررسی باید محدوده تضمین‌شده را بیان کند، نه فقط نام فناوری را.
کنترل فایل: فقط همان داده لازم را بدهید
پوشه کاری موقت را با حداقل فایل لازم آماده کنید. کل پوشه خانه، مخزن‌های دیگر و فایل اعتبارنامه را متصل نکنید. اگر وظیفه فقط تحلیل است، ورودی را فقط‌خواندنی بدهید و خروجی را در محل محدود دیگری بگیرید. برای ساخت برنامه، ممکن است برخی پوشه‌ها به نوشتن نیاز داشته باشند؛ همین نیاز را مشخص و دامنه آن را محدود کنید.
پوشه موقت نیز می‌تواند حاوی داده حساس شود. مدت نگهداری و روش پاک‌سازی آن را تعیین کنید و قبل از حذف، مسیر واقعی را بررسی کنید. اگر ایجنت قرار است خروجی را به پروژه اصلی منتقل کند، ابتدا فهرست تغییرها و اختلاف کد را بازبینی کنید. انتقال یک فایل خروجی نباید به جایگزینی بی‌دلیل کل پوشه منجر شود.