۹ لایهٔ دفاعی برای جلوگیری از فجایع عامل‌های هوش مصنوعی

تصور کنید یک عامل پشتیبانی، تیکت مشتری را می‌خواند و تصمیم می‌گیرد مبلغ اشتراک سالانه را به‌جای یک افزونهٔ ۱۲ دلاری، به‌طور کامل بازگرداند. این سناریو که در راهنمای ۵ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شده، یک شکست بحرانی در استقرار عامل‌های هوش مصنوعی را نشان می‌دهد: مدل کرش نکرد و API به‌درستی کار کرد، اما تصمیم اتخاذ شده فاجعه‌بار بود. ابزار دقیقاً همان‌طور که طراحی شده بود عمل کرد، اما نتیجه یک شکست در محیط عملیاتی (Production) بود.

بسیاری از توسعه‌دهندگان می‌پرسند چگونه می‌توان جلوی تصمیمات غلط مدل را گرفت، اما سؤال درست این است که کدام لایهٔ قطعی (Deterministic) باید پیش از تبدیل شدنِ اشتباه به خسارت، آن را متوقف می‌کرد. در فضای فعلی هوش مصنوعی عامل‌محور (Agentic AI)، تلقی کردن پرامپت سیستمی به‌عنوان یک مرز امنیتی، یک خطای معماری بنیادین است. عامل‌ها به روش‌های مختلفی شکست می‌خورند: درک نادرست قصد کاربر، طراحی برنامه‌های خطرناک، ارسال آرگومان‌های اشتباه، تخطی از دسترسی‌ها، افتادن در حلقه‌های تکرار، نشت داده‌ها یا انجام اقدامات جبران‌ناپذیر.

با تکیه بر تغییر رویکرد صنعت به سمت استفاده خودمختار از ابزارها، این چارچوب استدلال می‌کند که پرامپت‌ها دستورالعمل‌هایی احتمالی هستند، نه مرزهای اجرایی. اگر مورد امنیتی شما به این وابسته است که مدل جمله‌ای مانند «هرگز داده‌های مشتری را پاک نکن» را رعایت کند، شما در واقع هیچ مورد امنیتی ندارید؛ شما فقط «امیدوارید» که مدل دستور را اجرا کند. یک مدل ایمنی درست، شبیه به مجموعه‌ای از دروازه‌هاست که هرچه اقدام به آسیب جبران‌ناپذیر نزدیک‌تر شود، لایهٔ توقف باید قطعی‌تر و سخت‌گیرانه‌تر باشد.

دروازه‌های اولیه: کاهش نرخ خطا

نخستین خط دفاعی، لایهٔ پرامپت است. وظیفه این لایه هدایت و ترغیب است، نه اجبار. پرامپت‌ها برای تعیین لحن و اولویت‌ها مفیدند، اما هرگز نباید به‌عنوان لایهٔ کنترل استفاده شوند. طبق مستندات dev.to، مسئولیت‌های درست لایهٔ پرامپت عبارتند از:

• تبیین نقش عامل و ترتیب ترجیحی تصمیم‌گیری.
• تعیین زمان‌هایی که عامل باید برای شفاف‌سازی سؤال بپرسد.
• ترغیب عامل به استفاده از ابزارهای «فقط‌خواندنی» پیش از ابزارهای «نوشتنی».
• ارائه نمونه‌هایی از استدلال‌های ایمن و ناایمن.
• توضیح نحوه ارائه عدم قطعیت (Uncertainty) توسط مدل.

در مقابل، پرامپت‌ها هرگز نباید مسئول جداسازی مستاجران (Tenant Isolation)، احراز هویت، مسدود کردن بازگشت وجه‌های بالاتر از یک آستانه مشخص، یا تضمین عدم نشت اسرار (Secrets) باشند. یک پرامپت سیستمی معقول ممکن است شامل زمینهٔ سیاست‌ها باشد — مثلاً دستور به عامل برای توقف و درخواست بازبینی انسانی اگر نتیجه ابزار عبارت «approval_required» را برگرداند — اما این یک هدایت است، نه یک مرز. اگر یک تحلیل پس از حادثه با جمله «مدل پرامپت را نادیده گرفت» به پایان می‌رسد، شکست واقعی این است که پرامپت به‌عنوان یک مرز امنیتی در نظر گرفته شده بود.

در مرحله بعد، لایهٔ قصد (Intent Layer) قرار دارد. این لایه درخواست کاربر را پیش از شروع برنامه‌ریزی، به یک شیء تایپ‌شده تبدیل می‌کند. برای مثال، اگر کاربر بخواهد «رکورد‌های قدیمی تست را پاک کند»، مدل ممکن است «قدیمی» را به معنای «بیش از یک روز» تفسیر کرده و جدول کاربران واقعی در محیط Production را هدف قرار دهد. در اینجا، فراخوانی ابزار و دسترسی‌ها ممکن است معتبر باشند، اما مأموریت اشتباه است.

با شناسایی کلاس ریسک و محدوده (مثلاً «سراسری» در برابر «تک‌رکورد»)، سیستم می‌تواند مأموریت‌های پرریسک را فوراً به تأیید انسانی بفرستد. یک شیء قصد باید موارد زیر را ثبت کند:

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

قوانین مسیریابی برای این اشیاء باید قطعی باشند. برای مثال، هر قصدی با محدوده «سراسری» و سطح ریسکی غیر از «کم»، باید مستقیماً به مسیر require_human_scoping هدایت شود. یک قصد اشتباه که در این مرحله شناسایی شود تقریباً هیچ هزینه‌ای ندارد؛ اما قصدی که پس از سه فراخوانی ابزار شناسایی شود، ممکن است پیش از آن وضعیت دیتابیس را تغییر داده باشد. کلمه «سراسری» (Global) خطرناک‌ترین کلمه در عملیات عامل‌هاست؛ اگر عامل نتواند مجموعه اثرگذاری را دقیقاً توصیف کند، نباید اجازه تغییر در هیچ چیزی را داشته باشد.

سپس لایهٔ برنامه‌ریزی (Planning Layer) می‌آید که مسیرهای ممنوعه را رد می‌کند. حتی اگر تک‌تک فراخوانی‌های ابزار معتبر باشند، توالی آن‌ها می‌تواند از نظر عملیاتی خطرناک باشد؛ مثلاً توالی «لیست همه کاربران» و بلافاصله «حذف کاربر». اعتبارسنجی در سطح ابزار کافی نیست زیرا برخی اشتباهات تنها از ترکیب ابزارها ظاهر می‌شوند.

اعتبارسنجی برنامه باید موارد زیر را بررسی کند:

• توالی‌های ممنوعه (مثلاً read_ticket و بلافاصله send_external_email یا search_orders و سپس bulk_refund_orders).
• تعداد بیش از حد رکوردهای اثرپذیر یا ارتقای عملیات از یک رکورد به تعداد زیاد.
• نبود گام‌های «اجرای آزمایشی» (Dry-run) برای اقدامات تخریبی (مثلاً یک بازگشت وجه دسته‌جمعی باید با یک Dry-run شروع شود).
• عملیات نوشتن (Write) که بدون خواندن (Read) قبلی رخ می‌دهد.
• اقداماتی که جریان‌های تأیید (Approval Workflows) تعیین‌شده را دور می‌زنند.

مرزهای سخت: جلوگیری از فاجعه

لایهٔ قرارداد ابزار (Tool Contract Layer) باعث می‌شود اقدامات نامعتبر، اساساً غیرقابل‌نمایش باشند. به‌جای استفاده از ابزارهای کلی مثل run_sql — که در واقع یک مفسر و یک ریسک بزرگ است — توسعه‌دهندگان باید از ابزارهای محدود و تایپ‌شده استفاده کنند. اگر ابزاری اجازه نمایش یک اقدام فاجعه‌بار را بدهد، مدل بالاخره راهی برای نمایش آن پیدا می‌کند.

به‌عنوان مثال، به‌جای run_sql(query: str)، باید از ابزاری مثل archive_inactive_users استفاده کرد که با یک مدل Pydantic محدودیت‌های زیر را اعمال می‌کند:

• محدودیت‌های بازه (مثلاً inactive_days بین ۳۰ تا ۳۶۵۰ روز).
• الزام به ارائه tenant_id و محدودیت تعداد (limit) بین ۱ تا ۱۰۰.
• فعال بودن پیش‌فرض dry_run=True برای عملیات تخریبی.
• الزام به ارائه فیلد «دلیل» (Reason) بین ۱۰ تا ۵۰۰ کاراکتر برای قابلیت حسابرسی.

قراردادهای ابزار خوب از Enumها به‌جای متن‌های آزاد برای نام عملیات استفاده می‌کنند و نتایج خطای ساختاریافته‌ای ارائه می‌دهند که عامل بتواند آن‌ها را درک کند. اگر یک عامل می‌تواند دستورات دلخواه Shell یا درخواست‌های HTTP بنویسد، شما لایه ابزار نساخته‌اید، بلکه یک مفسر ساخته‌اید.

احراز هویت (Authorization) باید در مسیر اجرای ابزار رخ دهد، نه در استدلال مدل. اعتماد مدل به خودش، احراز هویت نیست. اگر یک پیمانکار پشتیبانی فقط اجازه بازگشت ۲۵ دلار را دارد، سیستم باید بازگشت ۱۲۰۰ دلاری را مسدود کند، فارغ از اینکه مدل چقدر به تصمیمش اطمینان دارد.

