Plimsoll امنیت کدِ عامل‌های هوش مصنوعی را با لایه‌های جداسازی تأییدپذیر تضمین

تصور کنید کدی را که یک عامل هوش مصنوعی نوشته است، بدون هیچ اطمینانی روی سرور خود اجرا می‌کنید؛ در واقع شما در حال قمار روی امنیت زیرساختتان هستید. اکثر توسعه‌دهندگان در حال حاضر کدهای نوشته شده توسط عامل‌ها را بر اساس یک اعتماد کورکورانه اجرا می‌کنند. سرویس Plimsoll که در ۱۱ اکتبر ۲۰۲۶ منتشر شد، با تبدیل «مرز جداسازی» از یک تنظیمات پنهان به یک مدرک قابل تأیید، این بازی خطرناک را به پایان می‌رساند.

بسیاری از محیط‌های سندباکس (Sandbox) — شبیه به یک اتاق آزمایش ایزوله که در آن مواد خطرناک را بدون ترس از نشت به محیط بیرون تست می‌کنیم — به‌صورت جعبه سیاه عمل می‌کنند و کاربر فقط امیدوار است که کانتینر امن باشد. طبق مستندات Plimsoll، این سامانه سیستمی را معرفی می‌کند که در آن هر نتیجه اجرا به‌طور صریح «لایه جداسازی» (Isolation Tier) خود را اعلام می‌کند؛ این لایه‌ها از یک پردازش ساده گرفته تا یک ماشین مجازی کامل را شامل می‌شوند. این یعنی فراخوان‌کننده می‌تواند اگر «کف امنیتی» (Security Floor) بیش از حد پایین باشد، اجرای کد را رد کند. نام این سرویس از «خط پلیمسول» (Plimsoll line) گرفته شده است؛ همان خطی که روی بدنه کشتی‌ها رسم می‌شود تا هر کسی بتواند حد مجاز بارگیری و ایمنی کشتی را به‌صورت بصری چک کند. Plimsoll همین کار را برای لایه جداسازی انجام می‌دهد: اینکه دیوار اطراف یک اجرا چقدر محکم است.

این رویکرد درست زمانی معرفی می‌شود که عامل‌های هوش مصنوعی از تولید متن ساده به سمت استفاده خودکار از ابزارها حرکت می‌کنند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، وقتی عامل‌ها برای حل مسائل دنیای واقعی اسکریپت می‌نویسند و اجرا می‌کنند، ریسک تزریق پرامپت (Prompt Injection) که منجر به اجرای کد از راه دور (RCE) روی ماشین‌های میزبان می‌شود، به یک گلوگاه بحرانی برای پذیرش این فناوری در سازمان‌های بزرگ تبدیل شده است.

چهار لایه جداسازی

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

• پردازش (Process): از QuickJS روی wazero (یک محیط اجرای WebAssembly که به زبان Go نوشته شده) در داخل خودِ plimsolld استفاده می‌کند. این لایه برای توسعه سریع محلی طراحی شده است اما هیچ دیواری در سطح سیستم‌عامل ندارد؛ هرگونه نشت کد (باگی که اجازه خروج کد از سندباکس را بدهد) مستقیماً وارد دیمون (Daemon) شما می‌شود. برای کدهای خصمانه هرگز از این لایه استفاده نکنید.
• کانتینر (Container): از Docker استاندارد با runc استفاده می‌کند. این لایه هسته (Kernel) ماشین را به اشتراک می‌گذارد و برای میزبانی شخصی مناسب است، مگر اینکه باگی در هسته سیستم‌عامل جزو حملاتی باشد که برای آن برنامه‌ریزی کرده‌اید. این لایه از نشست‌ها (Sessions) از طریق یک Image پروژه پشتیبانی می‌کند و اجازه می‌دهد متغیرهای مفسر JavaScript یا Python بین فراخوان‌ها باقی بمانند.
• هسته (Kernel): از gVisor (runsc) استفاده می‌کند که به عنوان لایه‌ای بین کانتینر و هسته میزبان عمل می‌کند. gVisor درخواست‌های کانتینر به سیستم‌عامل را مدیریت می‌کند تا کد هرگز مستقیماً با هسته شما صحبت نکند. این لایه برای اجرای کدهای خصمانه روی ماشین‌های شخصی توصیه می‌شود.
• ماشین مجازی (VM): از microVMها از طریق E2B (Firecracker) یا Docker Cloud Sandboxes استفاده می‌کند. این قوی‌ترین سطح جداسازی است چون کد روی سخت‌افزاری مجزا اجرا می‌شود و هزینه آن به ازای هر اجرا محاسبه می‌گردد. E2B از مانیتور VM متن‌باز AWS استفاده می‌کند. Docker Cloud Sandboxes (که در ۴ اکتبر ۲۰۲۶ تست شده) یک سرویس میزبانی شده با سیاست شبکه «رد همه» (deny-all) ارائه می‌دهد.

