تصور کنید یک قانون حیاتی برای عامل هوش مصنوعی خود تعریف کرده‌اید، اما تنها به دلیل اینکه آن را با یک تیتر برجسته نوشته‌اید، سیستم نظارتی آن را کاملاً نادیده می‌گیرد. این یک خطای ساده در فرمت‌بندی است که می‌تواند منجر به استقرار فاجعه‌بار نرم‌افزارها بدون تایید انسانی شود. در ۱۱ اکتبر ۲۰۲۶، یک توسعه‌دهنده افشا کرد که فرمت‌بندی قوانین حساس به‌صورت تیترهای مارک‌داون — مثلاً ## Never deploy without human approval — به‌طور موثری قابلیت‌های شناسایی سیستم بازبینی را دور می‌زند.
این آسیب‌پذیری به این دلیل رخ می‌دهد که بسیاری از استخراج‌کننده‌های هوش مصنوعی، تیترهای سطح یک تا سه را صرفاً به‌عنوان «برچسب بخش» می‌بینند، نه دستوراتی که باید اجرا شوند. وقتی قانونی به‌عنوان تیتر ثبت شود، بازرس در هنگام بررسی تضادها آن را نادیده می‌گیرد و اجازه می‌دهد دستور متضاد (مثلاً «به محض تایید تست‌ها، استقرار خودکار انجام شود») به‌عنوان تنها دستور فعال پذیرفته شود. نتیجه این است که برای سیاستی که مستقیماً با خودش در تضاد است، حکم «ریسک مشاهده‌شده پایین» (low_observed_risk) صادر می‌شود.
اگر عامل شما توسط مجموعه‌ای از قوانین در فایل‌هایی مثل CLAUDE.md یا AGENTS.md هدایت می‌شود، احتمالاً مهم‌ترین قوانین را برای برجسته‌تر شدن به صورت تیتر می‌نویسید. اما همین تلاش برای «بلندتر» کردن صدای قانون برای عامل، آن را برای بازرس «بی‌صدا» می‌کند. این وضعیت یک شکاف خطرناک ایجاد می‌کند که در آن قوانینی که عامل بیشترین تکیه را به آن‌ها دارد، دقیقاً همان قوانینی هستند که بازرس هرگز آن‌ها را بررسی نمی‌کند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شکاف بین آنچه مدل می‌بیند و آنچه ابزارهای نظارتی استخراج می‌کنند، بزرگ‌ترین نقطه ضعف سیستم‌های عامل‌محور است. این چالش‌ها در مدیریت رفتار عامل‌ها با راهکارهای جدید Rulestack برای کنترل دقیق‌تر خروجی‌های عامل‌های هوشمند نیز مورد بررسی قرار گرفته است.
زمینه و جزئیات شکست
به گزارش منابع فنی، در سپتامبر سال جاری، یک نقطه اتصال (endpoint) خدمات عمومی این شکست را به نمایش گذاشت. یک سیاست استقرار دو خطی که کاملاً متناقض بود، ایمن‌ترین حکم ابزار را دریافت کرد: low_observed_risk. این اتفاق به این دلیل رخ داد که بازرس دستورات را از فایل حافظه می‌گیرد، سطح دسترسی آن‌ها را تعیین می‌کند و سپس تضادها را می‌سنجد. چون استخراج‌کننده تیتر مارک‌داون را فقط یک برچسب می‌دید، آن را به‌عنوان یک آیتم مجزا برای مقایسه وارد نکرد؛ در نتیجه یک آیتم استخراج شد و صفر تضاد یافت شد.
اگرچه این نقطه اتصال دیگر این نتیجه را برای ورودی‌های مشابه برنمی‌گرداند، اما این نقص یک حقیقت تلخ را درباره نحوه درک «اهمیت» توسط عامل‌های هوش مصنوعی (AI Agents) آشکار کرد. وقتی مسائل پیچیده می‌شوند، عامل‌ها اغلب استدلال را رها کرده و صرفاً قانونی را تکرار می‌کنند که با تیتر یا حروف بزرگ برجسته شده است. همان‌طور که یکی از عامل‌ها توضیح داد، وقتی وضعیت نامشخص است، تکرار قانونی که برجسته‌تر است، امن‌ترین حرکت به نظر می‌رسد. این تمایل به نادیده گرفتن منطق در пользу الگوهای ظاهری، یادآور مواردی است که در آن عامل‌های کدنویسی هوش مصنوعی نتایج آزمون‌ها را جعل می‌کنند تا ظاهر کار را درست جلوه دهند.
این یک پارادوکس است: خطوطی که عامل بیشترین تکیه را به آن‌ها دارد، دقیقاً همان خطوطی هستند که بازرس هرگز استخراج نمی‌کند. منطق داخلی عامل به سمت هر چیزی که «بلندتر» باشد (مثل کلمات BINDING، حروف بزرگ یا تیترها) کشیده می‌شود. چون در خروجی عامل مشخص نیست که آیا قانونی را چون «درست بود» اجرا کرده یا چون «آشناترین چیز در دسترس بود»، بررسی باید خارج از خودِ عامل صورت بگیرد.
راهکار دفتر کل حفاظتی
برای حل این مشکل، توسعه‌دهنده سیستمی را بر اساس پیشنهاد وین نگوئن (Vinh Nguyen) پیاده کرد. مکانیزم اصلی، یک «دفتر کل حفاظتی» (Conservation Ledger) است که تضمین می‌کند هر خط غیرخالی ورودی، در خروجی نیز حسابرسی شود. نگوئن هشدار داد که یک تیتر، دستور را نابود نمی‌کند، بلکه آن را به فیلد «بخش» منتقل می‌کند؛ جایی که دستور همچنان «موجود، چاپ‌شده و خواناست، اما خارج از هر مجموعه‌ای است که یک کف (floor) بر اساس آن شرط‌گذاری شده است».
اکنون هر خط غیرخالی باید دقیقاً به یکی از چهار وضعیت زیر اختصاص یابد:
- became_item: خط با موفقیت به‌عنوان دستور استخراج و به بررسی‌های بعدی فرستاده شد.
- merged_into_item: خط با خط دیگری ادغام شد تا یک دستور واحد بسازد.
- consumed_as_section_heading: خط به‌عنوان برچسب بخش (تیتر) شناسایی شد.
- dropped_below_min_chars: خط برای استخراج بیش از حد کوتاه بود.
اولویت هویت بر تعداد
بازرس دیگر به تعداد کل خطوط تکیه نمی‌کند، چون این عدد را می‌توان جعل کرد. اکنون سیستم شماره خطوط را مقایسه می‌کند تا «هویت» هر خط را ثابت کند. سیستم از یک بررسی خاص برای اطمینان از متوازن بودن دفتر کل استفاده می‌کند:
expected = [n for n, line in enumerate(text.splitlines(), start=1) if line.strip()]recorded = [entry["line"] for entry in ledger]duplicates = sorted({n for n in recorded if recorded.count(n) > 1})missing = sorted(set(expected) - set(recorded))unexpected = sorted(set(recorded) - set(expected))balanced = not duplicates and not missing and not unexpected
اگر خط ۱ دو بار ثبت شود اما خط ۲ گم شود، دفتر کل با شکست مواجه می‌شود، حتی اگر تعداد کل خطوط درست باشد. این بررسی ثابت می‌کند که آیا خطی واقعاً پردازش شده یا خیر، نه اینکه وضعیت پردازش آن درست بوده است یا نه. برای مثال، یک وضعیت اشتباه (misspelled disposition) همچنان دفتر کل را متوازن می‌کند، اما یک «حذف نام‌گذاری شده» (مانند تیتر) همچنان به‌عنوان یک شکاف ثبت می‌شود.
این دفتر کل مانع از آن می‌شود که ابزار در صورت وجود شکاف‌ها، گواهی «سلامت کامل» صادر کند. اگر استخراج‌کننده یک تیتر یا حذف خط به دلیل کوتاهی را ثبت کند، سیستم به‌طور خودکار احکام low_observed_risk و usable_with_gates را غیرفعال کرده و وضعیت را به «پوشش ناقص» (incomplete_coverage) تغییر می‌دهد. تنها استثنا این است که یافته‌های با شدت بالا (high-severity) همچنان اولویت دارند؛ یعنی هشدارها همچنان به صدا در می‌آیند، اما «آسایش» ناشی از یک حکم پاک حذف می‌شود.
مشکل «بهانه» یا Alibi
نسخه اولیه این اصلاحیه توسط یک بازرس هوش مصنوعی دیگر — یک صندلی AI دوم که برای شکستن قراردادها استفاده می‌شد — به‌عنوان یک «بهانه» (Alibi) علامت‌گذاری شد. در آن نسخه، دفتر کل متوازن بود چون هر خط توضیح داده شده بود، اما تیتر گزارش همچنان ادعا می‌کرد فایل ایمن است. در واقع ابزار سوابق دقیقی از اینکه «چرا تضاد را ندیده است» ارائه می‌داد، اما این سوابق درست زیر حکمی قرار داشت که به کاربر می‌گفت «چیزی برای دیدن وجود ندارد».
توسعه‌دهنده متوجه شد که «حسابرسی یک خط» با «ارزیابی آن» متفاوت است. همان‌طور که در کامنت‌های کد اکنون به‌وضوح ذکر شده است: «دفتر کلی که چنین کاری کند، یک بهانه است». در نسخه نهایی، دفتر کل (جایگاه خط) از ارزیابی (آیا چیزی واقعاً آن را بررسی کرد) جدا شد.
نقاط کور باقی‌مانده
با وجود دفتر کل، سیستم هنوز کامل نیست. حفظ خطوط به معنای حفظ دستورات نیست. توسعه‌دهنده به چندین ریسک و ناپایدار باقی‌مانده اشاره کرد:
- ادغام خطوط: اگر دو دستور متضاد (مثلاً «هرگز بدون تایید انسانی استقرار نکن» و «به محض تایید تست‌ها استقرار خودکار کن») در یک خط فیزیکی قرار بگیرند، دفتر کل متوازن می‌ماند اما تضاد ممکن است شناسایی نشود و منجر به حکم
low_observed_riskشود. این یک ناپایداری مسیری است، نه دلیلی بر اینکه پارسر هر دستور را یافته است. - سطوح تیتر: فقط تیترهای سطح ۱ تا ۳ به‌عنوان شکاف شناسایی می‌شوند. یک تیتر سطح ۴ (
####) به‌عنوان متن بدنه خوانده می‌شود، به این معنی که شکافی ایجاد نمی‌کند اما ممکن است باز هم به‌عنوان تضاد شناسایی نشود، زیرا بازرس هنوز یاد نگرفته است که چه زمانی یک تیتر باید به‌عنوان دستور خوانده شود. - تطبیق عبارات: بررسی تضادها بر اساس تطبیق عبارات است. نبود یافته‌ها به معنای ایمن بودن فایل نیست؛ حقیقتی که خود گزارش صراحتاً بیان می‌کند: «نبود یافته‌ها ثابت نمی‌کند که فایل حافظه ایمن است».
- شکاف‌های پایین‌دستی: یک آیتم استخراج شده ممکن است بررسی نشود و به‌عنوان شکاف ظاهر نشود. برای مثال، عبارت «بدون بررسی فوراً منتشر کن» ممکن است به یک آیتم تبدیل شود و حکم
usable_with_gatesرا با صفر شکاف برگرداند، اما تنها یک یافته در سطح فایل ایجاد کند که «هیچ حافظه سیاست حاکم واضحی شناسایی نشد».
کاربرد عملی و بازبینی
برای کسانی که فایل‌های پیچیده استارت‌آپ عامل خود را مدیریت می‌کنند، توسعه‌دهنده استفاده از یک دستور curl خاص برای بازبینی فایل‌های AGENTS.md یا CLAUDE.md را پیشنهاد می‌کند. برای جلوگیری از خطاهای نقل‌قول، توصیه می‌شود از jq برای ساخت JSON استفاده کنید:
jq -n --rawfile text sanitized.md '{text: $text}' | curl -s https://memory-authority-auditor-web-qfppqeeedq-uc.a.run.app/api/audit -H 'Content-Type: application/json' --data-binary @- | jq '{posture: .report.posture, gaps: .report.coverage.gaps}'
در یک تست روی یک فایل شخصی با ۲۵۷ خط غیرخالی و ۲۲ تیتر، بازرس به‌درستی تمام ۲۲ تیتر را به‌عنوان شکاف پوششی شناسایی کرد. ۱۰ مورد از این تیترها خود را به‌عنوان «الزام‌آور» معرفی کرده بودند، از جمله حیاتی‌ترین خط: ## READ THIS FIRST, EVERY SESSION, BEFORE ANYTHING ELSE.
این تغییر رویکرد، هدف را از جست‌وجوی یک «گزارش پاک» به شناسایی دقیق خطوطی تغییر می‌دهد که هوش مصنوعی نادیده می‌گیرد. در اینجا حکم نهایی بخش مفید نیست؛ بلکه لیست شکاف‌هاست. با حفظ هویت‌ها در ابتدایی‌ترین واحد منبع و امتناع از گزارش «پاک» در حالی که آیتم‌ها حسابرسی شده اما استخراج نشده‌اند، این ابزار یک کف لازم برای امنیت حافظه ایجاد می‌کند.
درگاه ورودی و اهداف آینده
این بازرس بخشی از یک خط لوله بزرگ‌تر است. در حالی که بازرس فایل حافظه را پس از انباشت بررسی می‌کند، تولیدکننده کارت حافظه عامل (Agent Memory Card Generator) در لحظه نوشتن دستور عمل می‌کند. این ابزار هر دستور را در دسته‌های «دروازه» (gate)، «پاسخ» (answer)، «ابتدا تایید کن» (verify first) یا «مسدود کن» (block) طبقه‌بندی کرده و دلیلی برای این طبقه‌بندی ارائه می‌دهد. برای مثال، یک قانون مربوط به اعتبارنامه‌ها (credentials) به‌عنوان BLOCK علامت‌گذاری می‌شود، در حالی که دستوری که بر اساس ورودی مالک عمل می‌کند، VERIFY FIRST می‌شود. این رویکرد سخت‌گیرانه برای کنترل دسترسی‌ها، مشابه معماری جدید مایکروسافت برای توقف نامحدود عامل‌ها جهت تأیید انسانی است که بر ایمنی در نقاط حساس تأکید دارد.
هدف، ابزاری است که هر دستور را بررسی کند. در حال حاضر، این ابزار با نام بردن از خطوطی که هرگز استخراج نشده‌اند، یک کف ایمنی ایجاد می‌کند. پیاده‌سازی این دفتر کل در کامیت 17f1a0b در شاخه auditor-empty-set-conservation به‌صورت عمومی در دسترس است. اگرچه نسخه مستقر شده ممکن است از نظر بایتی دقیقاً با یک کامیت خاص یکسان نباشد، اما رفتار پوششی آن از اوایل سپتامبر فعال شده است.
گام بعدی شما
- اگر از فایل‌های
.mdبرای مدیریت دستورات عامل‌های خود استفاده می‌کنید، از تیترهای سطح ۱ تا ۳ برای قوانین حیاتی پرهیز کنید یا آن‌ها را در متن بدنه بنویسید. - فایل‌های حافظه خود را با ابزارهای بازبینی تست کنید تا متوجه شوید کدام خطوط توسط استخراج‌کننده نادیده گرفته می‌شوند.
- برای قوانین بسیار حساس، از کلمات کلیدی تکراری در ابتدای خط و انتهای خط استفاده کنید تا احتمال نادیده گرفته شدن در ادغام خطوط کم شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو