Styx با مکانیزم تایید بیومتریک مانع استقرار تصادفی عامل‌های کدنویس در محیط

یک پرچم اشتباه مانند --prod می‌تواند پیش از آنکه برنامه‌نویس متوجه شود، کل دیتابیس عملیاتی شرکت را پاک کند. Styx که در ۱۳ اکتبر ۲۰۲۶ منتشر شد، با قرار دادن یک لایه تایید انسانی اجباری بین عامل‌های هوش مصنوعی و اهداف استقرار، این ریسک را به صفر می‌رساند.

بسیاری از عامل‌های کدنویس — مثل Claude Code، Gemini CLI، Codex و Cursor — تمام دسترسی‌های کاربر را به ارث می‌برند. آن‌ها با همان PATH، فایل‌ها و CLIهای لاگین شده‌ی کاربر شروع به کار می‌کنند. این یعنی اگر شما یک بار در ترمینال خود دستورات vercel login یا gcloud auth login یا supabase login را اجرا کرده باشید، عامل هوش مصنوعی هم دقیقاً همان دسترسی‌ها را دارد. مشکل اینجاست که این عامل‌ها نمی‌توانند تفاوت بین vercel deploy و vercel deploy --prod را درک کنند، یا تشخیص دهند که یک دستور supabase db push قرار است روی یک پروژه آزمایشی اجرا شود یا روی دیتابیس زنده‌ای که هزاران کاربر واقعی در حال استفاده از آن هستند. این موضوع یک شکاف امنیتی عظیم ایجاد می‌کند. در این راستا، مدیریت دقیق لایه‌های اجرایی در ابزارهایی مانند Claude Code برای مهار هزینه‌ها و رفتارهای عامل‌های فرعی اهمیت ویژه‌ای یافته است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، اعتماد کورکورانه به ابزارهای خودکار در محیط‌های حساس، بزرگ‌ترین نقطه ضعف فعلی است. Styx به‌جای ایجاد یک محیط ایزوله یا سندباکس (Sandbox) — که شبیه به یک اتاق آزمایش امن است تا هیچ اتفاقی به بیرون سرایت نکند — به عنوان یک حفاظ (Guardrail) عمل می‌کند. این ابزار اجازه می‌دهد عامل فایل‌ها را بخواند، اما هرگاه بخواهد وضعیت دنیای واقعی را تغییر دهد، مسیرش را سد می‌کند. این رویکرد نرم‌افزاری مکمل راهکارهای سخت‌افزاری است، مشابه آنچه در سیستم‌های Cognous برای انتقال حفاظ‌ها به لایه‌ی سخت‌افزار برای مهار عامل‌های خودمختار دیده‌ایم. این پروژه تحت لایسنس Apache-2.0 منتشر شده است.

سازوکار شیم و بروکر

طبق مستندات فنی Styx، این ابزار مجموعه‌ای از اسکریپت‌های کوچک به نام «شیم» (Shim) را در ابتدای مسیر اجرای دستورات (PATH) عامل قرار می‌دهد. این شیم‌ها دستوراتی مثل vercel، gh، aws، gcloud، supabase و ssh را پوشش می‌دهند. وقتی عامل سعی می‌کند دستوری مثل supabase db push را اجرا کند، به‌جای اجرای فایل باینری اصلی، ابتدا با اسکریپت Styx برخورد می‌کند.

به‌عنوان مثال، شیم Vercel (که در فایل shim-service.ts تعریف شده) از یک اسکریپت شل برای اجرای دستور زیر استفاده می‌کند: exec env ELECTRON_RUN_AS_NODE=1 "$STYX_EXE" "$STYX_CLI" wrap vercel "$@". این دستور styx wrap به یک بروکر (Broker) محلی متصل شده، تابع exec_authorize را با ابزار مورد نظر، آرگومان‌ها و دایرکتوری کاری فراخوانی می‌کند و تا ۱۰ دقیقه منتظر پاسخ می‌ماند.

اگر پاسخ «بله» باشد، باینری اصلی با محیط (Environment) تایید شده اجرا می‌شود. در غیر این صورت، پیام styx: access to vercel was not granted چاپ شده و برنامه با کد خطای ۷۷ متوقف می‌گردد. پس از پایان فرآیند، شیم کد خروجی را به لاگ گزارش می‌دهد.

