تصور کنید یک عامل هوش مصنوعی دسترسی به ترمینال سیستم شما دارد و در لحظه‌ای از توهم، دستوری برای پاک‌سازی کل دایرکتوری ریشه صادر می‌کند. در Talos (نسخه ۰.۱۵.۱-آلفا)، چنین اتفاقی هرگز رخ نمی‌دهد چون یک هسته‌ی امنیتی تعیین‌گر (Deterministic Kernel) دقیقاً بین مدل و شل سیستم قرار گرفته است. این فریم‌ورک یک عامل طراحی شده است تا از خطاهای خودمختار جلوگیری کند.
این سامانه تضمین می‌کند هیچ فراخوانی ابزاری بدون مجوز فردی که به آرگومان‌های دقیق متصل است، اجرا نشود. هر اثر یا تغییر در سیستم به‌صورت مجزا تأیید شده و اعتبار آن تنها ۳۰ ثانیه است.
بیشتر عامل‌های هوش مصنوعی ابتدا برای قدرت ساخته می‌شوند و ترمزها تنها زمانی اضافه می‌شوند که مدل توانایی انجام کارهای پیچیده را ثابت کند. Talos این منطق را وارونه کرده است. این فریم‌ورک که نامش را از غول برنزی کرت گرفته است — غولی که با خارج کردن یک میخ تک از یک رگ متوقف شد — به‌گونه‌ای طراحی شده که در عین قدرت، به‌سادگی قابل توقف باشد. در واقع، این سیستم با هوش مصنوعی مانند بازیگری برخورد می‌کند که احتمال خطا در آن بالاست و نیازمند یک دروازه‌ی قابل‌راستی‌سنجی است تا تصمیم بگیرد عملیاتی اجازه اجرا دارد، رد شود یا نیاز به دخالت انسانی دارد. این رویکرد یادآور مکانیزم‌های GuardRail برای کنترل دسترسی عامل‌هاست که پیش از این برای جلوگیری از حذف داده‌های محیط عملیاتی بررسی شده بود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف اعتماد مطلق به مدل، تنها راه رسیدن به پایداری در محیط‌های عملیاتی است. به نقل از مستندات talos-agent.ch، این سیستم بر اصل «رد به‌صورت پیش‌فرض» (Deny by Default) استوار است. هر اثر باید در یک مانیفست تعریف شده باشد؛ اگر ابزاری سعی کند عملیاتی خارج از این لیست انجام دهد، هسته فوراً آن را رد می‌کند. این یک فرآیند تعیین‌گر است؛ چرا که ترمزهایی که نیاز به «فکر کردن» داشته باشند، ترمز نیستند و مدلی که دچار توهم (Hallucination) — شبیه دوستی که خاطره را اشتباه تعریف می‌کند — شده باشد، نمی‌تواند برای جلوگیری از خاموش شدن خودش مورد اعتماد باشد.
معماری امنیتی
این فریم‌ورک از یک خط لوله چندمرحله‌ای برای پردازش دستورات استفاده می‌کند: کف مسیر $ \rightarrow $ خط سخت $ \rightarrow $ خطرناک $ \rightarrow $ اثر. این ساختار تضمین می‌کند اقدامات پرخطر پیش از رسیدن به سیستم علامت‌گذاری شوند. برای ابزارهای مدیریت فایل، این لایه‌ها حتی دقیق‌تر و دانه‌بندی‌شده‌تر هستند: کف سیستم، هویت، اسرار، پایداری و در نهایت اثر. در این راستا، بهینه‌سازی مدیریت وضعیت فایل‌سیستم اهمیت ویژه‌ای دارد، مشابه آنچه در پروژه Shepherd برای کاهش هزینه بازگردانی وضعیت پیاده‌سازی شد.
مشخصات فنی کلیدی عبارتند از:
- دروازه‌ی تعیین‌گر: یک هسته‌ی مبتنی بر پایتون (فایل‌های
policy.pyو تابع_decide_exec) که بدون استفاده از مدل زبانی تصمیم می‌گیرد. این کار مانع از آن می‌شود که توهمات مدل، امنیت را دور بزنند. - سندباکسینگ (Sandboxing): یکپارچگی با bubblewrap در لینوکس و sandbox-exec در مک. در محیط‌هایی که هیچ‌کدام از این ابزارها وجود ندارند، سیستم به‌جای اجرای بدون حفاظ، کلاً از اجرا خودداری می‌کند.
- ابزارهای سخت‌گیرانه: مانیفستی شامل ۲۳ ابزار، که به ۱۵ عملیات خواندنی، ۵ نوشتنی و ۳ اجرایی تقسیم شده‌اند. هسته رفتار ابزار را حدس نمی‌زند و صرفاً به مانیفست تکیه می‌کند.
- کنترل هویت: هیچ لیست سفید پیش‌فرضی وجود ندارد. متغیر
TALOS_ALLOWED_PRINCIPALSباید دستی تنظیم شود تا نام یک هویت مورد اعتماد در آن قرار گیرد؛ زیرا وجود یک مقدار پیش‌فرض در کد ارسالی، به معنای ایجاد یک در پشتی (Backdoor) در سورس کد است. - توکن‌های تک‌بار مصرف: هر توکن عمری ۳۰ ثانیه‌ای دارد و فقط برای یک‌بار استفاده معتبر است.
قابلیت‌های عملیاتی
با وجود این محدودیت‌ها، Talos می‌تواند گردش‌های کاری پیچیده را مدیریت کند. این سیستم می‌تواند وظایف کدنویسی محدود شده را به یک عامل Claude محصور شده بسپارد که کدها را در یک فضای کاری یک‌بار مصرف (Disposable Workspace) که از هسته مشتق شده است، می‌سازد و تست می‌کند. اگر عامل به مرورگر نیاز داشته باشد (browser: true)، آن را در همان سندباکس اجرا می‌کند.
زمانی که یک شغل تفویض‌شده به پایان برسد، با خطا مواجه شود یا زمان آن تمام شود (Timeout)، چت اصلی یک «پوش تکمیل» (Completion Push) دریافت می‌کند. این پیام کوتاه و واقع‌گرایانه است که از رکورد عامل ساخته شده و برای حفظ دقت، به‌طور مشخص از نثر مدل‌های زبانی پرهیز می‌کند.
ارتباطات از طریق چهار کانال ترمینال، تلگرام، ایمیل IMAP و واتس‌اپ (از طریق یک بروکر تحت کنترل اپراتور روی SSH) مدیریت می‌شود. برای کاهش سطح حمله، سیستم هرگز سوکت شنونده (Listening Socket) باز نمی‌کند و فقط داده‌ها را می‌گیرد (Fetch). برای مثال، تلگرام از طریق long-poll و ایمیل‌ها از طریق IMAP فراخوانی می‌شوند. ایمیل‌های تأییدنشده با رویکرد «اعتماد فقط با پرسش» (Ask-only trust) برخورد می‌شوند.
برای اتوماسیون، سیستم از «بلوپرینت‌هایی» (Blueprints) با زبان ساده استفاده می‌کند. این‌ها جایگزین سینتکس سنتی cron شده‌اند و به کاربر اجازه می‌دهند وظایفی مثل «هر روز ساعت ۸:۳۰ صبح» را زمان‌بندی کنند، در حالی که همچنان تحت همان سقف امنیتی دستورات دستی هستند.
مکانیزم‌های کنترل
Talos دستورات کنترلی مستقیمی دارد که مدل زبانی را کاملاً دور می‌زنند:
/stop: متوقف کردن فوری تفکر جاری و پاک‌سازی صف./undo: بازگرداندن آخرین تغییر موفق در فایل‌ها./autonomy 0: کوتاه کردن زنجیره اختیار به صفر و افزودن لایه‌ای از رد بر روی سطوح موجود./log: نمایش آخرین رویدادهایی که اثر گذاشته‌اند؛ این رویدادها پیش از وقوع اثر ثبت می‌شوند، نه پس از آن.
اعتماد قابل‌راستی‌سنجی
طبق گزارش توسعه‌دهندگان، Talos به‌جای صفت‌های تبلیغاتی، بر اثبات بازتولیدپذیر تکیه دارد. نصب‌کننده پیش از شروع به کار عامل، مجموعه‌ای از ۲,۰۶۳ تست واحد (Unit Test) و ۱۷۹ مورد خصمانه (Adversarial) را مقابل چشم کاربر اجرا می‌کند. این تست‌های خصمانه توانایی هسته در بازگرداندن حکم DENY برای مسیرهای محافظت‌شده را می‌سنجند؛ برای مثال تلاش برای اجرای cat ~/.secrets/talos-telegram.env یا echo pwned >> /etc/sudoers باید رد شود.
احکام دیگر شامل ASK برای دستورات ریسکی (مثل rm -rf ~/talos/scratch یا نوشتن در ~/.bashrc) و ALLOW برای کارهای عادی (مثل read ~/talos/README.md) است.
این رویکرد پارادایم عامل‌محور را از «اعتماد به مدل» به «اعتماد به دروازه» تغییر می‌دهد. با حذف مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — از فرآیند تصمیم‌گیری هسته امنیتی، تضمین می‌شود که یک مدل دچار توهم نمی‌تواند مانع خاموش شدن خود شود یا پیوست‌های غیرمجاز بسازد. حجم پیوست‌های رسانه‌ای به ۲۰ مگابایت و حداکثر ۴ فایل محدود شده است و این فایل‌ها فقط از ریشه‌های هسته مشتق می‌شوند.
برای پیاده‌سازی، این سیستم به پایتون ۳.۱۱ به بالا و Claude Code CLI نیاز دارد و به‌قدری سبک است که روی رزبری‌پای اجرا شود. نصب‌کننده تمام ادعاها را اثبات می‌کند — با اجرای مجموعه‌های تست واحد و خصمانه — و سپس هیچ‌چیز را اجرا نمی‌کند. کاربر باید به‌صورت دستی کلید شروع را بزند تا عملیات آغاز شود.
گام بعدی شما
- اگر از عامل‌های خودکار در محیط توسعه استفاده می‌کنید، معماری «رد پیش‌فرض» Talos را برای مدیریت دسترسی‌های فایل بررسی کنید.
- تست‌های خصمانه (Adversarial Tests) را در خط لوله CI/CD عامل‌های خود بگنجانید تا نقاط ضعف امنیتی را پیش از استقرار بیابید.
- برای کاهش سطح حمله، مدل‌های ارتباطی Pull-based (مانند IMAP) را جایگزین Webhookهای باز کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو