۵ دسته‌بندی پاسخ منفی برای جلوگیری از بداهه‌پردازی عامل‌های هوش مصنوعی

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

به نقل از راهنمای فنی منتشر شده در dev.to در ۲ سپتامبر ۲۰۲۶، صنعت هوش مصنوعی در حال حاضر فاقد یک روش ماشین‌خوان برای تعریف محدودیت‌ها است. در واقع، سرورها راهی قطعی ندارند تا به عامل (Agent) — شبیه به کارمندی که دستورات را اجرا می‌کند اما مرزهای قانونی شرکت را نمی‌شناسد — بگویند چرا یک اقدام خاص ممنوع است. صنعت به یک روش دترمینیستیک (قطعی) نیاز دارد تا سرورها بتوانند دقیقاً دلیل ممنوعیت یک عمل را به عامل منتقل کنند.

اکثر یکپارچه‌سازی‌های فعلی بر اساس لیست ابزارها، اسناد OpenAPI یا شماهای MCP تعریف می‌شوند. این رویکرد تبدیل مستندات به ابزارهای اجرایی گام اول در فعال‌سازی عامل‌هاست، اما همچنان ابهامات امنیتی را به همراه دارد. عامل اقداماتی مثل search (جست‌وجو)، create_order (ایجاد سفارش)، send_message (ارسال پیام) یا refund (استرداد وجه) را می‌بیند و بر اساس آن‌ها برنامه‌ریزی می‌کند. اما این رویکرد یک ابهام خطرناک ایجاد می‌کند: اگر ابزاری در لیست نباشد، عامل نمی‌داند که آیا آن قابلیت اصلاً در این سطح در دسترس نیست، نیاز به احراز هویت سطح بالاتر دارد یا به‌طور کلی ممنوع است.

ابهام در ابزارهای مفقود

برای درک بهتر، یک MCP خرید ناشناس را در نظر بگیرید که تنها یک ابزار product search (جست‌وجوی محصول) را ارائه می‌دهد. یک کلاینت دقیق ممکن است استنباط کند که نمی‌تواند سفارش ثبت کند، اما سوالات حیاتی همچنان باقی می‌مانند:

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

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

برای حل این مشکل، چارچوبی پیشنهاد شده که پنج دسته‌بندی از «نه» یا پاسخ منفی را معرفی می‌کند تا رفتارهای بازیابی متفاوتی را فعال کند:

پنج دسته‌بندی پاسخ منفی

• ناموجود (Unavailable): قابلیت در این رابط وجود ندارد. مثال: یک نقطه اتصال (Endpoint) اکتشافی ناشناس می‌تواند جست‌وجو کند اما نمی‌تواند وجهی را جابه‌جا کند یا سفارش ایجاد کند. راهکار بازیابی: هدایت کاربر به یک رابط کاربری دیگر.
• محدود به سطح دسترسی (Scope-gated): قابلیت وجود دارد اما هویت فعلی مجوزهای لازم را دریافت نکرده است. سرورها باید به‌طور پیش‌فرض حالت «رد کردن» داشته باشند، به‌جای اینکه عامل‌های ناشناس را به‌طور گسترده مورد اعتماد قرار دهند. راهکار بازیابی: درخواست مجوز (Authorization).
• محدودیت نرخ (Rate-limited): اقدام در چارچوب یک بودجه مشخص مجاز است. محدودیت، واحد و پاسخ شکست باید قابل پیش‌بینی باشد تا کلاینت به‌جای تلاش‌های تهاجمی، متوقف شود. راهکار بازیابی: انتظار.
• ممنوع (Forbidden): رفتارهایی که فارغ از هر راحتی یا ضرورتی، به‌طور دائمی غیرمجاز هستند؛ مواردی مانند جعل هویت، فراتر رفتن از محدوده اعلام شده، بازفروشی داده‌های کاربر یا بازسازی گراف پروفایل‌های بین‌کاربری از طریق خواندن پروتکل‌ها. راهکار بازیابی: توقف کامل.
• نیازمند تایید انسانی (Human-gated): اقداماتی که پیامدهای آن‌ها بسیار زیاد است و محدوده دسترسی تفویض شده نمی‌تواند آن‌ها را نادیده بگیرد؛ مانند داوری، ابطال کلید، حذف حساب یا برداشت‌های کلان مالی. این موارد نیاز به یک مراسم تایید انسانی تازه دارند. راهکار بازیابی: ارجاع دقیق اقدام به انسان برای تایید نهایی.

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

مستندات به تنهایی ابزار اجرایی نیستند. یک فایل «فضای منفی» تنها زمانی مفید است که با رفتار زمان اجرا (Runtime) مطابقت داشته باشد. قوی‌ترین نسخه این سیستم، مرزهای اعلام‌شده را به مکانیسم‌های اجرایی متصل می‌کند: محدوده‌های نوشتاری نام‌گذاری شده به مسیرهای (Routes) واقعی متصل می‌شوند، نوشته‌های تعریف‌نشده به‌طور پیش‌فرض با شکست مواجه می‌شوند (Fail Closed) و سقف‌های نرخ، کدهای خطای پایداری تولید می‌کنند. این امر سند را به یک سطح یکپارچه‌سازی تبدیل می‌کند که قابل تست است.

پلتفرم WebAZ این سیستم قرارداد دوگانه را پیاده کرده است. این پلتفرم تا تاریخ ۲ سپتامبر ۲۰۲۶، نسخه ۰.۱.۳۷ و شمای ۴۹ را گزارش کرده است. WebAZ یک نقشه قابلیت‌های مثبت را در آدرس https://webaz.xyz/.well-known/webaz-capabilities.json منتشر می‌کند که محدوده‌های خواندن و عملیات‌های ایمن بدون نیاز به مجوز را توصیف می‌کند.

در کنار این، یک فایل اختصاصی به نام webaz-negative-space.json منتشر می‌کند. در این فایل، رفتارهای ممنوعه، محدودیت‌های دسترسی متقاطع و اقدامات انبوه، و همچنین پیامدهای سوءاستفاده‌های مکرر به‌طور صریح لیست شده‌اند. این تفکیک دقیق بین آماده‌سازی درخواست و تایید نهایی به پلتفرم اجازه می‌دهد تا ریسک‌های عملیاتی را پیش از وقوع کاهش دهد. این فایل شامل یک «قانون آهنین» است: برخی اقدامات حساس، فارغ از سطح دسترسی اعلام شده، حتماً به تایید زنده WebAuthn نیاز دارند.

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

برای توسعه‌دهندگان، این یعنی تفاوت بین عاملی که «بهترین تلاشش را می‌کند» و عاملی که «قابل اعتماد» است. یک عامل تنها زمانی واقعاً قابل اتکا است که بتواند دقیقاً توضیح دهد چرا متوقف شده است.

یک تست عملی برای سازندگان عامل

اگر در حال ساخت یک سرور MCP یا API برای عامل‌ها هستید، سیستم خود را با این سوالات بازرسی کنید:

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

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

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