این بروکر در یک فرآیند اصلی Electron اجرا می‌شود و از طریق سوکت‌های یونیکس (در ویندوز از Named Pipe) در دایرکتوری با دسترسی 0700 با هر کاربر ارتباط می‌گیرد. هر جلسه (Session) با یک توکن منحصر‌به‌فرد که به صورت هش SHA-256 ذخیره شده و در زمان ثابت (Constant Time) مقایسه می‌شود، شناسایی می‌گردد. این سازوکار تضمین می‌کند که یک عامل نتواند تاییدیه عامل دیگر را برباید؛ هر اتصال فقط می‌تواند دسترسی‌های خودش یا دسترسی‌های همیشگی روی اهداف پروژه خودش را ببیند. همچنین برای جلوگیری از سوءاستفاده، تعداد درخواست‌های جدید به ۵ مورد در دقیقه برای هر جلسه محدود شده است.

تاییدات مبتنی بر سیاست

تصمیم‌گیری درباره تایید یا رد دستورات توسط یک تابع سیاست‌گذاری خالص در بسته packages/core انجام می‌شود. این موتور برای تضمین پایداری، تحت پوشش ۱۰۰٪ تست‌های CI قرار دارد و هیچ وابستگی به Electron، ورودی/خروجی (I/O) یا ساعت داخلی ندارد؛ زمان به عنوان یک پارامتر به آن پاس داده می‌شود.

این موتور درخواست‌ها را با استفاده از یک ساختار تابع خاص ارزیابی می‌کند: evaluate(input: { target: { id; provider; env; policy }; scope: Scope[]; session: { id; mayRequestTargets } | null; appRules: Policy[]; projectRules: Policy[]; persistentGrants: Grant[]; now: number; }). خروجی این تابع می‌تواند auto (خودکار)، ask (پرسش از کاربر) یا deny (رد) باشد که همراه با مقادیری مثل requireMfa (نیاز به تایید دو مرحله‌ای)، maxDuration (حداکثر مدت)، idleMs (زمان بیکاری) و یک policyId بازگردانده می‌شود.

این موتور سلسله‌مراتب سخت‌گیرانه‌ای را دنبال می‌کند:

• اجازه درخواست: اگر تسکی اجازه درخواست برای اهداف (Targets) را نداشته باشد، فوراً رد می‌شود.
• تاییدات پوششی: اگر یک تاییدیه «همیشه مجاز» (Always Grant) وجود داشته باشد، درخواست تایید می‌شود.
• سیاست هدف: اگر هدف روی حالت Always allow تنظیم شده باشد، تایید می‌گردد.
• قوانین سفارشی: قوانین تعریف شده توسط کاربر از بالا به پایین بررسی می‌شوند.
• پیش‌فرض: اگر هیچ قانونی منطبق نباشد، سیستم به حالت پیش‌فرض «پرسش» (Ask) می‌رود.

جزئیات دامنه و قوانین

بروکر دستور را تحلیل می‌کند تا دامنه (Scope) مورد نیاز را تعیین کند. دستوراتی مثل ls یا view به عنوان «خواندنی» (Read)، دستور deploy به عنوان «استقرار» و دستوراتی مثل delete یا drop به عنوان «حذفی» طبقه‌بندی می‌شوند. هر دستوری که شناسایی نشود، برای امنیت بیشتر به عنوان «نوشتنی» (Write) در نظر گرفته می‌شود تا هرگز کمتر از حد خطرناک تصور نشود.

قوانین سفارشی در فایلی به نام .styx/project.json تعریف می‌شوند. از آنجایی که هر کسی با دسترسی Commit می‌تواند این فایل را ویرایش کند، این قوانین فقط می‌توانند باعث شوند Styx «بیشتر» سوال بپرسد تا زمانی که کاربر آن‌ها را بپذیرد (یعنی نمی‌توانند محدودیت‌های امنیتی کلی را دور بزنند).

عامل‌ها همچنین می‌توانند از طریق یک ابزار MCP (پروتکل زمینه مدل) به نام request_access از پیش درخواست دسترسی کنند.

