سیاست مسیریابی سرورهای یک‌بارمصرف؛ سدی در برابر تخریب لپ‌تاپ توسط کد AI

یک اسکریپت بازنویسی کد (refactor script) که توسط هوش مصنوعی تولید شده بود، جمعه‌ی گذشته سعی کرد خارج از دایرکتوری پروژه بنویسد؛ اتفاقی که ضرورت تغییر در نحوه برخورد با کدهای تاییدنشده را آشکار کرد. مشکل اصلی این است که تلقی کردن لپ‌تاپ اصلی به عنوان یک کانتینر یک‌بارمصرف، شعاع تخریب (blast radius) غیرقابل‌قبولی ایجاد می‌کند؛ به‌ویژه زمانی که یک مدل، دستوری توهم‌آمیز (hallucinated) یا مخرب تولید کند. این تجربه ثابت کرد که حتی اسکریپتی که در ظاهر روی صفحه نمایش تمیز و بی‌خطر به نظر می‌رسد، می‌تواند پس از اجرا رفتاری غیرقابل‌پیش‌بینی داشته باشد.

بسیاری از برنامه‌نویسان در حال حاضر برای سرعت بیشتر، اسکریپت‌های تولیدشده توسط هوش مصنوعی را مستقیماً در محیط محلی (local environment) خود اجرا می‌کنند. این رویه، اصل اساسی امنیت — یعنی برخورد با خروجی مدل‌ها به‌عنوان ورودی‌های غیرقابل‌اعتماد (untrusted input) — را نادیده می‌گیرد؛ استانداردی که توسط OWASP توصیه شده است. وقتی اسکریپتی تمیز به نظر می‌رسد اما رفتاری غیرقابل‌پیش‌بینی دارد، ماشین محلی به اولین نقطه شکست تبدیل می‌شود. برای حل این مشکل، یک گردش‌کار جدید از MonkeyCode استفاده می‌کند تا پروب‌های کد کوتاه و یک‌بارمصرف را به یک سرور رایگان راه دور منتقل کند. MonkeyCode دسترسی رایگان به مدل‌ها و یک گزینه سرور رایگان برای تسک‌های کوچک و یک‌بارمصرف فراهم می‌کند و بدین ترتیب یک مسیر ارزیابی ارزان‌قیمت ایجاد می‌کند که کدهای آزمایشی هوش مصنوعی را از محیط‌های عملیاتی (production) و داده‌های حساس محلی جدا می‌سازد.

گیت سه-سوالی

پیش از هرگونه اجرای کد، یک تابع مسیریابی (routing function) سخت‌گیرانه اعمال می‌شود. این مسیریاب به‌طور عمدی خسته‌کننده و به اندازه کافی کوتاه طراحی شده است تا بتوان آن را در یک نگاه بازبینی (audit) کرد. این رویکرد در واقع مکمل استراتژی‌های انضباط گردش کار برای بهینه‌سازی خروجی‌های AI است که بر کاهش هزینه‌ها و افزایش ایمنی تأکید دارد. این ابزار بر اساس سه معیار مشخص تصمیم می‌گیرد که آیا یک تسک در محیط محلی بماند یا به سرور یک‌بارمصرف منتقل شود:

• منبع (Source): آیا کد توسط یک انسان بازبینی شده است، یا صرفاً توسط مدل تولید شده است؟
• شبکه (Network): آیا تسک به دسترسی به سرویس‌های دیگر یا خروجی‌های خارجی (external egress) نیاز دارد؟
• اندازه (Size): این کد چقدر حافظه، دیسک و زمان مصرف می‌کند؟ به‌طور مشخص، آیا مصرف حافظه از ۵۱۲ مگابایت یا زمان اجرا از ۶۰۰ ثانیه فراتر می‌رود؟

اگر اسکریپتی توسط انسان بازبینی شده باشد، در محیط محلی می‌ماند زیرا توسعه‌دهنده می‌تواند سریع‌تر آن را ردیابی کرده و با ابزارهای کامل عیب‌یابی کند. با این حال، هر کد تولیدشده‌ای که به دسترسی شبکه نیاز داشته باشد، یا در محیط محلی می‌ماند یا به یک ماشین مجازی (VM) کامل منتقل می‌شود، زیرا باکس ارزیابی (evaluation box) دسترسی خروجی (egress) ندارد. به همین ترتیب، کدهای تولیدشده با مصرف بیش از ۵۱۲ مگابایت یا زمان بیش از ۶۰۰ ثانیه در محیط محلی می‌مانند، چرا که سرور رایگان برای پروب‌ها طراحی شده است، نه برای حجم‌های کاری (workloads) واقعی.

منطق مسیریابی و جدول تصمیم‌گیری

مسیریابی توسط یک تابع ساده مدیریت می‌شود: def route_task(source: str, needs_network: bool, max_mb: int, lifespan_s: int) -> str:. اگر منبع کد 'generated' نباشد، یا اگر نیاز به دسترسی شبکه داشته باشد، و یا اگر از محدودیت‌های حافظه و زمان عبور کند، تابع مقدار 'local' را برمی‌گرداند. تنها پروب‌های تولیدشده، کوچک و بدون نیاز به شبکه به 'free-server' ارسال می‌شوند.

