نظارت سنتی در برابر عامل‌های آلوده هوش مصنوعی

تصور کنید به یک مهندس تازه‌کار در روز اول کاری‌اش، دسترسی کامل به تمام سرورها و کدهای حساس شرکت بدهید؛ اکنون عامل‌های هوش مصنوعی دقیقاً همین جایگاه را در سازمان‌ها پیدا کرده‌اند. این هشدار که در ۲ اکتبر ۲۰۲۶ در یک تحلیل فنی توسط dev.to منتشر شد، به بحرانی اشاره دارد که اکثر سازمان‌ها نادیده می‌گیرند: اعطای دسترسی کامل به شل (Shell) و کامیت (Commit) به عامل‌های کدنویس مانند Claude Code یا Codex.

این تغییر، هوش مصنوعی را از یک چت‌بات ساده به یک بازیگر غیرانسانی تبدیل می‌کند که قادر است فایل‌ها را بخواند، وابستگی‌ها را نصب کند و درخواست‌های ادغام (Pull Request) ارسال نماید. در حالی که شرکت‌ها یک دهه را صرف ساخت سامانه‌های SIEM و EDR برای نظارت بر رفتار انسان‌ها کردند، اکنون کلیدهای گاوصندوق را بدون به‌روزرسانی سیاست‌های امنیتی به عامل‌ها سپرده‌اند.

سطح حمله جدید

طبق گزارش‌های منتشر شده، سطح حمله در حال حاضر از طریق متدهای شناخته‌شده‌ی زنجیره تأمین مورد بهره‌برداری قرار می‌گیرد. مهاجمان از بسته‌های مسموم npm برای فعال کردن قلاب‌های (Hooks) عامل‌ها و پیکربندی‌های مخرب برای نفوذ به جریان‌های کاری قانونی استفاده می‌کنند. به نقل از انجمن OpenAI، یک باگ مستند شده حتی اجازه می‌داد درخواست‌های PR غیرمجاز از طریق Codex ارسال شوند؛ موضوعی که ثابت می‌کند دسترسی‌های عامل‌محور، هدفی بسیار جذاب برای ربودن نشست‌ها (Session Hijacking) هستند. این آسیب‌پذیری‌ها در راستای تلاش‌های اخیر برای مسدود کردن نشت داده‌ها در عامل‌های کدنویس قرار دارد که نشان می‌دهد لایه‌های حفاظتی در زمان اجرا (Runtime) تا چه حد حیاتی هستند.

بسیاری از تیم‌ها هنوز این چارچوب را درک نکرده‌اند. اگر یک خط لوله CI به یک عامل اجازه نصب بسته و ارسال PR می‌دهد، سازمان در واقع یک «هویت ممتاز» جدید ایجاد کرده است. در حال حاضر، اکثر سازمان‌ها فاقد سند سیاست‌گذاری رسمی یا استراتژی نظارتی برای این هویت خاص هستند و همین امر یک شکاف امنیتی بحرانی ایجاد کرده است. این فقدان نظارت می‌تواند منجر به حوادثی شود که در آن عامل‌های هوش مصنوعی با سوءاستفاده از ابزارهای جانبی، داده‌های حساس سازمانی را استخراج می‌کنند، همان‌طور که اخیراً در مورد داده‌های تجاری سازمان ملل مشاهده شد.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های مدل بدون لایه‌ی نظارتی، ریسک‌های سیستمی را افزایش می‌دهد.

مکانیزم‌های شناسایی و جزئیات

برای مقابله با این تهدید، رویکرد جدیدی توسط Gryph و Jev پیشنهاد شده که یک لایه‌ی نظارت رفتاری را معرفی می‌کند. سازوکار این سیستم به شرح زیر است:

• ثبت لحظه‌ای تمام اقدامات عامل در لاگ‌ها.
• ارسال این لاگ‌ها به یک مدل زبانی بزرگ (LLM) مجزا.
• درخواست از مدل داور برای بررسی اینکه آیا این رفتار با الگوهای معمول توسعه‌دهنده و سیاست‌های سازمان همراستا است یا خیر.