اگر موتور سیاست‌گذاری تصمیم ask را برگرداند، عامل مسدود می‌شود. کاربر یک اعلان سیستمی، یک درخواست در چتِ عامل و یک ورودی در صفحه Access دریافت می‌کند. کاربر می‌تواند عامل، هدف، دلیل و دامنه‌ها را ببیند. کاربر می‌تواند تیک برخی دامنه‌ها را بردارد تا دسترسی کمتری بدهد، اما نمی‌تواند هیچ دامنه‌ای را اضافه کند. تا زمانی که کاربر پاسخ ندهد، شیم مسدود می‌ماناند و عامل منتظر می‌ماند.

تایید بیومتریک برای محیط عملیاتی

برای اقدامات حساس در محیط Production، یک کلیک ساده کافی نیست. Styx از یک شرط به نام requiresMfa استفاده می‌کند که اگر محیط prod باشد و دامنه‌ها شامل هر یک از WRITE_SCOPES باشند، فعال می‌شود.

در این حالت، Styx از سیستم‌عامل می‌خواهد هویت کاربر را از طریق Touch ID در مک، Windows Hello در ویندوز یا polkit در لینوکس تایید کند. در مک‌هایی که حسگر ندارند یا درب لپ‌تاپ بسته است، سیستم به درخواست رمز عبور macOS بازمی‌گردد. اگر دستگاه اصلاً نتواند کاربر را تایید کند، Styx به‌جای نادیده گرفتن بررسی، دسترسی را به‌طور کامل رد می‌کند.

این سازوکار مانع از آن می‌شود که یک عامل هوش مصنوعی بتواند تایید کاربر را جعل کند. تاییدیه نهایی در فرآیند اصلی (Main Process) از طریق GrantService.approve تصمیم‌گیری می‌شود که نیاز به MFA را مجدداً از دیتابیس با منطق زیر محاسبه می‌کند: const needMfa = requiresMfa(target.env, scopes) || target.policy === 'ask-mfa' || decision.requireMfa || this.unscopedProd(target, scopes);. این یعنی پنجره سندباکسی که کاربر در آن کلیک می‌کند، هیچ قدرتی برای دور زدن این بررسی ندارد.

برای ارائه‌دهندگانی که نمی‌توانند اعتبارنامه‌ها را به یک دامنه خاص محدود کنند (مانند Vercel، Supabase، GitHub و SSH)، هرگونه دسترسی به هدف عملیاتی، حتی برای خواندن، نیاز به تایید بیومتریک دارد. در زمان توسعه، سوییچی به نام STYX_MFA=auto برای شبیه‌سازی اعلان‌های سیستم‌عامل در تست‌های End-to-End استفاده می‌شد؛ اما مشخص شد که نسخه‌های ریلیز هم این سوییچ را می‌پذیرند. بنابراین در نسخه‌های نهایی (Packaged builds)، این سوییچ نادیده گرفته می‌شود تا عامل‌ها نتوانند Styx را با فعال کردن آن مجدداً اجرا کنند.

چرخه حیات دسترسی‌ها

هر دسترسی شامل یک هدف، مجموعه‌ای از دامنه‌ها و یک مدت زمان است. مدت‌زمان‌های موجود عبارتند از:

• یک‌بار (Once): بلافاصله پس از استفاده یا بعد از یک ساعت منقضی می‌شود.
• یک ساعت (1h): پیش‌فرض سیستم است و یک ساعت پس از صدور منقضی می‌گردد.
• جلسه (Session): با پایان یافتن جلسه عامل منقضی می‌شود.
• همیشگی (Always): تا زمانی که کاربر دستی آن را لغو نکند باقی می‌ماند.

یک قانون داخلی هر دسترسی (به جز همیشگی) را پس از یک ساعت عدم فعالیت می‌بندد. چرخه حیات توسط یک جدول انتقال جامع مدیریت می‌شود که برای هر جفت از حالت و رویداد (حتی موارد نامعتبر) تست شده است. دسترسی‌های Session را می‌توان زودتر توسط کاربر لغو کرد.

جداسازی اعتبارنامه‌ها

Styx توکن‌های حساس مثل GH_TOKEN، VERCEL_TOKEN و AWS_SECRET_ACCESS_KEY را از محیط ارث‌بری شده‌ی عامل پاک می‌کند تا اسرار ذخیره شده در پروفایل شل به دست عامل نیفتد. به‌جای آن، اعتبارنامه‌ها را فقط برای مدت زمان اجرای همان دستور تزریق می‌کند.

