Red Hat یک sandbox برای عامل‌های OpenClaw معرفی کرده است، همان‌طور که SiliconANGLE گزارش داده است. این اقدام جداسازی runtime را مستقیماً در خط محصول فروشنده قرار می‌دهد، به‌جای آنکه به اپراتورها واگذار شود تا خودشان container و policy را پیکربندی کنند. Dell، در همان رسانه، guardrail عامل‌های AI را مسیر رسیدن به خودمختاری بیشتر می‌داند: استدلال این است که مهار tighter همان چیزی است که اقدام واگذارشده گسترده‌تر را قابل‌قبول می‌کند. Sophos نیز به‌طور جداگانه کاری درباره کنترل دسترسی مبتنی بر intent برای عامل‌های AI منتشر کرده است که نقطه تصمیم را از allow-listهای ایستا به هدف اعلام‌شده یک فراخوانی منتقل می‌کند.
در کنار هم، این سه مورد بازاری را توصیف می‌کنند که بر مهار به‌عنوان یک پیش‌فرض قابل‌خرید همگرا می‌شود. این مفید است، اما ارزش دارد دقیق باشیم درباره اینکه یک sandbox واقعاً چه چیزی را محدود می‌کند. جداسازی runtime محدود می‌کند که کد درون host به چه چیزی می‌تواند دسترسی داشته باشد و بسته به پیاده‌سازی، کدام syscallها و فایل‌سیستم‌ها قابل مشاهده‌اند. اما به‌خودی‌خود مسیر egress را توصیف نمی‌کند: عامل می‌تواند داده را کجا بفرستد، کدام endpointها را می‌تواند فراخوانی کند، و آیا ترافیک خروجی فیلتر، ثبت و قابل‌انتساب است یا نه. همچنین credentialهایی که عامل در اختیار دارد را توصیف نمی‌کند. یک فرایند sandboxشده با یک token گسترده همچنان می‌تواند با اختیار کامل آن token در برابر هر سرویس قابل‌دسترسی عمل کند.
کنترل دسترسی مبتنی بر intent پاسخی جزئی به مسئله دوم است، چون مجوزدهی را به هدف اعلام‌شده گره می‌زند نه فقط به هویت. پرسش‌های باز یکپارچه‌سازی و اجرا هستند: اینکه چنین کنترل‌هایی در runtime عامل، در gateway یا در ارائه‌دهنده هویت قرار می‌گیرند، و چگونه intent اثبات می‌شود نه صرفاً ادعا. پوشش ارائه‌شده مکانیزم جداسازی Red Hat، معماری مرجع Dell یا نقطه اجرای Sophos را مشخص نمی‌کند.