پروب‌های پیش‌پرواز و اجرا

اجرای کد در یک سرور رایگان به‌طور خودکار ایزولاسیون را تضمین نمی‌کند. این گردش‌کار شامل یک «تست بویایی» (smell test) با استفاده از پروب‌های پیش‌پرواز (preflight probes) است تا محیط را پیش از اجرای اسکریپت هوش مصنوعی تأیید کند. این پروب‌ها یک محیط امنیتی کامل (security perimeter) نیستند، بلکه بررسی سریعی هستند تا ببینیم سرور در واقعیت چه دسترسی‌هایی را اجازه می‌دهد:

• پروب خروجی (Egress Probe): اجرای دستور timeout 5 curl -s 'https://example.com' >/dev/null برای بررسی اینکه آیا دسترسی خروجی باز است یا مسدود شده است.
• پروب فضای کاری (Workspace Probe): اجرای df -h /tmp برای بررسی فضای دیسک در دسترس.
• پروب زمان اجرا (Runtime Probe): اجرای python3 --version برای تأیید محیط اجرا.

اگر دسترسی خروجی باز باشد، با تسک به شکل متفاوتی برخورد می‌شود. اگر فضای کاری بسیار کوچک باشد، آستانه مسیریاب از ۵۱۲ مگابایت به مقدار کمتری کاهش می‌یابد. پس از اعتبارسنجی، اسکریپت روی یک کپی از مخزن (مثلاً از طریق git clone /local/repo /tmp/repo-copy --depth 1) یا داده‌های نمونه مصنوعی (synthetic sample data) اجرا می‌شود. استفاده از فلگ --dry-run برای اولین اجرا اجباری است. این مرحله حیاتی است زیرا بسیاری از اسکریپت‌های تولیدشده تنها زمانی رفتار واقعی خود را نشان می‌دهند که به یک دایرکتوری قابل‌نوشتن دسترسی داشته باشند.

سلسله‌مراتب ایزولاسیون

همه روش‌های ایزولاسیون یکسان نیستند. این گردش‌کار بین سطوح مختلف ریسک و هزینه‌های راه‌اندازی تمایز قائل می‌شود و خاطرنشان می‌کند که مستندات امنیتی داکر (Docker) هشدار می‌دهند که ایزولاسیون فرآیندها (process isolation) یک مرز امنیتی کامل نیست.

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

حتی با وجود این لایه‌ها، فرآیند مستلزم بازبینی دستی ۴۰ خط اول هر اسکریپت است. اگر کد حاوی بلوک‌های مبهم eval یا دستورات حذف فایل یا فراخوانی‌های مکرر os.system باشد، بدون توجه به مقصد مسیریابی، رد می‌شود.

کاربردها و محدودیت‌ها

این مسیر یک‌بارمصرف برای سه نوع کار خاص استفاده می‌شود: اسکریپت‌های بازنویسی کوچک که روی کپی مخازن اجرا می‌شوند، پروب‌های پاک‌سازی داده یا تبدیل فرمت تک‌مرحله‌ای روی داده‌های مصنوعی، و بررسی حالت‌های شکست (failure-mode checks) که قابلیت اجرای مجدد از ابتدا را دارند. این روش هرگز برای داده‌های مشتری، اعتبارنامه‌ها (credentials) یا هر چیزی که نیاز به پایگاه‌داده داشته باشد، استفاده نمی‌شود.

برای کسانی که استقرار در محیط تولید (production deployments) یا داده‌های رگوله‌شده مشتریان را مدیریت می‌کنند، این مسیر یک‌بارمصرف کافی نیست. چنین تسک‌هایی به یک ردپای حسابرسی (audit trail) کامل و یک سندباکس سخت‌گیرانه (hardened sandbox) نیاز دارند، زیرا ظرفیت‌های رایگان برای مقیاس‌پذیری، کارهای GPU یا ذخیره‌سازی دائمی طراحی نشده‌اند. این یک گردش‌کار شخصی برای پروب‌ها است، نه یک استراتژی میزبانی یا یک مرز انطباق امنیتی (compliance boundary).

برای شروع در مقیاس کوچک، یک اسکریپت تولید کنید، آن را با منطق route_task بررسی کنید، پروب‌های پیش‌پرواز را اجرا کنید، آن را روی یک هدف مصنوعی اجرا نمایید و سپس باکس را دور بیندازید. لپ‌تاپ شما نباید اولین جایی باشد که کدهای تاییدنشده هوش مصنوعی سعی می‌کنند خارج از دایرکتوری پروژه بنویسند.

گام بعدی شما

• اسکریپت‌های تولیدشده توسط هوش مصنوعی را هرگز مستقیماً روی دایرکتوری اصلی پروژه اجرا نکنید.
• یک تابع ساده مسیریابی (مانند route_task) برای تفکیک کدهای بازبینی‌شده از کدهای خام طراحی کنید.
• از محیط‌های ایزوله یا سرورهای یک‌بارمصرف برای اجرای اولین نسخه هر اسکریپت با فلگ --dry-run استفاده کنید.

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