• AWS: از اعتبارنامه‌های موقت STS با یک سیاست جلسه (Session Policy) محدود به دامنه‌های تایید شده استفاده می‌کند (مگر اینکه یک پروفایل CLI بدون نقش برای Assume متصل باشد).
• GCP: از توکن‌های دسترسی استفاده می‌کند که حداکثر یک ساعت اعتبار دارند.
• Vercel, Supabase, GitHub: این‌ها توکن ذخیره شده را دریافت می‌کنند زیرا ارائه‌دهندگان نمی‌توانند توکن‌های محدودتر صادر کنند.
• SSH: یک عامل SSH داخلی را در حافظه اجرا کرده و سوکت SSH_AUTH_SOCK دستور را به آن متصل می‌کند. سوکت بلافاصله پس از انقضای دسترسی بسته می‌شود.

اسرار در ذخیره‌سازهای رسمی سیستم‌عامل (Keychain، Credential Manager یا Secret Service) ذخیره می‌شوند و در دیتابیس و لاگ‌های Styx تنها ارجاعاتی مانند styx:v1:<provider>:<targetId>:<kind> وجود دارد. به‌طور پیش‌فرض، Styx برای دریافت توکن‌های جاری در هر دسترسی، از لاگین خودِ CLI ارائه‌دهنده استفاده می‌کند.

لاگ بازرسی تغییرناپذیر

تمام درخواست‌ها، تاییدها، ردها، استفاده‌ها، لغو‌ها و انقضاها در جدول audit_entries ثبت می‌شوند. این لاگ شامل بازیگر، جلسه، درخت کاری (Worktree) و خط فرمان (با حذف اسرار) است.

برای تضمین یکپارچگی، این لاگ «فقط-افزودنی» (Append-only) است. تریگرهای SQLite به نام‌های audit_no_update و audit_no_delete هرگونه تلاش برای تغییر یا حذف ردیف‌های قدیمی را متوقف می‌کنند. عملیات لغو (Revoke) صرفاً یک ردیف جدید اضافه می‌کند.

علاوه بر این، لاگ‌ها به‌صورت زنجیره‌ای از هش‌ها (Hash-chained) ذخیره می‌شوند. هر ردیف شامل هش SHA-256 ردیف قبلی و هش خودش است که در همان تراکنشِ درج محاسبه می‌شوند. فرآیند هشینگ از یک رشته JSON استاندارد استفاده می‌کند که با مرتب‌سازی کلیدهای ردیف ایجاد شده است: const canonical = JSON.stringify(row, Object.keys(row).sort());.

اگر فیلدی ویرایش شود یا ردیفی حذف گردد، زنجیره می‌شکند. اگرچه کاربری با دسترسی به فایل می‌تواند کل لاگ را بازنویسی کرده و هش‌ها را مجدداً محاسبه کند، اما نگه داشتن کپی از آخرین هش در جایی دیگر، مانع از دستکاری بی‌صدا می‌شود. مستندات لاگ بازرسی شامل یک اسکریپت کوتاه برای تایید زنجیره است.

شکست امن: رفع باگ انتخاب هدف

یک باگ بحرانی درست یک روز پیش از عرضه شناسایی شد که مربوط به نحوه انتخاب هدف در پروژه‌هایی بود که هم هدف Staging و هم Production برای یک ارائه‌دهنده داشتند. در ابتدا، اگر دستوری مثل supabase db push (که محیط را نام نمی‌برد) اجرا می‌شد، Styx بررسی می‌کرد آیا دسترسی زنده‌ای برای هر هدفی وجود دارد یا خیر. اگر نبود، به‌طور پیش‌فرض اولین هدف غیر-عملیاتی را انتخاب می‌کرد.

این یعنی دستوری که برای Production در نظر گرفته شده بود، ممکن بود با سیاست‌های Staging سنجیده شود و احتمالاً تحت یک دسترسی Staging آسان‌تر، تغییراتی در دیتابیس عملیاتی ایجاد کند. اکنون Styx بر اساس اصل «شکست امن» (Fail Closed) عمل می‌کند. محیط ابتدا تعیین می‌شود: اگر دستوری صراحتاً نام محیط را نبرد، به‌طور پیش‌فرض «عملیاتی» (Production) فرض می‌شود.

