حاکمیت عامل‌های هوش مصنوعی در سازمان شما تنها به اندازه شواهدی است که از آن پشتیبانی می‌کنند. در ۳ ژوئن ۲۰۲۴، پروژه امنیت GenAI (GenAI Security Project) وابسته به OWASP گزارش «وضعیت امنیت و حاکمیت هوش مصنوعی عامل‌محور ۲.۰» را منتشر کرد و یک مدل بلوغ پذیرش سازمانی را برای درجه‌بندی ایمنی عامل‌های خودمختار معرفی نمود.
این چارچوب درست زمانی عرضه می‌شود که سازمان‌ها برای استقرار عامل‌هایی که دسترسی به اعتبارنامه‌ها دارند، پول منتقل می‌کنند و با ورودی‌های نامعتبر تعامل دارند، عجله می‌کنند. با این حال، مدل فعلی یک نقطه کور خطرناک ایجاد می‌کند؛ چراکه به جای بررسی اینکه «چه کسی» ادعاهای امنیتی را تأیید کرده، صرفاً بر اساس آنچه سازمان «ادعا می‌کند» انجام داده است، درجه‌بندی می‌کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفاوت میان ادعا و واقعیت در محیط‌های عملیاتی بسیار حیاتی است. در یک بستر امنیتی حرفه‌ای، وجود یک «کلید قطع اضطراری» (Kill Switch) که توسط سازمان گزارش شده، با کلیدی که توسط یک مهاجم خارجی تست و تأیید شده باشد، کاملاً متفاوت است. مدلی که اقدام را اندازه می‌گیرد اما اعتبارسنجی را نادیده می‌گیرد، در واقع «ادعا» را درجه‌بندی می‌کند، نه «کنترل» را.
به نقل از مستندات OWASP، این مدل در حال حاضر از دو محور برای ترسیم وضعیت فعلی استفاده می‌کند:
- محور استقرار: از AT0 (هوش مصنوعی سایه یا غیررسمی) تا AT5 (عامل‌های داخلی سفارشی که در آن‌ها هویت، ابزارها و مرزها کاملاً کنترل شده‌اند).
- محور حاکمیت: از سطح ۰ (موردی و بدون برنامه) تا سطح ۳، جایی که عامل‌ها به عنوان زیرساخت‌های حیاتی تلقی شده و دارای حاکمیت کد-محور (Governance-as-Code)، کلیدهای قطع اضطراری و داشبوردهای رصد انحراف در لحظه هستند.
این نیاز به تأییدیه مستقل موضوع جدیدی نیست. در استانداردهای تضمین کیفیت، دهه‌هاست که «خوداظهاری» از «تأیید مستقل» جدا شده است. برای مثال، گزارش SOC 2 Type I فقط طراحی کنترل‌ها را توصیف می‌کند، اما Type II بررسی می‌کند که آیا این کنترل‌ها در طول زمان واقعاً عمل کرده‌اند یا خیر. به همین ترتیب، یک پرسشنامه امنیتی فروشنده با یک تست نفوذ شخص ثالث، پاسخ‌های متفاوتی می‌دهند و برای خریداران حرفه‌ای جایگزین یکدیگر نیستند.
طبق گزارش تحلیلگران، برای رفع این شکاف، افزودن محور سوم یعنی «نوع شواهد» (Evidence Type) پیشنهاد شده است. این رویکرد پیش از این در ارزیابی VS-R01 برای زیرساخت‌های پرداخت عامل‌محور به کار رفته و یافته‌ها را به پنج کلاس شواهد تقسیم می‌کند:
- E1: مشاهده استاتیک یا مستنداتی.
- E2: مشاهده زمان اجرا در مرحله پذیرش (پاسخ API در گیت ورودی، پیش از تسویه).
- E3: مشاهده زمان اجرا در مرحله تسویه.
- E4: تأیید بازپخش حملات خصمانه و پایداری آن‌ها.
- E5: تأیید ایزولاسیون متقاطع در برابر کنترل‌های مثبت و منفی.
این تفکیک حیاتی است زیرا یک مشاهده E2 (نحوه رد ورودی توسط API) نمی‌تواند ادعای «اجرای کامل» را پشتیبانی کند، چراکه اجرای کامل یک ویژگی مربوط به زمان تسویه (E3) است. بدون این جزئیات، سازمان‌ها اغلب ادعاهای اجرایی خود را بر اساس شواهد پذیرش بنا می‌کنند؛ خطایی که معمولاً تنها هنگام رخ دادن یک نقض امنیتی در محیط عملیاتی آشکار می‌شود.
برای متخصصان فنی، این تغییر به معنای جابجایی معیار از «تکمیل ویژگی‌ها» به «کنترل‌های اثبات‌پذیر» است. قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) که تعهدات مربوط به ریسک‌های بالا از اوت ۲۰۲۶ اجرایی می‌شود، بر «نظارت اثبات‌پذیر» تأکید دارد نه «نظارت ادعایی». مدلی که ادعا را به جای کنترل درجه‌بندی کند، در برابر بازرسی‌های قانونی دوام نخواهد آورد.
گام بعدی شما
- اگر در حال ترسیم نقشه راه عامل‌های هوش مصنوعی خود هستید، ادعاهای حاکمیتی خود را با تاکسونومی VS-R01 تطبیق دهید.
- بررسی کنید آیا وضعیت «سطح ۳» شما بر اساس خوداظهاری داخلی است یا شواهدی بازتولیدپذیر که از طریق وضعیت یک شاخه (Branch) عمومی قابل تأیید باشد.
- برای هر کنترل امنیتی ادعاشده، سطح شواهد (از E1 تا E5) را مشخص کنید تا نقاط کور امنیتی شناسایی شوند.
اما این چالش‌های حاکمیتی تنها بخشی از معماری است؛ برای درک عمیق‌تر از نحوه ایزولاسیون عامل‌ها در محیط‌های ابری، به تحلیل ما درباره استانداردهای Sandbox مراجعه کنید.
گفتگو