تصمیم سیاست احراز هویت باید موارد زیر را در نظر بگیرد:

• بازیگر (Actor) کیست و به کدام مستاجر (Tenant) تعلق دارد؟
• روی کدام منبع اقدام می‌شود و آیا آن منبع در وضعیتی است که اجازه این اقدام را بدهد (مثلاً آیا وضعیت سفارش «تحویل شده»، «مرجوع شده» یا «شکست خورده» است)؟
• محیط عملیاتی Production است، Staging است یا Development؟
• مقدار، محدوده یا شعاع تخریب (Blast Radius) این اقدام چقدر است؟

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

کنترل‌های اجرا (Execution Controls) اثرات جانبی را «پیش‌بینی‌پذیر» می‌کنند. این لایه از کلیدهای Idempotency برای جلوگیری از نوشتن تکراری داده‌ها و سقف‌های سخت برای اندازه دسته‌ها استفاده می‌کند. بسیاری از اشتباهات تولیدی، نه دراماتیک، بلکه تکرار پرداخت‌ها یا ایمیل‌های مکرر به دلیل تلاش مجدد (Retry) هستند.

اجرای ایمن نیازمند موارد زیر است:

• کلیدهای Idempotency و مرزهای تراکنشی برای اطمینان از اینکه یک Retry باعث ایجاد سه تیکت به‌جای یک تیکت نشود.
• محدودیت‌های نرخ (Rate limits)، بودجه‌های هزینه و Timeoutها.
• رکوردهای حسابرسی (Audit) که وضعیت قبل و بعد از تغییر را ثبت می‌کنند.

برای مثال، یک ابزار آرشیو دسته‌جمعی باید سقف سخت ۱۰۰ رکورد در هر اجرا داشته باشد تا شعاع تخریب محدود شود. اشتباهی که یک رکورد را تحت تأثیر قرار دهد یک حادثه است؛ اما اشتباهی که یک میلیون رکورد را تغییر دهد، می‌تواند منجر به نابودی شرکت شود.

ترمزهای نهایی: نظارت و بازبینی

لایهٔ خروجی (Output Layer) نتایج مضر را پیش از ارسال متوقف می‌کند. این شامل اسکن برای نشت داده‌های حساس (PII) در ایمیل‌ها یا مسدود کردن دستورات تغییر ساختار دیتابیس (DDL) در SQL تولیدشده است. کنترل‌های خروجی بسته به نوع داده متفاوت‌اند:

• متن: بررسی برای افشای اسرار، داده‌های حساس، تعهدات ممنوعه (مثل «ضمانت بازگشت وجه») یا ادعاهای پشتیبانی‌نشده.
• کد: مسدود کردن تماس‌های شبکه، دسترسی به فایل‌سیستم یا اجرای Shell؛ اجرا در محیط ایزوله (Sandbox) و محدود کردن وابستگی‌ها.
• SQL: اجازه دادن فقط به دستورات خواندنی؛ رد کردن DDL/DML مگر در صورت مجوز؛ الزام به وجود LIMIT محدود و اعتبارسنجی در برابر یک Schema شناخته‌شده.

ناظران زمان اجرا (Runtime Monitors) شکست‌های «آهسته» را متوقف می‌کنند؛ الگوهایی مثل حلقه‌های بی‌نهایت یا هزینه‌های تصاعدی که در یک گام واحد قابل مشاهده نیستند. یک عامل ممکن است یک ابزار جستجو را فراخوانی کند، نتیجه‌ای نگیرد، عبارت را تغییر دهد و این کار را ۲۵ بار تکرار کند و بدون رسیدن به پاسخ، گران و کند شود.

یک ناظر باید موارد زیر را ردیابی کند:

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

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

در نهایت، لایهٔ تأیید انسانی (Human Approval Layer) از ریسک‌های نامتقارن محافظت می‌کند. برای اقدامات جبران‌ناپذیر — مثل ایمیل زدن به ۲۰۰۰ مشتری یا تغییر تنظیمات صورت‌حساب — بازبینی انسانی تنها دروازه پذیرفتنی است. برخی اشتباهات ارزان تمام می‌شوند، اما پیامی غلط که برای هزاران نفر ارسال شده، قابل بازگشت نیست.

تأیید انسانی باید در موارد زیر الزامی باشد:

• اقدام خارجی باشد (ایمیل، SMS، پرداخت، پست عمومی، فراخوانی API شریک).
• اقدام بر تعداد زیادی رکورد اثر بگذارد (مثلاً بیش از ۱۰ رکورد) یا بالاتر از یک آستانه پولی باشد (مثلاً ۵۰ دلار).
• اقدام باعث تغییر در دسترسی‌ها، تنظیمات امنیتی یا زیرساخت شود.
• اعتماد مدل پایین باشد اما شعاع تخریب بالا باشد.

