عامل‌های هوش مصنوعی به عنوان کاربران ممتاز؛ چه کسی دسترسی آن‌ها را ممیزی می‌کند؟

سازمان‌ها معمولاً کارکنان انسانی خود را به شدت نظارت می‌کنند، اما عامل‌های خودمختار هوش مصنوعی (AI Agents) در سکوت با امتیازات گسترده‌ای فعالیت می‌کنند که می‌تواند آن‌ها را به نسل جدیدی از تهدیدات داخلی (Insider Threats) تبدیل کند.

نقطه کور در مدیریت هویت

تیم‌های امنیتی هزینه‌های زیادی را صرف محافظت از محیط‌های انسانی می‌کنند؛ از استقرار احراز هویت چندعاملی (MFA) مقاوم در برابر فیشینگ گرفته تا اعمال سیاست‌های سخت‌گیرانه دسترسی مشروط (Conditional Access). با این حال، در حالی که نظارت دقیقی بر کارکنان انسانی وجود دارد، تیم‌های مهندسی به آرامی دسترسی‌های گسترده‌ای به محیط‌های عملیاتی (Production) برای عامل‌های هوش مصنوعی اعطا می‌کنند. این عامل‌ها اغلب به عنوان هویت‌های غیرانسانی (Non-Human Identities یا NHI) و از طریق حساب‌های سرویس (Service Accounts)، توکن‌های API یا مجوزهای تفویض‌شده در محیط‌های ابری فعالیت می‌کنند.

این عامل‌ها تنها به تلخیص اسناد نمی‌پردازند، بلکه اقدامات ماشین-به-ماشین (Machine-to-Machine) را در مخازن حساس ابری، پایگاه‌های داده و محیط‌های سازمانی مدیریت می‌کنند. آن‌ها با استفاده از توکن‌های طولانی‌مدت و دارای امتیازات بیش از حد (Overprivileged)، اغلب خارج از کنترل‌های دسترسی تعاملی سنتی قرار می‌گیرند.

سقوط معماری تفکیک وظایف

بسیاری از تیم‌های امنیتی، جریان‌های کاری مبتنی بر عامل (Agentic Workflows) را به جای اجزای خودمختار با دسترسی‌های سیستمی، به عنوان ادغام‌های نرم‌افزاری بی‌خطر می‌بینند. اما واقعیت این است که وقتی یک عامل بتواند اقدامی را اجرا کند، بخشی از سطح حمله هویت (Identity Attack Surface) می‌شود. یک عامل خودمختار که کد اجرا می‌کند، منابع را تخصیص می‌دهد یا سوابق مالی را تغییر می‌دهد، در عمل مانند یک کاربر ممتاز (Privileged User) رفتار می‌کند.

یکی از اصول اساسی در سیستم‌های پرخطر، تفکیک وظایف (Segregation of Duties) است؛ به این معنا که هیچ هویت واحدی نباید بتواند یک فرآیند با ارزش بالا را به طور همزمان آغاز، تأیید و اجرا کند. اما هوش مصنوعی عامل‌محور می‌تواند این معماری را در صورت نبود مرزهای دسترسی شفاف، از بین ببرد.

سناریوی شکست در محیط ابری

تصور کنید یک تیم مهندسی، یک عامل اتوماسیون را با استفاده از یک حساب سرویس با مجوزهای Wild-card در AWS IAM (مانند s3:*) تعریف کند تا ادغام ابزارها ساده‌تر شود. اگر این عامل در حین بهینه‌سازی اسکریپت‌ها، تغییری در محیط عملیاتی ایجاد کند که منجر به قطعی شود، این اتفاق به دلیل ماهیت ماشین-به-ماشین، تمامی نقاط بازرسی انسانی (Human-in-the-loop) را دور می‌زند. در اینجا، عامل همزمان نقش آغازکننده، تأییدکننده و اجراکننده را ایفا کرده است.

راهکارهای کاهش ریسک و حاکمیت

برای جلوگیری از تبدیل این آسیب‌پذیری‌های عملیاتی به تهدیدات داخلی غیرقابل مدیریت، معماری‌های امنیتی باید هوش مصنوعی عامل‌محور را از محیط‌های Sandbox خارج کرده و در محدوده مدیریت دسترسی و هویت (IAM) و مدیریت دسترسی‌های ممتاز (PAM) قرار دهند. پیش از اعطای کلیدهای محیط عملیاتی، باید موارد زیر بررسی شوند:

• هویت عامل (Agent Identity): هر عامل باید یک هویت مجزا و غیرتعاملی داشته باشد. استفاده از توکن‌های سیستمی مشترک یا حساب‌های سرویس کلی باید ممنوع شود و توکن‌ها باید کوتاه‌مدت باشند.
• سلطه عامل یا شعاع تخریب (Blast Radius): دسترسی عامل باید دقیقاً محدود به هدف تجاری آن باشد. برای مثال، عاملی که فقط برای گزارش‌گیری نیاز به خواندن داده‌ها دارد، نباید مجوز Write یا Delete داشته باشد.
• مالکیت عامل (Agent Ownership): مسئولیت ریسک و پاسخگویی عملیاتی اقدامات خودمختار باید بر عهده یک مالک فرآیند تجاری (Business Process Owner) باشد، نه یک فریم‌ورک مهندسی.
• ثبت وقایع (Agent Logging): تیم‌های امنیتی به تله‌متری (Telemetry) نیاز دارند که ورودی‌های Prompt، فراخوانی‌های ابزار، خروجی‌های مدل و اجراهای API پایین‌دستی را با جزئیات ثبت کند.
• بازبینی عامل (Agent Review): هویت‌های خودمختار باید به طور منظم تحت بازبینی مجوزها (Access Certification) قرار گیرند تا از تبدیل شدن آن‌ها به حساب‌های زامبی (Zombie Accounts) جلوگیری شود.
• مهار عامل (Agent Containment): باید مکانیزم‌های مهار خارج از باند (Out-of-band) وجود داشته باشد تا بتوان عامل را بدون مختل کردن کل سیستم، سریعاً ایزوله یا غیرفعال کرد.

اگر عامل‌های هوش مصنوعی را با همان انضباطی که برای کاربران ممتاز انسانی به کار می‌برید، ممیزی و مدیریت نکنید، عامل‌های تهدید در آینده از آن‌ها به عنوان تهدیدات داخلی خودکار استفاده خواهند کرد.