بر اساس مستندات این پژوهش، این سیستم در یک تست کنترل‌شده توانست ۱۴ مورد از ۱۴ حمله مصنوعی را شناسایی کند. با این حال، گزارش تأکید می‌کند که نرخ شناسایی ۱۰۰ درصدی در یک دمو، تضمینی برای امنیت نیست. هر متخصص مهندسی شناسایی می‌داند که فاصله زیادی میان پاس کردن تست‌های مکتوب و مقابله با مهاجمی که سازوکار شناسگر را می‌شناسد، وجود دارد؛ چراکه حملات مصنوعی دقیقاً همان مواردی هستند که پژوهشگران از پیش پیش‌بینی کرده‌اند.

میزان استرس‌تست این راهکار در صنعت بسیار پایین است. برای مثال، این پژوهش در Hacker News تنها ۲ امتیاز گرفت و هیچ کامنتی دریافت نکرد که نشان می‌دهد این یک تحقیق اولیه است و نه یک راهکار میدان‌آزموده.

از منظر فنی، این سیستم در واقع همان تحلیل رفتار کاربر و موجودیت (UEBA) است که در اینجا «موجودیت» یک عامل زاینده است. مشکل اینجاست که رفتار «نرمال» یک عامل بسیار گسترده است و به دلیل تغییرات مکرر مدل‌های زیربنایی، به‌سرعت تکامل می‌یابد؛ موضوعی که ایجاد یک خط مبنای رفتاری (Behavioral Baselining) را برای مهندسان شناسایی به یک کابوس تبدیل می‌کند.

علاوه بر این، استفاده از یک LLM برای قضاوت درباره AI دیگر، یک مشکل اعتماد بازگشتی ایجاد می‌کند. مدل داور ممکن است دچار سردرگمی شود، با رانش مدل (Model Drift) مواجه شود یا هدف تزریق پرامپت (Prompt Injection) قرار گیرد و در نهایت به‌جای ایجاد دفاع در عمق، مجموعه‌ای از سیستم‌های نامطمئن را روی هم سوار کند.

پیامدهای امنیتی

برای تیم‌های امنیتی، اولویت فوری خرید لایه‌های شناسایی نیست، بلکه پیاده‌سازی اصول «خسته‌کننده» اما بنیادین امنیت است. این موارد عبارتند از:

• محدود کردن دقیق دسترسی‌های عامل (اصل کمترین امتیاز یا Least Privilege).
• جداسازی اعتبارنامه‌های عامل از اعتبارنامه‌های توسعه‌دهنده انسانی.
• اطمینان از ثبت تمام اقدامات در یک مکان بادوام، فارغ از دسته‌بندی آن‌ها.

شناسایی لایه دوم است؛ اما کمترین امتیاز لایه اول است و اکثر تیم‌ها هنوز لایه اول را تکمیل نکرده‌اند. تیم‌های امنیتی باید درک کنند که ریسک زنجیره تأمین عامل‌ها — مانند بسته‌های مسموم — دیگر فرضی نیست. فرآیندهای بررسی قلاب‌ها و اسکن وابستگی‌ها اکنون باید آرتیفکت‌هایی را در نظر بگیرند که می‌توانند نشست یک عامل را بربایند، نه فقط کدهایی که هنگام اجرای توسط انسان مخرب هستند.

در نهایت، صنعت در حال بازآموزی درس‌های دردناک مربوط به گسترش حساب‌های سرویس و نشت اعتبارنامه‌های CI/CD است. تنها تفاوت این است که پذیرش عامل‌ها بسیار سریع‌تر از حساب‌های سرویس رخ داده و این موضوع پنجره زمانی برای شکست‌های فاجعه‌بار را کوتاه‌تر کرده است.

گام بعدی شما

• اگر از ابزارهای عامل‌محور در محیط تولید استفاده می‌کنید، همین امروز سیاست‌های مدیریت هویت و دسترسی (IAM) خود را بازبینی کنید.
• دسترسی‌های عامل‌ها را از دسترسی‌های انسانی کاملاً مجزا کرده و برای هر کدام توکن‌های محدود کنید.
• فرآیند بررسی PRهای تولید شده توسط AI را به یک بازبینی انسانی سخت‌گیرانه تبدیل کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.