نسخه 2026.9.2 از OpenClaw یک تغییر مهم در نحوه اعتماد میان عاملها ایجاد کرده است. در این نسخه، دسترسی معمول عاملها به نشست یکدیگر بهصورت پیشفرض فعال شده و ابزارهای مربوط به نشستها میتوانند همه نشستهای یک Gateway را ببینند. قابلیت آزمایشی Swarm برای هماهنگکردن چند عامل نیز بهطور پیشفرض فعال است.
این تغییر به معنای کشف یک رخنه امنیتی نیست. خود OpenClaw صریحاً میگوید هر Gateway باید یک محدوده اعتماد واحد در نظر گرفته شود و کاربران یا گروههایی که به یکدیگر اعتماد ندارند نباید یک Gateway مشترک داشته باشند. با این حال، اگر سازمانی تا امروز شخصیتهای مختلف عامل را مرز محرمانگی فرض کرده باشد، پس از این بهروزرسانی باید تنظیماتش را دوباره بررسی کند.
نشستهای عاملها حالا بهطور پیشفرض در یک محدوده مشترک دیده میشوند
یادداشت انتشار ۵ سپتامبر میگوید ابزارهای نشست اکنون بهصورت پیشفرض همه نشستها را میبینند و ارتباط عادی میان عاملها نیز فعال است. مستندات امنیتی OpenClaw این رفتار را دقیقتر توضیح میدهد: مقدار پیشفرض tools.sessions.visibility برابر all و مقدار پیشفرض tools.agentToAgent.enabled برابر true است.
طبق همین مستندات، عاملی که بیرون از محیط ایزوله اجرا میشود و به ابزارهای نشست دسترسی دارد، میتواند نشستهای همه عاملها را فهرست کند، بخواند، جستوجو کند یا برای آنها پیام بفرستد؛ حتی متن گفتوگوهای کاربران دیگر نیز در این محدوده قرار میگیرد. عاملهای ایزوله هنگام دسترسی از داخل، همچنان به شاخهای که خودشان ایجاد کردهاند محدود میمانند، اما این محدودیت باعث نمیشود متن نشست آنها از دید یک عامل غیرایزوله پنهان شود.
OpenClaw این رفتار را جداسازی چند مستأجر مستقل نمیداند. در مدل امنیتی پروژه، دسترسی مدیریتی به یک Gateway نقشی قابل اعتماد است. برای محیطهایی با سطح اعتماد متفاوت، توصیه رسمی استفاده از Gateway و اعتبارنامه جدا و در صورت امکان کاربر سیستمعامل یا میزبان جداست.
بنابراین پرسش درست این نیست که آیا نسخه جدید «مجوزها را دور میزند». چنین ادعایی با مستندات سازگار نیست. پرسش مهم این است که آیا ساختار واقعی اعتماد در سازمان با محدودهای که OpenClaw برای یک Gateway فرض میکند همخوان است یا نه.
Swarm کار را بین عاملها پخش میکند، اما مجوز تازهای نمیدهد
در همین نسخه، Swarm نیز بهصورت پیشفرض فعال شده است. این قابلیت آزمایشی برای اجرای همزمان چند زیرعامل طراحی شده و نتیجه ساختیافته، محدودیت همزمانی و گزارش پیشرفت دارد. استفاده از آن از طریق Code Mode یا ابزارهای سطح پایینتر نشست امکانپذیر است.
مستندات چند محدودیت مهم را روشن میکند. Code Mode همچنان جداگانه باید فعال شود. سیاست ابزارها، فهرستهای مجاز، قواعد ارائهدهنده و محدودیتهای محیط ایزوله پابرجا هستند. روشنشدن Swarm ابزاری را که قبلاً مجاز نبوده به عامل اضافه نمیکند. همچنین زیرعاملهای جمعآوریکننده اگر برای یک اقدام به تأیید تعاملی کاربر نیاز داشته باشند، آن اقدام را رد میکنند.
در نتیجه دو تغییر نسخه را باید از هم جدا دید. Swarm ظرفیت تقسیم و هماهنگی کار را بیشتر میکند؛ تنظیمات نشست تعیین میکند هر عامل چه گفتوگوها و زمینهای را میتواند ببیند. کنار هم قرارگرفتن این دو، طراحی اعتماد در سامانههای چندعاملی را مهمتر میکند.
مرز واقعی اعتماد، Gateway است نه نام هر عامل
برداشت عملی Aipolix این است که صرف داشتن شخصیت یا شناسه جدا برای هر عامل، محرمانگی ایجاد نمیکند؛ مگر اینکه تنظیمات نیز این جدایی را اعمال کنند.
فرض کنید یک Gateway میزبان دستیار شخصی، عامل مالی و عامل مهندسی است. اگر دادهها یا کاربران این سه نقش سطح اعتماد یکسانی ندارند، جداکردن دستورهای عامل و محدوده ابزارها بهتنهایی کافی نیست. مستندات OpenClaw میگوید تنظیمات معمول ابزارها دامنه دسترسی ابزارهای نشست را محدود نمیکند و عامل غیرایزوله در حالت پیشفرض میتواند نشست یک عامل ایزوله را نیز بخواند.
برای نقشهایی که واقعاً به یکدیگر اعتماد دارند، تنظیم پیشفرض میتواند انتخابی راحت و آگاهانه باشد. اما اگر سطح اعتماد متفاوت است، خود پروژه پیشنهاد میکند tools.sessions.visibility روی agent یا self قرار گیرد، ارتباط میان جفتهای عامل با tools.agentToAgent.allow محدود شود یا ارتباط مستقیم عاملها کاملاً خاموش شود. برای کاربران متخاصم یا مستأجران مستقل، راهکار پیشنهادی Gateway جداست.
این نگاه برای معماری مهمتر از فرضکردن هر عامل بهعنوان یک مرز امنیتی مستقل است. پس از این نسخه، معمار سامانه باید هر Gateway را به یک محدوده واقعی اعتماد در سازمان نگاشت کند.
بهروزرسانی باید با بازبینی محدوده اعتماد همراه باشد
چون این رفتار بهعنوان تنظیم پیشفرض نسخه جدید عرضه شده، بررسی بهروزرسانی نباید فقط به امکانات تازه محدود شود. تیمهایی که چند عامل یا چند کاربر را روی یک Gateway دارند باید دسترسی مؤثر به نشستها را پیش و پس از ارتقا مقایسه کنند.
سه سؤال برای این بازبینی کافی است: کدام عاملهای غیرایزوله میتوانند ابزارهای نشست را اجرا کنند؟ آیا میان آنها نقشهایی با داده، کانال یا کاربرانی با انتظار محرمانگی متفاوت وجود دارد؟ و آیا این نقشها اصولاً باید یک Gateway مشترک داشته باشند؟
ابزار openclaw security audit نیز اکنون دسترسی میان نشستهای عاملها را بررسی میکند و زمانی که دید سراسری نشستها با نشانههایی مانند ایزولهسازی، محدودیتهای متفاوت عاملها یا ورود کاربران متعدد همراه باشد، هشدار میدهد.
مدرکی از سوءاستفاده یا دورزدن کنترلها در دست نیست. محدودیت ابزار و محیط ایزوله همچنان برقرار است و OpenClaw مدل «یک محدوده اعتماد برای هر Gateway» را آشکارا مستند کرده است. اهمیت نسخه 2026.9.2 در همین تغییر معماری است: وقتی اشتراک زمینه میان عاملها گستردهتر میشود، طراحی اعتماد باید بخشی از تصمیم بهروزرسانی باشد.