اجرای تأییدپذیر و اثرانگشت دیجیتال

برای جلوگیری از اینکه عامل‌ها موفقیت کاذب گزارش کنند یا نتایج را دستکاری کنند، Plimsoll یک زنجیره شواهد سخت‌گیرانه را اجرا می‌کند. هر اجرا، هش‌های SHA-256 درخواست ارسالی و نتیجه بازگشتی را برمی‌گرداند. کلاینت‌های رسمی این هش‌ها را مجدداً محاسبه می‌کنند تا یکپارچگی داده‌ها را تضمین کنند. برنامه‌ای مجزا در خارج از دیمون به نام plimsoll-attest نتایج بررسی شده را امضا می‌کند، اگر در زنجیره تماس‌ها حتی یک مورد گم شده باشد آن را رد می‌کند و می‌تواند یک اجرا را بازپخش (Replay) کند.

این سازوکار اجازه می‌دهد تا Plimsoll نه تنها کد نوشته شده توسط عامل را مهار کند، بلکه روی آن امتحان بگیرد. یک اجراکننده آزمایشی (Trial Runner) که در Image شبیه‌سازی تعبیه شده، برنامه را در مقابل سناریوهایی قرار می‌دهد که خودِ برنامه قادر به خواندن آن‌ها نیست؛ هر سناریو در فایلی به اجراکننده می‌رسد که پیش از شروع برنامه حذف می‌شود. این امتحان — شامل سیستم شبیه‌سازی شده، سناریوها و نمره قبولی — دارایی کاربر باقی می‌ماند و Plimsoll فقط مرز جداسازی و شواهد را فراهم می‌کند.

یک مثال عینی، مسئله شبیه‌سازی شده «عربه-میله» (cart-pole) است؛ یک مسئله استاندارد در مهندسی کنترل که در آن یک عربه روی ریل باید با فشار دادن به چپ و راست، یک میله مفصلی را عمود نگه دارد. یک عامل هوش مصنوعی یک کنترل‌کننده (برنامه‌ای که وضعیت سیستم را در هر تیک ۱۰ میلی‌ثانیه‌ای می‌خواند) برای حل این مسئله نوشت. Plimsoll این کد را در مقابل یک شبیه‌ساز که به WebAssembly کامپایل شده و در Image سندباکس قرار داشت، اجرا کرد. کنترل‌کننده تنها فایلی بود که فراخوان‌کننده از طریق API معمولی پروژه ارسال کرد و در لایه کانتینر اجرا شد.

وقتی اولین پیش‌نویس عامل شکست خورد و میله در ثانیه ۵.۹۶ افتاد، سیستم یک «اثرانگشت» (Fingerprint) منحصر‌به‌فرد تولید کرد؛ یعنی هش SHA-256 از تمام مسیر حرکت (هر وضعیت در هر تیک). چون اثرانگشت‌های یکسان به معنای اعداد یکسان هستند، این یک دلیل ریاضی برای اثبات عملکرد است. وقتی نسخه اصلاح‌شده موفق شد، اثرانگشت تغییر کرد.

