منبع رسمی چه چیزی اعلام کرده است؟
مایکروسافت در مطلب رسمی ۱۹ اکتبر ۲۰۲۶، برابر با ۲۷ مهر ۱۴۰۵، گسترش Project Perception برای کنترل Agentهای داخلی را توضیح داد. این اعلامیه از Guardian Agents، اختیار محدود به وظیفه و تغییر کنترل‌ها با تغییر ریسک صحبت می‌کند. نکتهٔ اصلیِ قابل نقل، جدا نگه‌داشتن مرجع اختیار از خود مدل است.
تاریخ آماده‌سازی این گزارش در آیوان، ۳ آبان ۱۴۰۵ است و با تاریخ رویداد یکی نیست. نام‌ها و قابلیت‌های بالا، توصیف اعلام رسمی مایکروسافت‌اند؛ این گزارش ارزیابی مستقل محصول یا اعلام عمومی‌بودن همهٔ اجزای آن در تمام اشتراک‌ها و مناطق نیست. بخش‌های بعد، تحلیل تحریریه و یک تمرین پیشنهادی برای تیم‌های سازمانی هستند.
چرا حساب کاربر و اختیار Agent را یکی نگیریم؟
فرض کنید کارشناس نگه‌داری هم کاتالوگ تجهیزات را می‌بیند و هم اجازهٔ ثبت سفارش قطعه دارد. دستیارِ جست‌وجوی راهنما برای کار فعلی فقط به خواندن چند سند نیاز دارد. اگر همهٔ اختیارهای صاحب حساب به ابزار دستیار منتقل شود، یک وظیفهٔ خواندن می‌تواند دامنهٔ اثر بسیار بزرگ‌تری پیدا کند.
پیشنهاد تحریریه این است که برای هر کاربرد، هدف، ابزار لازم و عملیات خارج از دامنه را روی یک برگه بنویسید. مالک کاربرد و مسئول قطع دسترسی مشخص باشند. هویت مستقل زمانی ارزش دارد که به این قرارداد عملی متصل شود؛ داشتن یک نام یا شناسهٔ جدا بدون محدودیت اجرا، به‌تنهایی شاهد کنترل نیست.
قانون باید در ابزار و زیرساخت هم اجرا شود
در تمرین پیشنهادی، Prompt به دستیار می‌گوید کارش خواندن راهنماست، اما کنترل اصلی در ابزار جست‌وجو و مسیر داده اعمال می‌شود. اگر متن یک سند از دستیار بخواهد سفارش ثبت کند، ابزار سفارش اصلاً نباید در اختیار این وظیفه باشد. این تفاوت میان توضیح رفتار مطلوب و اعمال اختیار مجاز است.
فهرست ابزارها، دامنهٔ منابع و پارامترهای مجاز را با مسیر واقعی اجرا مقایسه کنید. یک اتصال مخفیِ حساب سرویس یا مسیر جایگزین می‌تواند قرارداد ظاهری را بی‌اثر کند. برای شروع، یک سناریوی محدود را انتهابه‌انتها بررسی کنید؛ تعداد بیشتر کنترل‌های نام‌برده در معماری، جای آزمون همان مسیر را نمی‌گیرد.
تغییر ریسک لزوماً یک پاسخ دوحالتی ندارد
در طرح پیشنهادیِ تعمیرات، مشاهدهٔ رفتار غیرعادی می‌تواند ابتدا توان اجرای عملیات را ببندد و خواندن منابع بی‌خطر را با سیاست مناسب ادامه دهد. در وضعیت شدیدتر، توقف کامل لازم می‌شود. انتخاب بین این رفتارها به اثر عملیات و سیاست سازمان وابسته است، نه صرفاً امتیازی که یک مدل دربارهٔ خودش می‌دهد.
برای هر واکنش، علت قابل پیگیری و شرایط بازگشت تعریف کنید. پس از توقف، چه کسی اجازهٔ شروع دوباره دارد؟ آیا کار نیمه‌تمام دوباره اجرا می‌شود؟ اگر یک ابزار درخواست را پذیرفته اما پاسخ آن قطع شده، از تکرار ناخواستهٔ عمل چگونه جلوگیری می‌شود؟ این پرسش‌ها تحلیل اجرایی این گزارش‌اند و باید در محیط آزمایشی پاسخ عملی پیدا کنند.
برای سنجش راهکار از تأمین‌کننده چه شاهدی بخواهیم؟
یک سناریوی مشخص بدهید: دستیارِ خواندن کاتالوگ با درخواست نامجاز روبه‌رو شود، دسترسی‌اش در میانهٔ کار لغو شود و گزارش قابل بازبینی تحویل دهد. از ارائه‌دهنده بخواهید تصمیم سیاست، درخواست ابزار و نتیجهٔ واقعی اجرا را کنار هم نشان دهد. نمایش هشدار پس از وقوع عمل، با جلوگیری پیش از عمل یکسان نیست.
دربارهٔ وضعیت عرضه، پیش‌نیاز هویت، نگه‌داری گزارش و دامنهٔ پوشش سؤال کنید. بخشی از Agentهای سازمان ممکن است بیرون از پلتفرم انتخابی ساخته شده باشند. باید روشن شود کدام‌ها فقط شناسایی می‌شوند، کدام‌ها قابل مهارند و چه شکاف‌هایی باقی می‌ماند. این ارزیابی را با دادهٔ ساختگی و سطح اختیار محدود انجام دهید.
برداشت عملی برای سازمان
این خبر دلیل کافی برای خرید فوری یا واگذاری سیاست امنیت به یک Agent دیگر نیست. شروع مناسب، فهرست‌کردن Agentهای موجود و انتخاب یک کاربرد با اختیار روشن و مسئول پاسخ‌گوست. سپس لغو دسترسی، خروج از دامنه و توقف در اجرای واقعی آزموده شود.
خروجی قابل استفاده شامل ثبت مالک، نقشهٔ ابزار و داده، قواعد واکنش و شواهد آزمون است. روش‌های بالا پیشنهاد تحریریه برای خواندن این تحول‌اند و ادعای پیاده‌سازی همهٔ آن‌ها در آیوان نیستند. معیار تصمیم باید توانِ مشاهده و اعمال سیاست در سناریوی خود سازمان باشد، نه صرفاً نام یک قابلیت یا اعتماد به پاسخ مطمئن مدل.