خبر تأییدشده
AWS در ۲۸ اکتبر ۲۰۲۶ راهنمایی برای ممیزی واگذاری اختیار در سامانه‌های عامل‌محور منتشر کرد. متن پیشنهاد می‌کند مسیر کاربر، عامل‌ها، ابزارها و منابع داده رسم شود و مرزهای کنترل در هر انتقال بررسی شوند. AWS این فرایند را یک بررسی اولیه ۳۰ دقیقه‌ای توصیف می‌کند، نه ارزیابی امنیتی جامع. راهنما نحوه ارتباط این مرزها با AgentCore Policy، IAM و Bedrock Guardrails را نیز توضیح می‌دهد. رویداد خبری، انتشار یک روش اجرایی است؛ اطلاعیه عرضه سرویس جدید یا تضمین امنیت همه عامل‌ها نیست.
تحلیل مستقل IROSG
ارزش چنین بررسی‌ای برای تیم محصول در آشکارکردن اختیارهای پنهان است. در یک نمونه اولیه، افزودن ابزار تازه ممکن است فقط چند خط تنظیمات باشد؛ ولی همان ابزار در محیط واقعی می‌تواند به داده حساس یا اقدام برگشت‌ناپذیر وصل شود. تحلیل تحریریه این است که نمودار معماری باید علاوه بر مسیر داده، مسیر اجازه را نیز نشان دهد: چه کسی درخواست را آغاز می‌کند و اختیار هر مرحله از کجا می‌آید.
برای نمونه فرضی یک دستیار پشتیبانی، خواندن سوابق مشتری و تغییر وضعیت اشتراک دو عمل با پیامد یکسان نیستند. حتی اگر هر دو از یک API انجام شوند، مجوز و شاهد لازم برای آن‌ها باید جداگانه ارزیابی شود. پیشنهاد ما این است که تیم ابتدا فهرست اقدام‌های ممکن را بنویسد و سپس برای هر اقدام، داده لازم و شرط پذیرش را مشخص کند. این روش از بحث کلی درباره «اعتماد به عامل» قابل اجرا‌تر است.
آزمون منفی بخش مهم این ارزیابی خواهد بود. صرف اینکه درخواست معتبر موفق می‌شود، نشان نمی‌دهد درخواست نامعتبر متوقف خواهد شد. در محیط آزمایش می‌توان هویت کم‌اختیار، داده متعلق به حساب دیگر یا درخواست خارج از دامنه را بررسی کرد و نتیجه را ثبت کرد. پاسخ مناسب باید از کنترل اجرایی حاصل شود، نه فقط از اینکه مدل در چند نمونه مؤدبانه از انجام کار خودداری کرده است.
ثبت شواهد نیز باید هدفمند باشد. نگهداری همه مکالمات بدون ساختار ممکن است حجم داده و ریسک محرمانگی را زیاد کند، اما پاسخ‌گویی را بهتر نکند. پیشنهاد تحریریه ثبت شناسه درخواست، هویت، تصمیم مجوز و نتیجه ابزار با حداقل محتوای حساس است. در زمان رخداد، این داده‌ها باید امکان بازسازی ترتیب اقدام‌ها را فراهم کنند و روشن سازند کدام کنترل اجازه یا منع داده است.
پس از بررسی اولیه، موارد پرخطر باید مالک و زمان پیگیری داشته باشند. یک نقشه رنگی بدون اصلاح عملی به‌سرعت قدیمی می‌شود. اضافه‌شدن ابزار، تغییر دامنه داده یا تبدیل پیش‌نویس به ارسال واقعی، دلیل مناسبی برای بازبینی دوباره است. هدف این کار متوقف‌کردن استفاده از عامل نیست؛ هدف، قابل فهم‌کردن دامنه اختیار و پاسخ‌گویی درباره نتیجه است. این توصیه‌ها تحلیل مستقل IROSG برای تبدیل راهنمای منتشرشده به برنامه کاری تیم هستند.
یک جلسه کوتاه پیگیری پس از اصلاح نخستین مورد می‌تواند نشان دهد آیا کنترل واقعاً در مسیر اجرای ابزار قرار گرفته یا فقط در سند طراحی توصیف شده است؛ این تفاوت برای پذیرش نتیجه تعیین‌کننده است.