Image شبیه‌سازی Plimsoll شامل هشت شبیه‌ساز برای اجرای کنترل‌کننده‌ها است: دوش (shower)، مبدل کاهنده (buck converter - یک منبع تغذیه که ولتاژ را با قطع و وصل کردن کاهش می‌دهد)، جهت کشتی (ship heading)، مدار سیاهچاله، راکت نسبیتی، ساعت ماهواره‌ای، شکاف دوگانه و نوسان عربه-میله. برای مثال، یک کنترل‌کننده buck converter که به زبان C نوشته و در سندباکس به WebAssembly کامپایل شده، می‌تواند تست شود تا ببینیم آیا در هنگام تغییرات ناگهانی بار، منبع تغذیه را روی ۵ ولت نگه می‌دارد یا خیر. چون این کد هیچ تابع کتابخانه‌ای را صدا نمی‌زند، مسیر حرکت آن در هر چهار سناریو، بایت به بایت با نسخه JavaScript یکسان است.

دسترسی امن به API از طریق بروکر

Plimsoll مشکل نشت اعتبارنامه‌ها (Credential Leak) را با این تضمین حل می‌کند که کد نوشته شده توسط عامل هرگز کلید API، آدرس API یا دسترسی باز به شبکه را در اختیار نداشته باشد. یک اجرا بدون «مجوز» (Grant)، هیچ دسترسی شبکه‌ای ندارد. به‌جای دادن دسترسی شبکه به سندباکس، Plimsoll از یک سیستم بروکر (Broker) استفاده می‌کند:

۱. کاربر یک «مجوز» تعریف می‌کند که به یک اجرا اجازه می‌دهد مسیرهای لیست شده از یک API خاص را صدا بزند.
۲. کد، یک کلاینت کوچک ارائه شده توسط Plimsoll را در داخل سندباکس صدا می‌زند.
۳. بروکر (بخشی از Plimsoll در خارج از سندباکس که تماس واقعی را برقرار می‌کند) درخواست را رهگیری کرده، هویت فراخوان و مسیر دقیق را تأیید می‌کند و سپس اعتبارنامه را خودش اضافه می‌کند.
۴. اعتبارنامه برای هر اجرا صادر می‌شود؛ Plimsoll برای هر اجرا یک بار آن را درخواست می‌کند، بنابراین می‌تواند یک توکن کوتاه‌مدت و تازه باشد و هرگز وارد سندباکس نمی‌شود.

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

ادغام با چارچوب‌های عامل‌محور

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

• Vercel AI SDK: ادغام از طریق @plimsollmark/client/ai-sdk.
• Google ADK: پشتیبانی از طریق plimsoll-client[adk] برای فایل‌های ورودی، مصنوعات خروجی و رد درخواست‌های زیر حد امنیتی.
• Agno و CrewAI: کلاینت‌های مبتنی بر پایتون از طریق plimsoll-client[agno] و plimsoll-client[crewai] برای گردش‌کارهای عامل‌محور.
• Trigger.dev و Mastra: پشتیبانی از TypeScript از طریق @plimsollmark/client/trigger و @plimsollmark/client/mastra برای اجراکننده‌های شغلی میزبانی شده.

برای Trigger.dev، افزونه TypeScript یک ابزار executeCode فراهم می‌کند. این قابلیت در واقع مکمل پیاده‌سازی‌های پیشین است که در آن Plimsoll با ایجاد محیط ایزوله، اجرای امن کد پایتون را به عامل‌های Trigger.dev اضافه کرد. در یک نشست (Session)، یک سندباکس برای چندین فراخوان باز می‌ماند؛ هر فراخوان یک «سلول» (Cell) است که در آن متغیرها و فایل‌ها زنده می‌مانند. هر نتیجه ابزار گزارش می‌کند که آیا فراخوان تازه شروع شده، از چه لایه جداسازی استفاده شده و رسید SHA-256 رکورد اجرا چیست. یک استارتر Trigger.dev قابل استقرار می‌تواند بدون نیاز به فراخوانی مدل هوش مصنوعی، ثابت کند که دو سلول از یک مفسر مشترک از طریق یک دیمون واقعی استفاده می‌کنند.

جزئیات فنی و مکانیسم‌ها

اجرای جداسازی (Isolation Enforcement)

