در مدلهای سنتی امنیتی، احراز هویت (Authentication) مشخص میکند که کاربر کیست و سطح دسترسی (Authorization) تعیین میکند که او چه کارهایی میتواند انجام دهد. اما در دنیای ایجنتهای هوش مصنوعی (AI Agents)، این مدلها برای جلوگیری از سوءاستفادههای پیچیده کافی نیستند. مشکل اینجاست که یک ایجنت ممکن است دسترسی قانونی برای خواندن رکوردها و ارسال ایمیل داشته باشد، اما تحت تأثیر یک دستور مخرب، این دسترسیهای قانونی را در مسیر اشتباه به کار ببرد.
چالش تزریق دستورات غیرمستقیم (Indirect Prompt Injection)
یکی از جدیترین تهدیدات، تزریق دستورات غیرمستقیم (Indirect Prompt Injection) است. در این سناریو، عامل تهدید دستورات مخرب را در محتوایی (مانند ایمیل، سند یا وبسایت) قرار میدهد که ایجنت قرار است آن را بخواند. اگر ایجنت این دستورات را به عنوان دستورات معتبر بپذیرد، میتواند بدون نیاز به سرقت رمز عبور، اقدام به سرقت دادهها یا اجرای کدهای مخرب نماید. این موضوع نشان میدهد که Prompt Injection تنها یک مشکل مهندسی پرامپت نیست، بلکه یک نقص امنیتی در سطح معماری است.
ضرورت حریمهای حفاظتی قطعی (Deterministic Safeguards)
برای مقابله با این تهدیدات، سیستمها نباید صرفاً به خروجی مدل هوش مصنوعی اعتماد کنند. تصمیمات حساس باید بر اساس وضعیت مورد اعتماد اپلیکیشن (Trusted Application State) گرفته شوند، نه بر اساس آنچه مدل ادعا میکند. برای مثال، اگر یک ایجنت قصد ارسال گزارش به یک آدرس جدید را دارد، سیستم باید بهطور مستقل بررسی کند که:
- چه کسی تسک را شروع کرده است؟
- اطلاعات مربوط به کدام مشتری است؟
- آیا گیرنده نهایی در لیست مخاطبان تأیید شده قرار دارد؟
- آیا این عملیات نیاز به تأیید انسانی (Human-in-the-loop) دارد؟
مدیریت مقصد و جریان دادهها
استفاده از لیستهای سفید (Allowlists) ساده برای دامنهها کافی نیست. یک دامنه تأیید شده (مانند یک سرویس ابری) ممکن است شامل حسابهای شخصی مهاجم نیز باشد. بنابراین، سیستم باید تا سطح Tenant، پوشه و گیرنده نهایی را رصد کند. همچنین ابزارهای DLP (جلوگیری از نشت دادهها) باید کل جریان داده را دنبال کنند، زیرا مدلهای هوش مصنوعی میتوانند با خلاصهسازی اسناد محرمانه، نشانگرهای امنیتی (Markers) را حذف کرده و در عین حال اطلاعات حساس را منتقل کنند.
تأیید انسانی و چالش اعتماد
حضور انسان در چرخه تصمیمگیری (Human-in-the-loop) به تنهایی یک ویژگی امنیتی نیست. مهاجمان میتوانند با مسموم کردن توضیحات ایجنت، بازبین انسانی را فریب دهند تا عملیاتی را تأیید کند که در واقعیت هرگز مورد موافقت مدیر نبوده است. برای جلوگیری از این اتفاق، جزئیات عملیات باید توسط کد اپلیکیشن و بهصورت مستقل از توضیحات ایجنت نمایش داده شود.
پایش و تحلیل (Audit & Logging)
در تحلیلهای پس از حادثه، استدلالهای تولید شده توسط مدل (Reasoning) به عنوان ردپای (Audit Trail) قابل اعتماد نیستند. سازمانها باید دقیقاً ثبت کنند که چه ایجنتی، با چه منابعی و بر اساس کدام Policy عملیاتی را انجام داده است. این دادهها در SIEM میتواند الگوهای مشکوک (مانند تغییر مخاطب و سپس استخراج دادههای کوچک اما مکرر) را شناسایی کند.