برای جلوگیری از خستگی از تأییدات (Approval Fatigue) و تأییدات بدون بررسی، درخواست باید شامل استدلال عامل، شواهد پشتیبان، اثر مورد انتظار و جایگزین بازگشت‌پذیر باشد.

چارچوب تصمیم‌گیری برای ایمنی

طبق تحلیل dev.to، بهترین لایه توقف، اولین لایه قطعی است که قادر به جلوگیری از آسیب باشد. این چارچوب شکست‌ها را به حالت‌های متمایز تقسیم می‌کند:

• قصد اشتباه: (مثلاً کاربر اطلاعات می‌خواهد، عامل داده‌ها را تغییر می‌دهد) $
  ightarrow$ بهترین توقف توسط طبقه‌بندی قصد.
• برنامه خطرناک: (مثلاً لیست همه رکوردها و سپس حذف آن‌ها) $
  ightarrow$ بهترین توقف توسط اعتبارسنجی برنامه.
• آرگومان‌های نامعتبر: (مثلاً عامل all=true یا فیلتر خالی می‌فرستد) $
  ightarrow$ بهترین توقف توسط Schemaهای ابزار.
• اقدام غیرمجاز: (مثلاً عامل سفارشی را بازمی‌گرداند که نباید لمس کند) $
  ightarrow$ بهترین توقف توسط سیاست‌های احراز هویت.
• اقدام بیش از حد گسترده: (مثلاً عامل ۱۰۰,۰۰۰ ردیف را به‌روزرسانی می‌کند) $
  ightarrow$ بهترین توقف توسط محدودیت‌های محدوده + Dry-run.
• خروجی مضر: (مثلاً عامل PII را در ایمیل لو می‌دهد) $
  ightarrow$ بهترین توقف توسط اعتبارسنجی خروجی.
• حلقه runaway: (مثلاً عامل ۳۰ بار یک ابزار شکست‌خورده را تکرار می‌کند) $
  ightarrow$ بهترین توقف توسط ناظران زمان اجرا.
• اقدام جبران‌ناپذیر: (مثلاً عامل به مشتریان ایمیل می‌زند یا داده‌ها را پاک می‌کند) $
  ightarrow$ بهترین توقف توسط تأیید انسانی.
• توهم مدل: (مثلاً عامل یک سیاست یا حقیقت مشتری را اختراع می‌کند) $
  ightarrow$ بهترین توقف توسط Grounding + تأیید.

این رویکرد لایه‌ای تضمین می‌کند که لایه‌های اولیه نرخ اشتباهات را کاهش دهند، در حالی که لایه‌های نهایی شدت آن‌ها را کم می‌کنند. اگر فقط روی لایه‌های اولیه سرمایه‌گذاری کنید، از شکست‌ها غافلگیر خواهید شد. اگر فقط روی لایه‌های نهایی سرمایه‌گذاری کنید، عامل شما به ابزاری بی‌فایده و مسدود شده تبدیل می‌شود.

برای توسعه‌دهندگان، اولویت روشن است: اقدامات خطرناک را غیرقابل‌نمایش، اقدامات غیرمجاز را غیرقابل‌اجرا و اقدامات پرریسک را نیازمند تأیید صریح انسانی کنید. مدل خلاق‌ترین بخش عامل است، اما هرگز نباید قابل‌اعتمادترین بخش باشد.

برای پیاده‌سازی این مدل، با بازبینی مجموعه ابزارهای فعلی خود شروع کنید. هرگونه مفسر کلی (مانند SQL خام یا دسترسی Shell) را با توابع محدود و تایپ‌شده جایگزین کنید که مرزها را در سطح کد اعمال می‌کنند. وظیفه سیستم این است که اجازه دهد مدل استدلال کند، در حالی که مطمئن شود اشتباهاتش کوچک، قابل مشاهده و بازگشت‌پذیر باقی می‌مانند.

گام بعدی شما

• مجموعه ابزارهای فعلی خود را بازبینی کنید و هرگونه مفسر کلی (مانند دسترسی مستقیم به SQL یا Shell) را با توابع محدود و تایپ‌شده جایگزین کنید.
• برای هر عملیات تخریبی، لایهٔ اجباری dry_run و سقف تعداد رکوردها (Blast Radius) را پیاده‌سازی کنید.
• یک ماتریس ریسک برای ابزارهای خود ترسیم کنید تا مشخص شود کدام اقدامات نیاز به تأیید انسانی دارند.

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