اسکنر Fail-Closed مانع تزریق تنظیمات پنهان توسط عامل‌های هوش مصنوعی شد

تصور کنید یک وصلهٔ کد (Patch) که توسط هوش مصنوعی نوشته شده، تمام تست‌ها را پاس می‌کند و چراغ‌ها سبز می‌شوند، اما یک فلگ (Flag) پنهان و اعلام‌نشده در آن وجود دارد که می‌تواند منجر به توقف کامل سیستم در محیط عملیاتی (Production Outage) شود. برای مبارزه با این ریسک، یک گردش‌کار فنی جدید که در ۶ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، هرگونه مقدار پیش‌فرض اعلام‌نشده را به عنوان یک شکست بحرانی تلقی کرده و بدون هیچ مذاکره‌ای، بلافاصله شاخهٔ کد (Branch) مربوطه را حذف می‌کند.

این رویکرد در زمانی ارائه می‌شود که توسعه‌دهندگان با «شکاف بازبینی» (Review Gap) دست‌وپنجه نرم می‌کنند؛ واقعیتی تلخ که در آن عامل‌های هوش مصنوعی کدها را در چند ثانیه می‌نویسند، اما ساعات بازبینی انسانی مقیاس‌پذیر نیستند. دقیقاً در همین شکاف است که «پیش‌فرض‌های خاموش» زندگی می‌کنند. وقتی یک عامل هوش مصنوعی مقداری را فرض می‌کند یا یک فلگ «کمک‌کننده» مانند force را اضافه می‌کند که توسعه‌دهنده هرگز درخواست نکرده است، یک پیش‌فرض خاموش ایجاد شده است. این فرض‌های پنهان اغلب از مجموعه‌های تست استاندارد عبور می‌کنند، زیرا تست‌ها زمانی که آن فلگ ظاهر می‌شود همچنان پاس می‌شوند؛ اما تست‌های سبز ثابت نمی‌کنند که عامل برای افزودن آن اجازه گرفته است.

معماری شکست بسته (Fail-Closed)

هستهٔ این سیستم یک ریتوال یا آیین «شکست بسته» است که شواهد سخت را جایگزین حس‌های مبهم می‌کند. هدف در اینجا ارائه یک راهنمای بقای معماری دیگر نیست که پر از بیست واژهٔ پرزرق‌وبرق دربارهٔ عامل‌ها باشد، بلکه ایجاد یک بستهٔ مشخص شامل سه فایل است: یک لیست سفید (Allowlist)، یک اسکنر و مجموعه‌ای از شواهد. این فرآیند به شش گیت (Gate) سخت‌گیرانه تقسیم شده است تا ارسال کدهای خاموش و مبهم را هزینه‌بر کند.

زمینه و محدودیت‌ها

برای حفظ یکپارچگی این گیت‌ها، توسعه‌دهنده باید تحت محدودیت‌های عملیاتی شدیدی کار کند. بودجهٔ زمانی برای کل این فرآیند، از لحظه کلون کردن مخزن تا تصمیم نهایی، نود دقیقه است. اگر این محدودیت زمانی به پایان برسد، شاخهٔ کد بدون استثنا رها (Abandon) می‌شود.

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

جزئیات مکانیزم گیت‌های نظارتی

• گیت ۱: انجماد وظیفه (Task Freezing). توسعه‌دهنده باید پیش از هر اقدامی، وظیفه را در یک جمله واحد در فایل task.txt بنویسد. اگر وظیفه مبهم یا «تار» باشد، عامل هوش مصنوعی سکوت را با فرض‌های شخصی خود پر می‌کند. برای مثال، یک وظیفه صحیح می‌تواند این باشد: «یک فلگ --timeout-s اضافه کن. مقدار پیش‌فرض ۱۵ باشد. هیچ چیز دیگری اضافه نشود.» این گیت همچنین نیازمند فایلی به نام forbidden.txt است تا صراحتاً مواردی را لیست کند که باید کاملاً از وصله کد حذف شوند. در اینجا «نبودن» یک مورد، به عنوان یک نیاز واقعی تلقی می‌شود، نه یک حس کلی. نمونه‌هایی از کلمات ممنوعه عبارتند از: force ،retry ،insecure و auto_approve.

• گیت ۲: اعلام پیش‌فرض‌ها (Default Declaration). هر مقدار پیش‌فرض قانونی باید در یک فایل JSON ساده ذخیره شود (مثلاً: {"timeout_s": 15, "output": "json", "max_tokens": 512}). اگر مقداری در کد ظاهر شود اما در این لیست سفید JSON نباشد، غیرقانونی تلقی می‌شود. دلیل استفاده از JSON به جای چک‌لیست‌های Markdown این است که JSON قابل Diff و Grep است؛ در حالی که یک توسعه‌دهنده خسته نمی‌تواند در حین بازبینی، یک «حس کلی» را Grep کند.

• گیت ۳: پین کردن ابزارها و مسیرها (Tool and Path Pinning). برای جلوگیری از گسترش بی‌رویه دامنه (Scope Creep)، توسعه‌دهنده فایل‌های allowed-tools.txt (مانند read_file ،replace_in_file ،run_tests) و allowed-paths.txt (مانند src/cli.ts ،src/config.ts ،tests/cli.test.ts) را تعریف می‌کند. اگر یک عامل به فایلی برای استقرار (Deployment) دست بزند که نامش در لیست نیست، این یک «پیش‌فرض خاموش در دامنه» محسوب شده و شاخه بلافاصله و بدون مذاکره کشته می‌شود.

• گیت ۴: اسکنر (The Scanner). یک ابزار پایتونی به نام kill_defaults.py به عنوان داور خودکار عمل می‌کند. این ابزار عمداً با «پایتون خسته‌کننده و ساده» نوشته شده است، زیرا وقتی عامل‌ها شروع به بداهه‌پردازی می‌کنند، سادگی یک ویژگی است. اسکنر، Git Diff را تجزیه کرده و به دنبال خطوط اضافه‌شده‌ای می‌گردد که با + شروع می‌شوند (در حالی که هدرهای +++ یا --- را نادیده می‌گیرد). سپس جفت‌های کلید-مقدار را استخراج کرده و کلیدهای مشاهده‌شده را با لیست سفید و لیست ممنوعه مقایسه می‌کند. این ابزار با دستوری شبیه به این اجرا می‌شود:

  git diff main > /tmp/agent.patch
python3 kill_defaults.py --allowlist allowed-defaults.json --forbidden forbidden.txt --allowed-paths allowed-paths.txt --diff /tmp/agent.patch --out review-packet
echo $?

  کد خروجی صفر به معنای پاک بودن بسته است. هر کد دیگری به معنای توقف ادغام (Merge) است.

• گیت ۵: الزامات شواهدی (Evidence Requirements). اسکنر صرفاً یک «احساس» ارائه نمی‌دهد، بلکه یک پوشه به نام review-packet تولید می‌کند. این پوشه باید شامل موارد زیر باشد:

  • declared.json: لیست سفید اصلی.
  • observed.json: کلیدهایی که واقعاً در Diff پیدا شده‌اند.
  • extras.json: کلیدهایی که پیدا شده‌اند اما اعلام نشده بودند.
  • forbidden_hits.txt: هرگونه تطبیق با لیست ممنوعه.
  • path_hits.txt: هر فایلی که خارج از مسیرهای مجاز لمس شده است.
  • verdict.txt: وضعیت نهایی «PASS» یا «FAIL_CLOSED».

  اگر extras.json یک شیء خالی نباشد یا اگر verdict.txt مفقود شود، شاخه رد می‌شود. نبودِ شواهد به عنوان شکست تلقی می‌شود، نه به عنوان مورد قابل چشم‌پوشی.

• گیت ۶: محدودیت زمانی و بازگشت (Time Box and Rollback). کل فرآیند از کلون تا تصمیم در بازه ۹۰ دقیقه‌ای است. اگر شاخه نتواند در این پنجره زمانی پاکسازی شده و از اسکنر عبور کند، رها می‌شود. بازگشت (Rollback) یک دستور است، نه یک سخنرانی: ابتدا git restore . و سپس انتقال review-packet به پوشه abandoned/ با استفاده از دایرکتوری برچسب‌دار زمانی مانند abandoned/$(date +%Y%m%dT%H%M). این کار تضمین می‌کند که فایل extras.json به عنوان یک درس مکتوب باقی بماند تا اشتباهات آخر هفته تکرار نشوند.

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

