یک رکورد گم‌شده در سیستم می‌تواند یک نقص فنی کوچک در هوش مصنوعی را به یک فاجعه‌ی حقوقی تبدیل کند. وقتی یک عامل (Agent) — شبیه به کارمندی دیجیتال که می‌تواند به‌جای شما ابزارها را اجرا کند — دچار خطا می‌شود، تنها دفاعی که در دادگاه یا بازرسی پذیرفته می‌شود، یک گزارش قابل تأیید از این است که چه چیزی، در چه زمانی و توسط چه کسی بررسی شده است.
این چرخش به سمت مستندسازی سخت‌گیرانه درست زمانی رخ می‌دهد که لایحه‌ی پاسخگویی عامل‌های هوش مصنوعی هاولی/مورفی (Hawley/Murphy) در ۱ اکتبر معرفی شد. اگرچه این لایحه هنوز به قانون تبدیل نشده است، اما مفهوم «حفاظ‌های معقول» را معرفی می‌کند؛ عبارتی مبهم که تیم‌های مهندسی را در معرض خطر قرار می‌دهد، زیرا تکیه بر حافظه یا پرامپت‌های سیستمی (System Prompts) — دستورالعمل‌های اولیه که رفتار مدل را تعیین می‌کنند — برای اثبات ایمنی کافی نیست.
زمینه و بستر پاسخگویی
اکثر تیم‌ها به سؤالات ایمنی با تکیه بر حافظه پاسخ می‌دهند و ادعا می‌کنند که پرامپت سیستمی به عامل دستور داده است که به محیط عملیاتی (Production) دست نزند یا اینکه «حفاظ‌هایی» (Guardrails) را پیاده کرده‌اند. اما هیچ‌کدام از این ادعاها چیزی نیستند که بتوانید به یک بازرس نشان دهید. حفاظ‌ها شبیه به نرده‌های ایمنی در لبه‌ی یک پل هستند که مانع سقوط کاربر می‌شود، اما بدون مدرک، وجود آن‌ها اثبات نمی‌شود. این چالش‌ها در چارچوب‌های ارزیابی جدیدی مانند AgentGuardBench برای سنجش دقیق‌تر ریسک‌های امنیتی مورد بررسی قرار گرفته‌اند تا نقاط ضعف حفاظ‌ها شناسایی شود.
وقتی تعاریف ایمنی مبهم هستند، تنها چیزی که یک تیم مهندسی بر آن کنترل دارد، سوابق خودش است. این صرفاً یک استراتژی حقوقی نیست؛ بلکه یک عادت مهندسی است که برای اولین باری که یک عامل در ساعت ۲ صبح رفتار عجیبی از خود نشان می‌دهد، طراحی شده است.
برای حل این مشکل، یک چارچوب عملیاتی جدید پیشنهاد می‌کند که برای هر عامل یک فایل EVIDENCE.md ایجاد شود. این لاگ، ادعای «ما حفاظ داشتیم» را با چهار جدول مشخص و داده‌محور جایگزین می‌کند. قانون اصلی ساده است: اگر بررسی را انجام نداده‌اید، ردیف را خالی بگذارید. یک ردیف خالی حقیقت را می‌گوید؛ اما تاریخی که بعداً برای پر کردن جاهای خالی اضافه شده باشد، خیر. این رویکرد در واقع پاسخی به پیش‌نویس IETF است که بر خطرات خطاهای نامرئی و ثبت سوابق منفی تأکید دارد.
۱. لیست‌های مجاز شبکه و ابزار
به‌جای ادعای کلی مبنی بر اینکه «خروجی‌ها محدود شده‌اند»، تیم‌ها باید دامنه‌های دقیق، انواع رکورد DNS، ابزارها و محدوده‌های نوشتاری (Write Scopes) مجاز را ثبت کنند.
- سازوکار: استخراج مستقیم داده‌ها از پیکربندی زنده (Live Config) یا سیاست‌های خروجی (Egress Policy).
- شواهد: یک ورودی معتبر باید شامل هشِ کامیت (Commit Hash) دقیق (مثلاً
a19f03d) و تاریخ بازبینی باشد. - مثال: یک ورودی ضعیف می‌گوید «همه چیز درست به نظر می‌رسد». اما یک ورودی استاندارد دقیقاً ذکر می‌کند:
api.payments-sandbox.test (write: refunds)وmail.internal (send: templated)، در حالی که همزمان حذفpastebin.comو*.githubusercontent.comرا ثبت می‌کند.
۲. اعتبارسنجی کلید توقف (Kill-Switch)
تست دستور توقف روی یک عامل بیکار بی‌فایده است، چون یک عامل بیکار همیشه متوقف می‌شود. این چارچوب الزام می‌کند که کلید توقف در حالی که عملیات در جریان است (In-flight) تست شود.
- تست: چندین فراخوانی ابزار را در صف قرار دهید، دستور توقف را ارسال کنید و سپس زمان توقف و تعداد فراخوانی‌هایی که پس از دستور توقف اجرا شده‌اند را اندازه‌گیری کنید.
- هدف: رسیدن به «صفر فراخوانی پس از توقف».
- شکاف فنی: اگر پرچم توقف (Stop Flag) فقط بین مراحل برنامه‌ریزی بررسی شود، ممکن است یک دسته از سه فراخوانی همچنان برای ۴۰ ثانیه اجرا شوند. انتقال این بررسی به داخل مجری ابزار (Tool Executor) — با استفاده از مکانیزم‌هایی مانند
if stop_flag.is_set(): batch.cancel_pending()— می‌تواند زمان توقف را به چند صد میلی‌ثانیه کاهش دهد. - مثال: یک ورودی باکیفیت، زمان دقیق (
۲۰۲۶-۰۹-۲۴ ۱۴:۰۲:۱۰)، محرک استفاده شده (API /stop) و نتیجه (۴۱۲ میلی‌ثانیه | پاس | ۰ فراخوانی پس از توقف) را ثبت می‌کند.
۳. برچسب‌های زمانی حوادث
وقتی خطایی رخ می‌دهد، فاصله بین شناسایی خطا و توقف سیستم، «پنجره مواجهه» (Exposure Window) نامیده می‌شود. این اولین عددی است که در جلسات کالبدشکافی (Post-mortem) از تیم پرسیده می‌شود.
- یکپارچگی داده‌ها: برچسب‌های زمانی باید در همان روز از لاگ‌ها استخراج شوند. زمان‌هایی که یک ماه بعد از اسکرول کردن در تاریخچه‌ی Slack بازسازی می‌شوند، بیشتر حدس هستند تا واقعیت.
- دقت: دقیقاً ثبت کنید چه چیزی لمس شده است. عبارت «برخی داده‌ها» بی‌فایده است؛ اما «جدول دفتر کل Sandbox، ۱۱ ردیف» یک مورد قابل پیگیری و عملی است.
- مثال: یک لاگ باکیفیت، زمان شناسایی را
۱۴:۳۱:۰۵، زمان هشدار را۱۴:۳۱:۴۰و زمان توقف را۱۴:۳۲:۰۲ثبت کرده و آن را به یک تیکت خاص مانندOPS-212متصل می‌کند.
۴. جداسازی اعتبارنامه‌ها (Credentials)
اگر یک فرآیند عامل بتواند یک اعتبارنامه (Credential) را بخواند، می‌تواند از آن به روش‌های برنامه‌ریزی‌نشده استفاده کند؛ مثلاً آن را در یک لاگ بنویسد یا به یک ابزار غیرمنتظره پاس دهد.
- بررسی: تأیید کنید که اعتبارنامه‌ها خارج از محیط کاری عامل (مثلاً در یک Vault یا مسیری که فقط دسترسی انسانی دارد) نگهداری می‌شوند.
- تأیید: لاگ باید تأیید کند که اعتبارنامه توسط یک پروکسی ابزار (Tool Proxy) واکشی می‌شود و در محیط (Environment) خودِ عامل قرار ندارد. برای مقابله با چنین ریسک‌هایی، معماری‌های پیشرفته‌ای مانند TrustGraph با رویکرد صفر-اعتماد برای جلوگیری از سرقت وزن‌ها و داده‌های حساس توسعه یافته‌اند.
- مثال: یک بررسی موفق ثبت می‌کند که کلید پرداخت‌ها در یک Vault قرار دارد و تأیید می‌کند که هنگام بررسی محیط داخلی کانتینر عامل، هیچ سکرتی (Secret) وجود نداشت.
این رویکرد، فرض بنیادی استقرار عامل‌ها را از «اعتماد به پرامپت» به «تأیید وضعیت» تغییر می‌دهد. برای توسعه‌دهنده، این یعنی صرف ۱۰ دقیقه در هر بازبینی برای جلوگیری از ساعت‌ها بازسازی جنایی و فارنزیک در یک حادثه ساعت ۲ صبح.
برای کسب‌وکار، این متد ایمنی را از یک ادعای کیفی به یک دارایی کمی تبدیل می‌کند. با متصل کردن بررسی‌های ایمنی به کامیت‌های Git، دفترچه شواهد مسیری ایجاد می‌کند که هم بازرسی‌های امنیتی داخلی و هم تقاضاهای نظارتی آینده را پاسخ می‌دهد.
شروع کنید و ابتدا تست کلید توقف (Kill-switch) را پیاده‌سازی کنید. این محتمل‌ترین مکانیزمی است که تأخیرهای پیش‌بینی‌نشده در حلقه اجرای عامل شما را آشکار می‌کند.
گام بعدی شما
- تست کلید توقف (Kill-switch) را در حین اجرای عملیات واقعی پیاده‌سازی کنید؛ این سریع‌ترین راه برای کشف تأخیرهای پیش‌بینی‌نشده در حلقه اجرای عامل شماست.
- یک فایل
EVIDENCE.mdساده در ریشه مخزن کد خود ایجاد کرده و اولین جدول «لیست مجاز ابزارها» را با هش کامیت‌ها پر کنید. - در اولین حادثه فنی بعدی، پنجره مواجهه (Exposure Window) را با دقت ثانیه‌ای ثبت کنید تا استانداردهای گزارش‌دهی تیمتان ارتقا یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو