تصور کنید ساعت ۲ صبح است و گزارش‌های سیستمی شما خروجی انبوه داده‌ها و تغییرات غیرمجاز در دفاتر حسابداری را نشان می‌دهند، اما هیچ راهی برای شناسایی ربات مسئول وجود ندارد. این کابوس امنیتی اکنون برای بسیاری از سازمان‌هایی رخ داده است که با «مشکل هویت» روبره‌اند؛ وضعیتی که در آن چندین عامل (Agent) — شبیه به چندین کارمند مختلف که همگی از یک کارت شناسایی واحد برای ورود به شرکت استفاده می‌کنند — یک حساب کاربری مشترک دارند. این چالش در مقیاس وسیع‌تر با افزایش چشمگیر تعداد هویت‌های ماشینی نسبت به انسان‌ها مرتبط است که مدیریت احراز هویت را در سیستم‌های حساس پیچیده‌تر کرده است.
همان‌طور که در تحلیل قبلی ما درباره‌ی ضرورت کلیدهای توقف (Kill Switches) برای هوش مصنوعی اشاره کردیم، چالش فعلی از سیاست‌های کلان به جزئیات اجرایی منتقل شده است. در بسیاری از ساختارهای فعلی، کلید توقف عملاً بی‌فایده است؛ زیرا غیرفعال کردن حساب مشترک، تمام عامل‌ها را به‌طور هم‌زمان از کار می‌اندازد، فارغ از اینکه کدام‌یک دچار نقص شده است.
به نقل از گزارش ۲۶ سپتامبر ۲۰۲۶ توسط AI Tech Connect، شکست اصلی در اینجا مربوط به سطح دسترسی‌ها یا مجوزها نیست. حتی با محدودترین دسترسی‌ها، اگر پلتفرمی نتواند یک اقدام خاص را به یک هویت مشخص نسبت دهد، ایزوله کند یا توضیح دهد، شکست خورده است. این موضوع یادآور تله‌های امنیتی در پروتکل MCP است که در آن تسهیل دسترسی‌ها می‌تواند منجر به دور زدن لایه‌های حفاظتی داده‌های حساس شود. این گزارش سناریویی را توصیف می‌کند که در آن ۱۱ عامل از یک شناسه کاربر (Actor ID) استفاده می‌کنند و همین موضوع، گزارش‌های ممیزی (Audit Logs) را بی‌معنی می‌کند.
این وضعیت یک نقطه کور خطرناک برای تیم‌های امنیتی ایجاد می‌کند. وقتی یک رکورد تأمین‌کننده در عرض ۳ ثانیه دو بار تغییر می‌کند، نبود هویت فردی مانع از تشخیص سریع مشکل می‌شود. شما نمی‌توانید رفتار یک عامل خاص را اصلاح کنید، اگر نتوانید ثابت کنید کدام عامل در حال رفتار نادرست است. برای حل این بحران پاسخگویی، رویکرد جدید COGEXT در ایجاد لایه‌های انتقال وضعیت تلاش می‌کند تا شفافیت عملیاتی عامل‌های خودکار را افزایش دهد.
برای توسعه‌دهندگان، این یعنی تغییر معماری از «اول-مجوز» به «اول-هویت». هر عامل به یک هویت منحصربه‌فرد، یک مالک مشخص و یک کلید توقف اختصاصی نیاز دارد تا پایداری سیستم در زمان بروز خطا تضمین شود.
گام بعدی شما
- نقشه‌برداری از حساب‌های سرویس (Service Accounts) خود را ممیزی کنید تا مطمئن شوید هیچ دو عاملی از یک اعتبارنامه مشترک استفاده نمی‌کنند.
- برای هر عامل یک شناسه (ID) مجزا تعریف کنید تا گزارش‌های ممیزی قابلیت ردیابی داشته باشند.
- مکانیزم توقف مجزا برای هر عامل پیاده‌سازی کنید تا در صورت بروز خطا، کل عملیات متوقف نشود.
اما داستان سخت‌افزاری مدیریت این هویت‌ها در مقیاس میلیونی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی زیرساخت‌های مدیریت دسترسی در مراکز داده مراجعه کنید.
گفتگو