برای اطمینان از اینکه گیت واقعاً کار می‌کند، گردش‌کار نیازمند یک «نمونه شکست» (Failure Fixture) است؛ یعنی یک وصله کثیف که عمداً برای شکست دادن اسکنر طراحی شده است. یک توسعه‌دهنده هرگز نباید به گیتی اعتماد کند که هرگز با آن شکست نخورده است. برای مثال، یک فایل نمونه مانند fixtures/silent-retry.patch ممکن است مقدار retry: 99 را به یک فایل تنظیمات اضافه کند.

در هنگام اجرا، اسکنر باید کد خروجی ۲ را برگرداند و retry را در extras.json لیست کند. دستور اعتبارسنجی به این شکل است:

python3 kill_defaults.py --allowlist allowed-defaults.json --forbidden forbidden.txt --allowed-paths allowed-paths.txt --diff fixtures/silent-retry.patch --out /tmp/packet-fail
echo $? # expect 2
cat /tmp/packet-fail/extras.json

اگر اسکنر در برابر یک شکست شناخته‌شده ساکت بماند، یک «گیت لال» است و باید دور ریخته شود.

محدودیت‌های فنی

طبق راهنمای dev.to، این اسکنر یک ابزار خشن (Blunt Instrument) است. این ابزار از Regex روی Patchها استفاده می‌کند، به این معنی که پیش‌فرض‌های محاسباتی که داخل توابع کمکی پنهان شده‌اند یا مقادیری که از متغیرهای محیطی بارگذاری می‌شوند را نمی‌بیند. فرض‌های معنایی (Semantic) همچنان ممکن است نفوذ کنند؛ مثلاً یک Timeout اعلام‌شده ممکن است عدد اشتباهی باشد. گیت فقط ثابت می‌کند که مقدار «ابتدا اعلام شده بود».

علاوه بر این، این یک ممیزی امنیتی نیست. این ابزار تزریق پرامپت در خروجی ابزارها یا نشت اسرار (Secrets) در فایل‌های اضافی را شناسایی نمی‌کند. همچنین برای بازسازی‌های عظیم تولید شده (مثلاً PRهای ۳۰۰۰ خطی) مناسب نیست، زیرا این موارد محدودیت زمانی ۹۰ دقیقه‌ای را از بین می‌برند. چنین وظایفی باید تقسیم شوند یا کلاً رد شوند. این ریتوال برای تیم‌هایی که کنترل تغییرات رسمی دارند یا برای کسانی که اصلاً Diffها را نمی‌خوانند نیست، زیرا یک بسته شواهد نمی‌تواند جایگزین دقت چشم انسان شود.

ابزارها و دسترسی

برای کسانی که به دنبال محیطی کم‌هزینه برای تست این عامل‌ها هستند، نویسنده به MonkeyCode اشاره می‌کند؛ یک پروژه متن‌باز که دسترسی رایگان به مدل‌ها و گزینه سرور رایگان برای آزمایش‌ها فراهم می‌کند. با این حال، بسته «شکست بسته» مستقل از فروشنده (Vendor-agnostic) است. توسعه‌دهنده می‌تواند فردا مدل را عوض کند اما گیت‌ها را حفظ کند؛ اگر extras.json پر شود، فرآیند متوقف می‌شود.

این تغییر در عمل، توسعه‌دهنده را از یک «بازبین» به یک «دربان» تبدیل می‌کند. با بالا بردن هزینه پیش‌فرض‌های خاموش نسبت به هزینه یک شاخه شکست‌خورده، این ریتوال عامل‌ها را مجبور می‌کند تا در مرزهای سخت قصد انسان باقی بمانند.

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

گام بعدی شما

• سه فایل اصلی (لیست سفید، لیست ممنوعه و مسیرهای مجاز) را در مخزن کد خود ایجاد و کامیت کنید.
• یک نمونه شکست (Failure Fixture) بسازید تا مطمئن شوید اسکنر واقعاً مقادیر غیرمجاز را شناسایی می‌کند.
• محدودیت زمانی ۹۰ دقیقه‌ای را برای هر نشستِ تولید کد توسط عامل اعمال کنید.

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