• کف امنیتی (The Floor): یک درخواست می‌تواند MinimumIsolation را تعیین کند (مثلاً sandbox.IsolationVM). اگر دیمون نتواند این سطح را فراهم کند، قبل از اجرای هر کدی، اجرا را رد کرده و خطای ErrInsufficientIsolation برمی‌گرداند. این یعنی هیچ کدی اجرا نشده است.
• دلیل عدم اجرا (NotDispatchedReason): این تابع علامتی را روی ردها می‌خواند تا تعیین کند چرا هیچ چیز اجرا نشد. دلایل شامل: درخواست (request)، مجوز (permission)، پروتکل (protocol)، پشتیبانی نشده (unsupported)، جداسازی (isolation)، محیط (environment) یا ظرفیت (capacity) است.
• امنیت تکرار (Retry Safety): خطاهایی که علامت «عدم اجرا» ندارند، ممکن است بعد از شروع کد رخ داده باشند، بنابراین هرگز ایمن نیستند که به‌طور خودکار تکرار شوند.
• شناسه‌های درخواست (Request IDs): یک علامت تنها زمانی معتبر است که پاسخ، شناسه درخواست کلاینت را بازگرداند تا از ارسال پاسخ یک درخواست برای درخواست دیگر توسط یک پروکسی جلوگیری شود.
• شواهد در برابر گواهی (Evidence vs Attestation): لایه جداسازی، شواهدی است که از تنظیمات و بررسی‌های استارت‌آپ جمع‌آوری شده است و یک گواهی رمزنگاری‌شده سخت‌افزاری (Cryptographic Attestation) نیست.

جزئیات ارائه‌دهندگان (Provider Specifics)

• OpenShell: از محیط اجرای سندباکس عامل‌های NVIDIA استفاده می‌کند. هر اجرا یک سندباکس بدون شبکه دریافت می‌کند؛ Plimsoll تنظیمات را بازخوانی کرده و در صورت هرگونه تفاوت، اجرا را رد می‌کند. مجوزها از طریق یک رله در داخل سندباکس به بروکر می‌رسند، بنابراین سندباکس به قوانین شبکه نیاز ندارد. این مورد در ۲۸ سپتامبر ۲۰۲۶ روی gateway v0.1.2 تست شد.
• Docker Cloud: از دو API پشتیبانی می‌کند. API پیش‌فرض (قبل از عرضه) از مجوزها و شواهد Image پشتیبانی می‌کند. API REST مستند شده یک جایگزین است که مجوز ندارد، تحت PLIMSOLL_HARDENED=1 رد می‌شود و حداکثر زمان اجرای آن ۲۷۰ ثانیه است.
• Seccomp: ارائه‌دهنده داکر می‌تواند یک پروفایل seccomp را اعمال کند؛ لیستی از تنها تماس‌های سیستمی (مانند باز کردن فایل) که کانتینرهای آن مجازند به هسته ارسال کنند.
• ارائه‌دهنده Wasm: جاوااسکریپت را روی QuickJS کامپایل شده به WebAssembly در داخل پردازش شما اجرا می‌کند. برای اجرای مثال‌های حداقلی، به دیمون، داکر یا شبکه نیاز ندارد.

حسابرسی امنیتی و CI
Plimsoll در حال حاضر در نسخه پیش از ۱.۰ است، توسط یک نویسنده توسعه یافته و هیچ کاربر خارجی ندارد. تغییرات ساختاری (Breaking Changes) عمداً بدون مسیر جایگزینی (Deprecation Path) اعمال می‌شوند. هیچ حسابرسی امنیتی شخص ثالثی تا به حال انجام نشده است. پروژه از یک گردش‌کار حسابرسی سه مرحله‌ای استفاده می‌کند:
۱. audit: اجرای make audit (شامل بیلد، vet، تست‌های race، lint، buf lint، بررسی انحراف کد تولید شده و govulncheck).
۲. clients: اجرای make clients-suite برای پکیج‌های TypeScript و Python در حالت مورد نیاز. نبود محیط اجرا یا وابستگی باعث شکست شغل می‌شود.
۳. audit-docker: اجرای make docker-suite برای اثبات Read-only بودن ریشه و مانت‌های writable با اندازه مشخص و noexec تحت runc با پروفایل seccomp.

