آیا میتوان به عاملهای هوش مصنوعی برای دسترسی به اطلاعات حساس اعتماد کرد؟

هوش مصنوعی دیگر فقط به پرسشهای کاربران پاسخ نمیدهد یا متن و تصویر تولید نمیکند. نسل جدیدی از ابزارهای هوشمند با نام عامل هوش مصنوعی (AI Agent) میتواند به فایلها و اطلاعات شخصی دسترسی پیدا کند، از ابزارهای مختلف استفاده کند، وظایف چندمرحلهای را پیش ببرد و حتی بدون دخالت مداوم انسان تصمیم بگیرد چه کاری انجام دهد.
این قابلیتها فرصتهای تازهای برای خودکارسازی کارهای روزمره و سازمانی ایجاد کردهاند؛ اما در مقابل، یک نگرانی جدی به وجود آوردهاند: اگر یک عامل هوش مصنوعی از محدوده اختیارات خود فراتر برود، چه اتفاقی برای اطلاعات محرمانه و زیرساختهای سازمانی میافتد؟
در واکنش به این نگرانیها، تیم واکنش اضطراری رایانهای هند (CERT-In) در ۴ نوامبر ۲۰۲۶ دستورالعمل جدیدی با عنوان AI Security Auditing Guidelines منتشر کرد. این سند ۱۰۷ صفحهای چارچوبی برای ارزیابی امنیت، حریم خصوصی، شفافیت و نظارت بر سامانههای هوش مصنوعی ارائه میدهد.
در این مقاله بررسی میکنیم عاملهای هوش مصنوعی چه خطراتی دارند، دستورالعمل جدید CERT-In چه الزاماتی مطرح میکند و سازمانها چگونه میتوانند دسترسی این ابزارها به اطلاعات حساس را کنترل کنند.
عامل هوش مصنوعی چیست و چه تفاوتی با چتبات معمولی دارد؟
چتباتهای معمولی عمدتاً به درخواست کاربر پاسخ میدهند؛ برای مثال، میتوانند یک متن را خلاصه کنند، به سؤالی پاسخ دهند یا برای انجام کاری راهنمایی ارائه کنند.
اما عامل هوش مصنوعی علاوه بر پاسخدادن، میتواند برای رسیدن به یک هدف چندین اقدام را برنامهریزی و اجرا کند. این ابزارها بسته به سطح دسترسی و امکاناتی که در اختیارشان قرار گرفته است، میتوانند با نرمافزارها، فایلها، پایگاههای داده و سرویسهای آنلاین ارتباط برقرار کنند.
برای درک تفاوت این دو، یک دستیار هوشمند مدیریت ایمیل را در نظر بگیرید:
- چتبات معمولی: ایمیلهای انتخابشده را خلاصه میکند و پیشنهاد میدهد کدام پیامها مهمتر هستند.
- عامل هوش مصنوعی: میتواند ایمیلها را بررسی کند، پیامهای مهم را دستهبندی کند، پاسخ پیشنهادی بنویسد و در صورت داشتن مجوز، آن را ارسال کند.
تفاوت اصلی در میزان خودمختاری و توانایی انجام عملیات است. عامل هوش مصنوعی ممکن است برای تکمیل یک وظیفه، چندین ابزار را به کار بگیرد و بدون نیاز به تأیید جداگانه برای هر مرحله، کار را پیش ببرد.
همین ویژگی باعث میشود کنترل دسترسی و نظارت بر فعالیت آن اهمیت بیشتری پیدا کند.
چرا دسترسی عاملهای هوش مصنوعی به اطلاعات حساس خطرناک است؟
مشکل اصلی صرفاً این نیست که هوش مصنوعی میتواند به اطلاعات محرمانه دسترسی داشته باشد؛ مسئله این است که ممکن است از دسترسی مجاز خود برای انجام کاری خارج از محدوده وظیفه استفاده کند.
فرض کنید یک کارمند اجازه دارد پنج پرونده مشخص را بررسی کند. اگر یک عامل هوش مصنوعی با همان اعتبارنامه و سطح دسترسی فعالیت کند، ممکن است در جریان اجرای وظیفه به تعداد بسیار بیشتری از پروندهها دسترسی پیدا کند؛ حتی اگر این اطلاعات ارتباطی با درخواست اولیه نداشته باشند.
در چنین شرایطی، سامانههای امنیتی سنتی ممکن است فعالیت عامل را مجاز تشخیص دهند؛ زیرا درخواستها با حساب کاربری معتبر انجام شدهاند. درحالیکه هدف و دامنه واقعی فعالیت عامل از محدوده مجاز فراتر رفته است.
مهمترین خطرهای این موضوع عبارتاند از:
- افشای اطلاعات محرمانه: عامل ممکن است به اسناد، اطلاعات مشتریان یا دادههای شخصی غیرمرتبط با وظیفه خود دسترسی پیدا کند.
- استفاده نادرست از ابزارها: یک عامل میتواند از APIها یا سرویسهای متصل برای انجام عملیات پیشبینینشده استفاده کند.
- گسترش خطا در چند سامانه: اگر عامل به ابزارهای مختلف متصل باشد، یک اشتباه ممکن است روی چند سرویس و پایگاه داده اثر بگذارد.
- استفاده مجدد از اطلاعات ورود افشاشده: اعتبارنامههایی که در جریان فعالیت عامل پیدا میشوند، ممکن است در عملیات بعدی نیز مورد استفاده قرار بگیرند.
- حملات مبتنی بر دستور مخرب: مهاجمان میتوانند دستورهای پنهان در اسناد، صفحات وب یا ورودیهای دیگر قرار دهند تا رفتار عامل را تغییر دهند.
بنابراین، صرفاً تعیین یک وظیفه مشخص برای عامل هوش مصنوعی کافی نیست؛ زیرساختی که عامل در آن فعالیت میکند نیز باید از نظر فنی مانع دسترسی غیرمجاز شود.
چرا نباید فقط به دستورهای متنی برای کنترل هوش مصنوعی اعتماد کرد؟
یکی از نکات مهمی که کارشناسان امنیت سایبری در گزارش Digit مطرح کردهاند، تفاوت میان محدودیت رفتاری و محدودیت فنی است.
برای مثال، فرض کنید به یک عامل هوش مصنوعی دستور میدهید:
«فقط اطلاعات را بخوان و هیچ فایلی را تغییر نده.»
این جمله صرفاً یک دستور متنی است. اگر عامل همچنان به ابزار حذف یا ویرایش فایل دسترسی داشته باشد، دستور شما بهتنهایی مانع اجرای آن عملیات نمیشود.
راهکار مطمئنتر این است که محدودیتها در سطح نرمافزار و زیرساخت اعمال شوند. یعنی اگر عامل فقط باید اطلاعات را بخواند، حساب کاربری و ابزارهای متصل به آن نیز نباید مجوز ویرایش یا حذف اطلاعات را داشته باشند.
این رویکرد با مفهوم Control by Design شناخته میشود؛ به این معنا که امنیت باید در طراحی و ساختار فنی سامانه اعمال شود، نه اینکه صرفاً از مدل بخواهیم رفتار مناسبی داشته باشد.
برای مثال، میتوان:
- دسترسی عامل به پوشههای غیرمرتبط را از نظر فنی مسدود کرد.
- برای هر وظیفه فقط ابزارهای ضروری را فعال نگه داشت.
- دسترسی نوشتن یا حذف اطلاعات را به تأیید انسان وابسته کرد.
- مدت اعتبار مجوزهای دسترسی را محدود کرد.
- فعالیت عامل را بهصورت پیوسته ثبت و بررسی کرد.
دستورالعمل جدید CERT-In چیست؟
CERT-In نهاد ملی واکنش به حوادث امنیت رایانهای در هند است که زیرمجموعه وزارت الکترونیک و فناوری اطلاعات این کشور فعالیت میکند.
این نهاد در ۴ نوامبر ۲۰۲۶ دستورالعمل Artificial Intelligence Security Auditing Guidelines را منتشر کرد. هدف سند، ایجاد یک چارچوب مشترک برای ارزیابی امنیت و حاکمیت سامانههای هوش مصنوعی در تمام مراحل چرخه عمر آنهاست؛ از طراحی و توسعه گرفته تا استقرار، نظارت و بازنشستگی.
این دستورالعمل فقط به چتباتها محدود نیست و انواع سامانههای هوش مصنوعی، از جمله مدلهای مولد، سیستمهای چندعاملی، ابزارهای بازیابی اطلاعات و عاملهای خودمختار را پوشش میدهد.
دامنه آن نیز صرفاً به ابزارهای ساختهشده در هند محدود نمیشود؛ سامانههایی که دادههای هند را پردازش میکنند یا خدمات هوش مصنوعی را به کاربران این کشور ارائه میدهند نیز در چارچوب آن قرار میگیرند.
CERT-In سامانههای هوش مصنوعی را به چهار سطح ریسک تقسیم میکند
یکی از بخشهای مهم دستورالعمل جدید، طبقهبندی سامانههای هوش مصنوعی بر اساس میزان خطر آنهاست. این دستهبندی مشخص میکند هر سامانه به چه سطحی از ممیزی، نظارت و کنترل امنیتی نیاز دارد.
| سطح ریسک | ویژگیها | نمونه کاربرد |
|---|---|---|
| کم (Low) | تأثیر محدود و خودمختاری پایین | ابزارهای ساده پیشنهاددهنده |
| متوسط (Moderate) | تأثیر قابلکنترل بر فرایندهای کاری با نظارت انسانی | دستیارهای پشتیبانی مشتری |
| زیاد (High) | تأثیر جدی بر تصمیمها یا عملیات سازمانی | سامانههای مؤثر بر تصمیمهای مالی مهم |
| بحرانی (Critical) | احتمال آسیب گسترده، اختلال سیستمی یا پیامدهای جبرانناپذیر | سامانههای هوش مصنوعی در زیرساختهای حیاتی |
این طبقهبندی فقط به نوع مدل بستگی ندارد. عواملی مانند میزان خودمختاری، حساسیت اطلاعات، گستردگی استفاده، امکان بازگشت از تصمیم اشتباه و اهمیت زیرساختی که هوش مصنوعی در آن فعالیت میکند نیز در تعیین سطح ریسک مؤثر هستند.
برای مثال، یک مدل زبانی که صرفاً متنهای عمومی را خلاصه میکند ممکن است ریسک پایینی داشته باشد؛ اما همان مدل اگر به پایگاه داده مشتریان یک بانک متصل شود و بتواند تراکنشها را آغاز کند، در شرایط کاملاً متفاوتی قرار میگیرد.
هر سطح ریسک به چه نوع ممیزی نیاز دارد؟
CERT-In شدت و دفعات ممیزی را متناسب با سطح خطر تعیین کرده است:
| سطح ریسک | شیوه ممیزی | دفعات بررسی |
|---|---|---|
| کم | ارزیابی داخلی یا خودارزیابی | بازبینی سالانه |
| متوسط | ممیزی داخلی مستند | ارزیابی مستمر |
| زیاد | ممیزی مستقل توسط شخص ثالث | حداقل سالانه |
| بحرانی | ممیزی مستقل توسط سازمان مورد تأیید CERT-In و نظارت مستمر | ارزیابی پیوسته و ممیزیهای دورهای؛ هر شش ماه در شرایط مقتضی |
بنابراین، سامانهای که به اطلاعات حساس یا زیرساختهای حیاتی دسترسی دارد، نمیتواند صرفاً به یک بررسی اولیه هنگام راهاندازی اکتفا کند.
ممیزی امنیت هوش مصنوعی باید چه بخشهایی را بررسی کند؟
دستورالعمل CERT-In نه حوزه اصلی برای ممیزی امنیت و عملکرد مسئولانه سامانههای هوش مصنوعی مشخص کرده است. این حوزهها تمام مراحل فعالیت یک سیستم را پوشش میدهند.
۱. حاکمیت و مسئولیتپذیری هوش مصنوعی
سازمان باید مشخص کند چه کسی مسئول توسعه، استقرار، نظارت و مدیریت ریسک سامانه است. همچنین هدف استفاده از هوش مصنوعی و حدود اختیارات آن باید مستند باشد.
۲. چرخه عمر داده، کیفیت و حریم خصوصی
نحوه جمعآوری، ذخیرهسازی، پردازش و حذف اطلاعات باید بررسی شود. سازمان باید مشخص کند دادهها از کجا آمدهاند، چه اطلاعات حساسی دارند و چه کسانی اجازه دسترسی به آنها را دارند.
۳. مدیریت ریسک مدل
رفتار مدل، محدودیتها، احتمال خطا و تغییر عملکرد آن در طول زمان باید ارزیابی شود.
۴. اخلاق، سوگیری و عدالت
سامانه باید از نظر ایجاد تبعیض یا ارائه نتایج ناعادلانه برای گروههای مختلف کاربران بررسی شود.
۵. شفافیت و توضیحپذیری
سازمان باید بتواند عملکرد سامانه و عوامل مؤثر بر تصمیمهای مهم آن را تا حد مناسبی توضیح دهد.
۶. امنیت سایبری و مقاومت در برابر حملات
این بخش شامل بررسی آسیبپذیریها، حملات مخرب، افشای اطلاعات و آمادگی برای مدیریت حوادث امنیتی است.
۷. نظارت مستمر و مدیریت تغییرات
عملکرد هوش مصنوعی باید پس از استقرار نیز پایش شود. تغییر دادهها، رفتار مدل یا محیط اجرایی ممکن است ریسکهای جدیدی ایجاد کند.
۸. نظارت انسانی و پاسخگویی در تصمیمها
برای تصمیمهای مهم باید امکان بررسی، تأیید، اصلاح یا متوقفکردن خروجی هوش مصنوعی توسط انسان وجود داشته باشد.
۹. امنیت تأمینکنندگان و سرویسهای شخص ثالث
سازمان باید خطرهای ناشی از مدلهای خارجی، APIها، کتابخانهها و ابزارهای متصل به سامانه را نیز بررسی کند.
CERT-In برای ایمنسازی عاملهای هوش مصنوعی چه راهکارهایی پیشنهاد میکند؟
دستورالعمل جدید بخش مستقلی را به امنیت عاملهای هوش مصنوعی اختصاص داده است. هدف این بخش آن است که هر عامل فقط در محدوده مشخصی فعالیت کند و نتواند بهصورت خودکار اختیارات بیشتری از کاربران یا ابزارهای دیگر به ارث ببرد.
مهمترین راهکارها عبارتاند از:
۱. تعریف هویت و محدوده دسترسی مستقل برای هر عامل
هر عامل باید هویت مشخص، هدف مجاز و فهرستی از ابزارهای تأییدشده داشته باشد. همچنین نباید تمام دسترسیهای حساب کاربری یا عامل دیگری را بهصورت خودکار دریافت کند.
برای مثال، عامل مسئول بررسی فاکتورها باید فقط به اطلاعات موردنیاز برای خواندن و تحلیل فاکتورها دسترسی داشته باشد، نه تمام اسناد مالی سازمان.
۲. استفاده از اصل حداقل دسترسی
اصل Least Privilege میگوید هر کاربر یا نرمافزار باید فقط به حداقل مجوزهای لازم برای انجام وظیفه خود دسترسی داشته باشد.
برای عاملهای هوش مصنوعی نیز این اصل اهمیت زیادی دارد. اگر یک عامل فقط باید اطلاعات را بخواند، نباید مجوز حذف یا تغییر آنها را داشته باشد.
۳. دریافت تأیید انسان برای عملیات حساس
عملیات مهم مانند انتقال پول، حذف اطلاعات، تغییر تنظیمات امنیتی یا ارسال دادههای محرمانه باید در صورت نیاز به تأیید انسان وابسته باشند.
این کار مانع از آن میشود که یک تصمیم اشتباه یا دستور مخرب، بدون بررسی انسانی به اقدامی غیرقابلبرگشت تبدیل شود.
۴. ثبت تمام فعالیتها و فراخوانی ابزارها
هر اقدام عامل باید قابل پیگیری باشد. اطلاعاتی مانند فراخوانی ابزارها، وظایف واگذارشده به عاملهای دیگر، تغییر وضعیت اجرا، تأییدهای انسانی و خروجیهای مهم باید در گزارشهای محافظتشده ثبت شوند.
این گزارشها به سازمان کمک میکنند در صورت بروز مشکل، مسیر فعالیت عامل و نقطه شروع حادثه را شناسایی کنند.
۵. ایجاد کلید توقف اضطراری
عاملهای پرخطر باید امکان توقف فوری داشته باشند. همچنین سازمان باید بتواند اعتبارنامههای آنها را لغو کند، تغییرات را به وضعیت قبلی برگرداند و از شروع مجدد کنترلنشده فعالیت جلوگیری کند.
۶. کنترل ارتباط با ابزارها و سرویسهای خارجی
اگر عامل از افزونهها، سرورهای MCP، APIها یا سرویسهای دیگر استفاده میکند، سازمان باید فهرست مشخصی از اتصالات مجاز داشته باشد.
اتصال جدید نیز پیش از استفاده در محیط عملیاتی باید از نظر هویت سرویس، اعتبار منبع و امنیت بررسی شود.
اگر چند عامل هوش مصنوعی با یکدیگر همکاری کنند، چه خطری وجود دارد؟
برخی سیستمها بهجای یک عامل، از چند عامل هوش مصنوعی استفاده میکنند که وظایف را بین خود تقسیم میکنند. برای مثال، یک عامل اطلاعات را جمعآوری میکند، عامل دوم آن را تحلیل میکند و عامل سوم گزارش نهایی را آماده میسازد.
این ساختار میتواند سرعت و کارایی را افزایش دهد؛ اما اگر یکی از عاملها دچار خطا یا نفوذ شود، ممکن است پیامد آن به سایر بخشهای فرایند نیز منتقل شود.
CERT-In برای کنترل این خطرها بر چند موضوع تأکید میکند:
- هر عامل باید هویت مستقل و قابلشناسایی داشته باشد.
- ارتباط میان عاملها باید احراز هویت و محافظت شود.
- عاملها نباید تمام مجوزهای خود را به عامل بعدی منتقل کنند.
- پیامهای دریافتی از عاملهای دیگر باید تا زمان تأیید اعتبار، قابل اعتماد فرض نشوند.
- دسترسی به حافظه و اطلاعات مشترک باید کنترل شود.
- واگذاری بیپایان وظایف و ایجاد حلقههای تکراری باید محدود شود.
- در صورت بروز مشکل، امکان توقف یک عامل یا کل فرایند چندعاملی وجود داشته باشد.
این کنترلها کمک میکنند یک خطای اولیه به زنجیرهای از عملیات ناخواسته در چند سامانه تبدیل نشود.
آیا دستورالعمل جدید CERT-In به معنی ممنوعیت استفاده از عاملهای هوش مصنوعی است؟
خیر. هدف این دستورالعمل جلوگیری از توسعه یا استفاده از عاملهای هوش مصنوعی نیست؛ بلکه ایجاد چارچوبی برای استفاده امنتر و قابلممیزی از آنهاست.
عاملهای هوش مصنوعی میتوانند در پشتیبانی مشتری، تحلیل اطلاعات، برنامهنویسی، مدیریت اسناد و خودکارسازی فرایندهای سازمانی بسیار مفید باشند. بااینحال، هرچه سطح دسترسی و میزان خودمختاری آنها بیشتر شود، نیاز به کنترلهای امنیتی نیز افزایش پیدا میکند.
همچنین باید توجه داشت که این سند یک چارچوب امنیتی و ممیزی در حوزه قضایی هند است و نباید آن را بهعنوان قانون جهانی برای تمام کاربران و شرکتهای فناوری معرفی کرد. دامنه کاربرد آن سازمانهای فعال در هند و سامانههایی را در بر میگیرد که دادههای هند را پردازش میکنند یا به کاربران این کشور خدمات میدهند.
کاربران عادی چگونه از اطلاعات حساس خود در برابر عاملهای هوش مصنوعی محافظت کنند؟
هرچند دستورالعمل CERT-In بیشتر سازمانها و توسعهدهندگان را هدف قرار داده است، کاربران عادی نیز میتوانند با رعایت چند نکته خطر افشای اطلاعات را کاهش دهند:
- دسترسی غیرضروری ندهید: اگر یک ابزار فقط برای خلاصهسازی به کار میرود، دسترسی کامل به ایمیل، فضای ابری یا فایلهای شخصی را فعال نکنید.
- اطلاعات محرمانه را ارسال نکنید: رمز عبور، اطلاعات کارت بانکی، اسناد هویتی و کلیدهای API را در اختیار ابزارهای هوش مصنوعی قرار ندهید.
- مجوزها را بررسی کنید: هنگام اتصال یک عامل به سرویسهای دیگر، مشخص کنید چه اطلاعاتی را میخواند و چه عملیاتهایی را میتواند انجام دهد.
- تأیید عملیات مهم را فعال نگه دارید: برای ارسال ایمیل، حذف فایل، خرید یا انتقال اطلاعات، تا حد امکان تأیید انسانی را ضروری کنید.
- اتصالات غیرضروری را قطع کنید: اگر دیگر از یک ابزار یا افزونه استفاده نمیکنید، دسترسی آن را لغو کنید.
- فعالیت حسابها را زیر نظر بگیرید: گزارش ورودها، دسترسیهای غیرعادی و عملیات انجامشده از طریق ابزارهای متصل را بررسی کنید.
مهمترین اصل این است که به یک عامل هوش مصنوعی فقط به اندازه وظیفهای که بر عهده دارد دسترسی بدهید، نه بیشتر.
جمعبندی
عاملهای هوش مصنوعی با توانایی برنامهریزی، استفاده از ابزارها و اجرای وظایف چندمرحلهای، امکانات تازهای برای کاربران و سازمانها فراهم کردهاند. اما همین خودمختاری میتواند در صورت نبود محدودیتهای فنی، به دسترسی غیرمجاز، افشای اطلاعات و گسترش خطا در چند سامانه منجر شود.
دستورالعمل جدید CERT-In تلاش میکند با طبقهبندی چهارگانه ریسک، ممیزی در نه حوزه اصلی، محدودکردن مجوزها، نظارت انسانی و ثبت فعالیتها، استفاده از سامانههای هوش مصنوعی را امنتر کند.
پیام اصلی این چارچوب روشن است: نباید امنیت اطلاعات را فقط به دستورهایی که به هوش مصنوعی میدهیم وابسته کنیم؛ محدودیتها باید در سطح فنی و زیرساختی نیز اعمال شوند. هرچه عامل هوش مصنوعی به دادهها و ابزارهای مهمتری دسترسی داشته باشد، کنترل مستقل، نظارت مستمر و امکان توقف فوری آن ضروریتر خواهد بود.