در محیط‌های سازمانی مدرن، تعداد فزاینده‌ای از محصولات شخص ثالث (Third-party) در حال ادغام قابلیت‌های هوش مصنوعی هستند. نکته بحرانی این است که در حالی که برخی از این ابزارها پشت سیستم‌های Single Sign-On (SSO) قرار دارند، بخش بزرگی از آن‌ها برای زیرساخت‌های مدیریت هویت (Identity Infrastructure) نامرئی هستند. این اتفاق به دلیل پنهان‌کاری نیست، بلکه به این دلیل است که استک‌های هویت تنها می‌توانند مواردی را مدیریت کنند که از طریق آن‌ها احراز هویت شوند، در حالی که بسیاری از عامل‌های هوش مصنوعی (AI Agents) هرگز این مسیر را طی نمی‌کنند.
تغییر پارادایم: از AI داخلی به عامل‌های ارث‌بری شده
تا پیش از این، «امنیت هوش مصنوعی» بر روی مشکلات First-party تمرکز داشت؛ یعنی زمانی که سازمان تصمیم می‌گرفت از یک مدل خاص استفاده کند، لایسنس تهیه کرده و آن را پشت یک Gateway مستقر می‌کرد. در این حالت، تیم‌های امنیتی می‌توانند کنترل‌های لازم را روی ابزاری که سازمان آگاهانه انتخاب کرده بود، اعمال کنند. اما عامل‌ها (Agents) به این شکل وارد سازمان نمی‌شوند. آن‌ها درون نرم‌افزارهای موجود در سازمان ادغام شده و بدون تصمیم مدیریتی فعال می‌شوند.
چرا کنترل‌های سنتی ناکارآمد هستند؟
اکثر ابزارهای امنیتی بر پایه یک «لحظه تصمیم‌گیری» بنا شده‌اند؛ برای مثال، اسکن مدل‌ها فرض می‌کند مدلی انتخاب شده است یا بازرسی Promptها فرض می‌کند یک Gateway مستقر شده است. اما عامل‌های هوش مصنوعی این مرحله را دور می‌زنند. برای نمونه، وقتی یک عامل کدنویسی در یک ابزار چت سازمانی فعال می‌شود، می‌تواند به Context گفتگو دسترسی داشته باشد، کد بنویسد و یک Pull Request باز کند. در این سناریو، حاکمیت (Governance) این عامل تنها به عضویت در یک کانال چت محدود می‌شود، در حالی که این عامل دسترسی مستقیم به GitHub و زیرساخت‌های Production دارد.
دسته‌بندی عامل‌های هوش مصنوعی
عامل‌ها را می‌توان به سه دسته تقسیم کرد:
- عامل‌های ارث‌بری شده (Inherited Agents): که از طریق آپدیت‌های نرم‌افزاری در پلتفرم‌های موجود فعال می‌شوند (بزرگترین و خطرناک‌ترین گروه).
- عامل‌های پیکربندی شده (Configured Agents): منطق و Promptهایی که سازمان روی Runtime و مدل‌های دیگران اجرا می‌کند.
- عامل‌های ساخته شده (Built Agents): فریم‌ورک‌های باز روی زیرساخت‌هایی که سازمان به‌طور کامل مالک آن‌هاست.
کجا باید تمرکز کرد؟ مدل یا داربست (Scaffolding)؟
بیشتر ریسک‌های امنیتی در خودِ مدل هوش مصنوعی نیست، بلکه در داربست (Scaffolding) و اکوسیستمی است که مدل در آن قرار دارد. برای ارزیابی ریسک، باید به چهار سوال کلیدی پاسخ داد:
- ثبت (Registration): آیا این عامل در جایی ثبت شده است و مالک مشخصی دارد یا به‌طور نامرئی اجرا می‌شود؟
- دسترسی‌ها (Entitlements): عامل اجازه انجام چه کارهایی را دارد و آیا این دسترسی‌ها بیش از نیاز واقعی است؟ (بررسی OAuth Scopes و Roleها).
- شعاع تخریب (Blast-radius): این عامل به‌طور مستقیم یا غیرمستقیم به چه داده‌ها، ذخیره‌سازها و عامل‌های دیگر دسترسی دارد؟
- رفتار (Behavior): عامل در عمل چه می‌کند و آیا این رفتار با توصیفات Prompt آن مطابقت دارد؟
ریسک زنجیره تأمین و الزامات قانونی
مدیران ارشد امنیت (CISO) اکنون عامل‌های هوش مصنوعی را به عنوان یک ریسک سیستمیک در زنجیره تأمین (Supply Chain Risk) می‌بینند. رویکرد ایده‌آل این است که یک عامل در ابتدا هویت داشته باشد اما هیچ دسترسی (Entitlement) پیش‌فرضی نداشته باشد و دسترسی‌ها تنها پس از تأیید IT اعطا شوند.
از سوی دیگر، مقرراتی مانند EU AI Act سازمان‌ها را ملزم می‌کند که فهرستی از سیستم‌های AI خود را تهیه کرده و نظارت بر آن‌ها را اثبات کنند. سازمانی که نتواند عامل‌های هوش مصنوعی فعال در محیط خود را شناسایی و شمارش کند، نمی‌تواند با این قوانین مطابقت داشته باشد.
