ZTAI برای عامل‌های خودکار؛ اختیار محدود در تمام مسیر اجرا

عامل مأمور شده است گزارش تعمیرات یک کارخانه را بررسی کند و برای تجهیزات پرخطر، درخواست بازدید بسازد. در یکی از گزارش‌ها، جمله‌ای می‌بیند که می‌گوید برای تکمیل تحلیل، سوابق را به یک نشانی بیرونی بفرستد. ممکن است مدل این جمله را دستور معتبر تشخیص دهد؛ ممکن است هم آن را کنار بگذارد. معماری امنیتی نمی‌تواند تمام مسئولیت حفاظت را به همین تشخیص بسپارد. پرسش مهم‌تر این است: حتی اگر عامل بخواهد چنین کاری کند، آیا ابزار، اعتبارنامه و مسیر لازم برای انجام آن را دارد؟

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

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

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

عامل پیشنهاد می‌کند؛ محیط درباره اجازه اجرا تصمیم می‌گیرد

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

این منطق با مبنای NIST SP 800-207، منتشرشده در اوت ۲۰۲۰ سازگار است: قرارگرفتن در شبکه داخلی یا تعلق داشتن به سازمان، به‌خودی‌خود اعتماد ایجاد نمی‌کند. در معماری پیشنهادی این یادداشت، همین اصل را به هویت عامل، ابزارها و وضعیت هر مأموریت اعمال می‌کنیم. آنچه در ادامه می‌آید، صورت‌بندی طراحی برای این کاربست است، نه نقل یک نسخه آماده از استاندارد.

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

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

هویت مستقل، اختیار وابسته به مأموریت

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

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

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

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

در هر دو حالت، اختیار مؤثر از ترکیب محدودکننده سیاست سازمان، مجوز مأموریت، اختیار سرویس، سیاست منبع و وضعیت جاری اجرا به دست می‌آید. حق پردازش، حق مشاهده نتیجه و حق اقدام بر مبنای نتیجه، باید جداگانه تعیین شوند.

واگذاری کار نباید کارخانه تولید مجوز باشد

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

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

RFC 8693، پروتکل OAuth 2.0 Token Exchange، میان واگذاری با حفظ هویت عامل و عمل‌کردن به جای هویت دیگر تمایز می‌گذارد و امکان نمایش زنجیره واگذاری را فراهم می‌کند. اما این پروتکل به‌تنهایی کاهش اختیار یا لغو خودکار همه توکن‌های مشتق‌شده را تضمین نمی‌کند. سیاست صدور و انتشار رویداد لغو، مسئولیت پیاده‌سازی است.

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

هر عملیات، بیرون از مدل کنترل می‌شود

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

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

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

جدول زیر مرزهای پیشنهادی را به آزمون قابل اجرا تبدیل می‌کند. این‌ها معیار پذیرش معماری‌اند، نه صرفاً گزینه‌هایی در تنظیمات مدل.

در RAG، مجوز باید همراه سند بماند

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

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

در مستندات کنترل دسترسی سطح سند Azure AI Search، نگهداری فراداده مجوز و کنترل هنگام پرس‌وجو از هم تفکیک شده‌اند. بخشی از قابلیت‌های بومی با API پیش‌نمایش 2026-08-01-preview ارائه می‌شوند. کنترل هنگام پرس‌وجو، مجوز کاربر را با فراداده ذخیره‌شده در نمایه تطبیق می‌دهد؛ بنابراین تا وقتی تغییر مجوز منبع به نمایه نرسیده باشد، کنترل بر پایه وضعیت قدیمی انجام می‌شود. زمان همگام‌سازی مجوزها بخشی از زمان مؤثر لغو دسترسی است.

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

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

حافظه نباید دسترسی دیروز را به حق امروز تبدیل کند

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

در سیاست پیشنهادی، هر حافظه مشتق‌شده باید تا حد لازم منشأ و وابستگی خود را حفظ کند. کلید کش باید قلمرو سازمانی، زمینه دسترسی و نسخه‌های مؤثر سیاست و داده را لحاظ کند. اشتراک‌گذاری کش میان کاربران تنها زمانی پذیرفتنی است که برابری مجوز آن خروجی احراز شود. یکسان‌بودن متن پرسش چنین برابری‌ای را نشان نمی‌دهد.

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

همه مشتقات را هم نمی‌توان به‌سادگی به یک سند برگرداند. اگر خلاصه‌ای منشأ دقیق ندارد، راه محافظه‌کارانه ممکن است کنارگذاشتن کل آن خلاصه باشد. نگهداری کمتر و کوتاه‌تر، مسئله ابطال را ساده‌تر می‌کند. حافظه دائمی نباید پیش‌فرض هر عامل باشد.

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

MCP اتصال را استاندارد می‌کند، نه اعتماد را

MCP می‌تواند ابزارها و منابع را با رابط مشترک در اختیار عامل قرار دهد؛ اما اتصال موفق به یک سرور به معنی مجازبودن همه عملیات آن نیست. نام و شرح ابزار هم سند صلاحیت امنیتی نیستند.

در بخش Authorization مشخصات MCP با نسخه ۲۸ ژوئیه ۲۰۲۶، دامنه سازوکار مجوزدهی، انتقال مبتنی بر HTTP است و اعتبار توکن برای سرور مقصد اهمیت دارد. این سازوکار را نباید بدون تمایز به اجرای محلی stdio تعمیم داد. راهنمای رسمی Security Best Practices نیز عبور توکن نامتناسب به سرویس پایین‌دست، سوءاستفاده از نماینده و اجرای محلی با اختیار زیاد را بررسی می‌کند.

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

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

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

بودجه فقط تعداد توکن نیست؛ اثر عمل را هم محدود کنیم

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

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

حسابداری باید در کل مأموریت و شاخه‌های آن مشترک باشد. پیش از اجرای موازی، سهم لازم رزرو شود تا چند درخواست هم‌زمان نتوانند همگی موجودی یکسان را قابل مصرف ببینند. retry باید به نتیجه قبلی وابسته باشد و در عملیات پشتیبانی‌شده از کلید یکتای عمل استفاده کند؛ timeout به معنی شکست قطعی عملیات بیرونی نیست.

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

توقف، لغو و بازگشت سه قابلیت متفاوت‌اند

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

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

بازگشت نیز همیشه ممکن نیست. پیش‌نویس را می‌توان حذف کرد؛ برخی تغییرات داده را می‌توان با کنترل هم‌زمانی برگرداند؛ اما ایمیل ارسال‌شده، اطلاعات افشاشده یا اثر فیزیکی بر ماشین، با بازگرداندن snapshot سامانه عامل خنثی نمی‌شود. برای این موارد، باید اقدام جبرانی و فرایند رسیدگی داشت و حتی‌الامکان پیش از اثر برگشت‌ناپذیر، محدودیت قوی‌تری اعمال کرد.

در محیط صنعتی، توقف امن الزاماً قطع فوری همه اجزا نیست. ممکن است تجهیزات به توالی ایمن توقف نیاز داشته باشند. عامل زبانی نباید بتواند قفل‌های ایمنی مستقل یا سامانه کنترل صنعتی را دور بزند. وضعیت امن باید پیشاپیش با مسئول فرایند تعریف شود، نه در لحظه بحران توسط مدل.

اگر سرویس سیاست یا ثبت شواهد ضروری از دسترس خارج شد، ادامه عملیات حساس بدون کنترل پذیرفتنی نیست. برای نیازهای تداوم، مسیر جایگزین باید از قبل با اختیار و مدت محدود طراحی شود. «برای اینکه کار نخوابد» نباید دلیل دائمی کنارگذاشتن مرز حفاظت باشد.

ناظر شواهد، نه تماشاگر همه داده‌ها

حذف مشاهده روزمره داده، مسئولیت انسان را حذف نمی‌کند. ناظر باید بتواند مأموریت، نسخه سیاست، دامنه اختیار، رخدادهای ردشده، میزان مصرف و نتیجه عملیات را بررسی کند. برای این کار معمولاً لازم نیست کل پرامپت، اسناد بازیابی‌شده و پاسخ خام ابزارها در یک داشبورد عمومی جمع شوند.

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

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

ارزیابی مستقل؛ عامل داور موفقیت خودش نیست

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

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

پژوهش AgentDojo، نسخه سوم در ۲۴ نوامبر ۲۰۲۴، محیطی برای سنجش عامل‌های ابزارمحور در مواجهه با داده نامطمئن ارائه می‌کند. نکته قابل استفاده برای ما، ارزیابی توأمان انجام کار و مقاومت در برابر حمله است. سامانه‌ای که همه درخواست‌ها را رد می‌کند ممکن است خروج غیرمجاز نداشته باشد، اما مأموریت را هم انجام نمی‌دهد.

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

بازخورد، ورودی نامطمئن چرخه بعدی است

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

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

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

برای صورت‌بندی تهدیدها می‌توان از رده‌بندی یادگیری ماشین خصمانه NIST AI 100-2 E2025، منتشرشده در مارس ۲۰۲۵ کمک گرفت. کاربرد آن در اینجا، جداکردن منشأ حمله، مرحله اثرگذاری و توان مهاجم است؛ نه اینکه هر بازخورد نادرست را بدون بررسی «مسموم‌سازی» بنامیم.

از سناریوی تعمیرات تا معیار پذیرش

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

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

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

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

تحولات تازه چه چیزی را تأیید می‌کنند؟

OWASP Top 10 for Agentic Applications 2026، منتشرشده در ۹ دسامبر ۲۰۲۵، امنیت عامل‌های دارای توان برنامه‌ریزی و اقدام را به صورت موضوعی مستقل صورت‌بندی کرده است. در ۱ سپتامبر ۲۰۲۶ نیز صفحه Agent Control Standard یا ACS در پروژه OWASP منتشر شده که بر نقاط اتصال کنترلی و اعمال سیاست در زمان اجرا تمرکز دارد. این‌ها شاهد توجه فنی به کنترل عامل‌اند؛ نه گواهی تحقق تعریف فرایندمحور ZTAI یا تضمین امنیت یک محصول.

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

خودکارسازی را با رهاکردن اختیار اشتباه نگیریم

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

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

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