گردش‌کار gvisor همین مجموعه را تحت runsc از نصب‌کننده پین شده اجرا می‌کند. تشخیص‌دهنده race در شغل audit معمولی و هر دو شغل docker-suite اجرا می‌شود. هیچ بررسی‌ای روی E2B یا Docker Cloud Sandboxes انجام نمی‌شود، زیرا این‌ها سرویس‌های پولی زنده هستند.

زمینه اضافی و پیاده‌سازی

مدیریت نشست‌ها (Session Management)
نشست‌ها، سندباکس تازه در هر فراخوان را فدای سرعت و تداوم وضعیت (State Persistence) می‌کنند. کد یک فراخوان قبلی می‌تواند آنچه فراخوان‌های بعدی می‌بینند را تغییر دهد. برای استفاده از دسترسی API در یک نشست، مجوز باید صراحتاً اجازه نشست‌ها را بدهد. یک نشست نشان‌دهنده یک دامنه اعتماد (Trust Domain) است که به فراخوان احراز هویت شده متصل است. سرویس‌هایی که کد را برای چندین مشتری اجرا می‌کنند، باید هر مشتری را در نشست خود ایزوله کنند تا از نشت داده‌های بین مستاجران (Cross-tenant data leakage) جلوگیری شود.

استقرار و پیکربندی (Deployment and Configuration)
حالت پیش‌فرض Plimsoll ارائه‌دهنده Disabled است که هیچ چیز را اجرا نمی‌کند تا تضمین شود اجرای کد هرگز به‌طور تصادفی فعال نمی‌شود. برای انتقال از لایه Process به لایه Kernel، کاربران می‌توانند sudo ./docker/install-gvisor.sh را برای نصب یک نسخه پین شده از gVisor و ثبت runtime runsc در داکر اجرا کنند. این کار اجازه می‌دهد همان کد کلاینت با تغییر متغیر محیطی SANDBOX_DOCKER_RUNTIME با جداسازی بالاتر اجرا شود.

تحلیل عملکرد (Performance Analysis)
Plimsoll شامل یک مشاور بهره‌وری (Efficiency Advisor) است که تماس‌های API را در طول یک اجرا تحلیل می‌کند. این ابزار الگوهای اتلافی را شناسایی می‌کند؛ مثلاً وقتی یک عامل یک سؤال مشابه را در ۱۳ فراخوان مجزا می‌پرسد در حالی که یک مسیر (Route) واحد می‌توانست پاسخ را بدهد. برای حفظ حریم خصوصی، سوابق مشاور هرگز شامل داده‌های واقعی ارسالی یا دریافتی نیست و فقط الگوها و مسیرهای استفاده شده را ثبت می‌کند.

تحلیل: تغییر مدل اعتماد

Plimsoll بار امنیتی را از ارائه‌دهنده به قرارداد منتقل می‌کند. با اجازه دادن به یک درخواست برای تعیین MinimumIsolation: sandbox.IsolationVM، توسعه‌دهنده یک محدودیت سخت ایجاد می‌کند: اگر سیستم نتواند یک VM فراهم کند، کد به‌سادگی اجرا نمی‌شود.

برای یک توسعه‌دهنده عملی، این بدان معناست که می‌توانید به‌صورت محلی از لایه سریع process (از طریق ارائه‌دهنده wasm) استفاده کنید اما در محیط عملیاتی، یک کف اجباری kernel یا vm را بدون تغییر حتی یک خط از منطق عامل اعمال کنید. این امر امنیت را از یک مورد در چک‌لیست به یک الزام زمان اجرا (Runtime Requirement) تبدیل می‌کند.

این معماری به‌طور مؤثری با کدهای تولید شده توسط هوش مصنوعی به‌صورت پیش‌فرض به عنوان یک محموله خصمانه (Hostile Payload) برخورد می‌کند. با جداسازی اعتبارنامه از محیط اجرا از طریق بروکر، Plimsoll رایج‌ترین بردار حمله در گردش‌کارهای عامل‌محور — یعنی سرقت متغیرهای محیطی از یک سندباکس متلاشی شده — را حذف می‌کند.