در BrokerHost.pickTarget منطق جدید ابتدا پرچم‌هایی مثل --prod یا --production یا کلمه production را بررسی می‌کند. اگر پیدا نشد، از envOfCommand مربوط به آداپتور استفاده می‌کند. اگر آن هم null بود، به استخر Production می‌رود.

برای Vercel، آداپتور مشخص می‌کند که فقط دستور deploy بدون --prod یا --target production و دستور env که نام preview/development را دارد و دستور read به عنوان preview شناخته می‌شوند. هر چیز دیگری، از جمله promote یا rm به عنوان Production تلقی می‌شود. برای سایر CLIها، هر دستوری که نام محیط را نبرد، در صورت وجود هدف Production، با آن سنجیده می‌شود و یک دسترسی Staging نمی‌تواند چنین دستوری را اجرا کند.

محدودیت‌های فعلی

باید توجه داشت که Styx یک حفاظ است، نه یک سندباکس کامل. همان‌طور که در مدل امنیتی ذکر شده، عامل‌ها همچنان با دسترسی کاربر اجرا می‌شوند و می‌توانند هر فایلی را که حساب کاربر به آن دسترسی دارد بخوانند/بنویسند، هر برنامه‌ای را اجرا کنند و به شبکه متصل شوند.

Styx نمی‌تواند عاملی را که شیم‌ها را دور می‌زند و CLI را از طریق مسیر مطلق (Absolute Path) فراخوانی می‌کند، متوقف کند. اگرچه Styx به عامل‌ها می‌گوید این کار را نکنند، اما اگر ابزاری مثل Claude Code این کار را انجام دهد، Styx فقط می‌تواند یک هشدار در چت ارسال کند که هیچ دسترسی‌ای درخواست نشده و چیزی ثبت نشده است. همچنین در حال حاضر ابزارهایی مثل scp، rsync، sftp، gsutil، bq، sam یا cdk را پوشش نمی‌دهد، هرچند در نقشه راه هستند.

علاوه بر این، برای Vercel، Supabase و GitHub، یک دستور تایید شده، توکن کامل ذخیره شده را دریافت می‌کند. یک عامل مخرب می‌تواند این توکن را در طول مدت دسترسی کپی کند؛ لغو دسترسی در Styx جلوی تحویل‌های آینده را می‌گیرد اما توکن را در سطح ارائه‌دهنده لغو نمی‌کند. برای محیط Production، توسعه‌دهنده توصیه می‌کند از توکن‌های اختصاصی با کمترین سطح دسترسی (Least Privilege) استفاده شود.

نقشه راه آینده

بهبودهای آتی عبارتند از:

• افزودن شیم برای ابزارهای باقی‌مانده که در آداپتورها طبقه‌بندی شده‌اند (scp، rsync، sftp، gsutil، bq، sam، cdk).
• ادغام تایید زنجیره هش و خروجی گرفتن از لاگ‌ها مستقیماً در اپلیکیشن برای حذف نیاز به sqlite3.
• گسترش پشتیبانی به اهداف بیشتر، از جمله Azure و Netlify.

این تغییر در تجربه توسعه، صنعت را از «اعتماد کورکورانه» به استفاده از ابزارها توسط عامل‌ها دور می‌کند. با اجباری کردن تایید بیومتریک برای نوشتن در محیط عملیاتی، Styx یک فاجعه احتمالی را به یک اعلان تایید ساده تبدیل می‌کند. اگر ایزولاسیون مطلق مورد نیاز است، کاربران باید عامل‌ها را علاوه بر Styx، داخل یک VM یا کانتینر اجرا کنند.

گام بعدی شما

• اگر از عامل‌های کدنویس برای پروژه‌های واقعی استفاده می‌کنید، Styx را نصب کنید تا ریسک حذف تصادفی دیتابیس را حذف کنید.
• در فایل .styx/project.json قوانین سخت‌گیرانه‌ای برای دستورات drop و delete تعریف کنید.
• برای محیط‌های Production، حتماً از توکن‌های اختصاصی با کمترین سطح دسترسی (Least Privilege) استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.