امنیت اتصال هوش مصنوعی به ابزارهای کسب‌وکار
از حداقل دسترسی و OAuth تا تأیید عملیات، Prompt Injection، Idempotency و Audit Log؛ چارچوبی عملی برای اتصال امن هوش مصنوعی به داده‌ها و ابزارهای سازمان.
اتصال هوش مصنوعی به ابزارهای کسب‌وکار یک تغییر مهم ایجاد می‌کند: مدل دیگر فقط درباره اطلاعات صحبت نمی‌کند؛ می‌تواند داده واقعی بخواند و در بعضی سناریوها عملیات انجام دهد. همین قابلیت، ارزش محصول را چند برابر می‌کند و هم‌زمان سطح ریسک را هم بالا می‌برد.
امنیت در این فضا با یک گزینه «فعال/غیرفعال» حل نمی‌شود. باید هویت کاربر، سطح دسترسی، نوع ابزار، حساسیت عملیات، نگهداری اعتبارنامه‌ها، تأیید انسانی و ثبت رویداد در کنار هم طراحی شوند.
مدل هوش مصنوعی نباید مرجع نهایی مجوز باشد. حتی اگر مدل تصمیم بگیرد ابزاری را فراخوانی کند، سرویس باید مستقل از مدل بررسی کند چه کسی، با چه مجوزی، روی چه منبعی و با چه محدودیتی اجازه انجام آن کار را دارد.
چرا اتصال AI با یک API معمولی فرق دارد؟
در یک نرم‌افزار سنتی معمولاً برنامه‌نویس دقیقاً مشخص می‌کند هر دکمه کدام API را صدا بزند. در سیستم عامل‌محور، مدل بر اساس متن کاربر و زمینه گفتگو تصمیم می‌گیرد چه ابزاری مناسب است. بنابراین کنترل‌های امنیتی نباید به «قضاوت مدل» وابسته باشند.
ورودی مدل نیز فقط متن مستقیم کاربر نیست. محتوای صفحات وب، ایمیل، اسناد یا داده برگشتی از ابزارها هم می‌تواند روی تصمیم مدل اثر بگذارد. این همان جایی است که خطر Prompt Injection اهمیت پیدا می‌کند.
تهدیدهای اصلی
۱. دسترسی بیش از حد
اگر یک اتصال از ابتدا اجازه خواندن، ویرایش و حذف همه چیز را داشته باشد، هر خطای مدل یا درخواست نامناسب دامنه اثر بزرگی خواهد داشت. اصل حداقل دسترسی می‌گوید هر کاربر و هر اتصال فقط ابزارهایی را ببیند که برای وظیفه‌اش لازم است.
۲. Prompt Injection
ممکن است داده‌ای که مدل می‌خواند شامل دستور مخرب باشد؛ مثلاً یک متن در صفحه وب یا تیکت پشتیبانی تلاش کند مدل را وادار کند اطلاعات دیگری را ارسال یا ابزاری حساس را اجرا کند. محتوای خارجی باید داده در نظر گرفته شود، نه دستور قابل اعتماد.
۳. افشای اعتبارنامه‌ها
رمز عبور، API Key، توکن دسترسی یا کلید خصوصی نباید در چت وارد شود. اعتبارنامه‌ها باید در لایه اتصال ذخیره، رمزگذاری و در زمان فراخوانی ابزار استفاده شوند؛ مدل فقط باید نتیجه یا خطای لازم را ببیند.
۴. عملیات مخرب یا برگشت‌ناپذیر
حذف رکورد، بازپرداخت، ارسال پیام انبوه، تغییر DNS، توقف سرویس یا تغییر دسترسی کاربر با خواندن اطلاعات تفاوت دارد. سیاست امنیتی باید نوع عملیات را تشخیص دهد و برای کارهای حساس تأیید، Idempotency و محدودیت بیشتری اعمال کند.
۵. اشتباه در هویت و مرز سازمان
در سیستم چندکاربره فقط دانستن نام ابزار کافی نیست. هر درخواست باید به هویت عضو، سازمان و نشست معتبر متصل باشد و سرویس مقصد نیز در صورت امکان سطح دسترسی بومی خودش را بررسی کند.
۶. گسترش بی‌صدای Scope
وقتی سرویس مقصد ابزار جدیدی اضافه می‌کند، نباید فرض شود اتصال موجود خودکار اجازه استفاده از آن را دارد. اضافه‌شدن Scope یا ابزار حساس بهتر است نیازمند بازبینی یا اتصال مجدد باشد.
۷. نبودن ردپای حسابرسی
اگر بعداً ندانیم چه کسی، چه زمانی، کدام ابزار را با چه ورودی‌ای اجرا کرده، بررسی خطا یا حادثه بسیار دشوار می‌شود. Audit Log باید بخشی از طراحی باشد، نه قابلیت جانبی.
مدل دسترسی پیشنهادی
برای اکثر سازمان‌ها تفکیک ابزارها بر اساس اثر، از یک نقش کلی مثل «مدیر» مفیدتر است. چهار سطح زیر نقطه شروع مناسبی هستند:
- خواندن: مشاهده اطلاعات بدون تغییر وضعیت منبع
- نوشتن کم‌ریسک: ایجاد یا ویرایش محدود که قابل بازگشت است
- عملیات حساس: تغییر مالی، حذف، ارسال گسترده یا تغییر زیرساخت که نیازمند تأیید است
- ممنوع: عملیاتی که نباید از مسیر AI قابل اجرا باشد
این طبقه‌بندی باید در سمت سرور اعمال شود. پنهان‌کردن یک دکمه یا توضیح‌دادن به مدل که «این کار را نکن» کنترل امنیتی محسوب نمی‌شود.
OAuth بهتر است یا واردکردن API Key؟
هرجا سرویس از OAuth پشتیبانی می‌کند، معمولاً انتخاب مناسب‌تری برای اتصال کاربرمحور است؛ چون Scope، انقضا، لغو دسترسی و گردش مجوز را استانداردتر می‌کند. API Key هنوز در بعضی سرویس‌ها لازم است، اما باید در Vault نگهداری شود و هرگز در متن گفتگو نمایش داده نشود.
در MCP نیز Authorization یک بخش مستقل از خود ابزارهاست. پیاده‌سازی امن باید اعتبار توکن، مخاطب، Scope و هویت را در هر درخواست بررسی کند؛ نه اینکه فقط در اولین اتصال اعتماد ایجاد کند.
تأیید انسانی کجا لازم است؟
تأیید برای هر عملیات کوچک تجربه کاربری را خراب می‌کند، اما حذف کامل تأیید نیز خطرناک است. قاعده عملی این است که تأیید بر اساس اثر عملیات تعیین شود.
- خواندن گزارش فروش: معمولاً بدون تأیید
- ویرایش توضیح یک محصول: بسته به سیاست سازمان می‌تواند بدون تأیید یا با تأیید باشد
- تغییر قیمت تعداد زیادی محصول: بهتر است تأیید شود
- بازپرداخت وجه: تأیید صریح
- حذف اطلاعات یا تغییر دسترسی کاربران: تأیید صریح یا ممنوع
- ارسال پیام انبوه: تأیید، محدودیت نرخ و نمایش تعداد گیرندگان
Idempotency؛ کنترل مهمی که معمولاً فراموش می‌شود
مدل یا شبکه ممکن است یک درخواست را تکرار کند. برای عملیات نوشتنی حساس باید یک کلید Idempotency وجود داشته باشد تا اجرای دوباره همان درخواست باعث دو بار بازپرداخت، دو سفارش یا دو پیام نشود.
ثبت لاگ باید چه چیزهایی را پوشش دهد؟
- هویت عضو و سازمان
- نام ابزار و اتصال مورد استفاده
- زمان اجرا و شناسه درخواست
- نتیجه موفق یا ناموفق
- اینکه عملیات نیازمند تأیید بوده و چه کسی آن را تأیید کرده
- شناسه منبع تغییرکرده در حد لازم
- نسخه‌ای امن از ورودی‌ها بدون ذخیره اسرار
لاگ خوب نباید تبدیل به محل دوم ذخیره رمز و توکن شود. داده‌های حساس باید Mask شوند و سیاست نگهداری مشخص داشته باشند.
امنیت شبکه و سرویس مقصد
اتصال امن فقط به مجوز ابزار محدود نیست. مقصد باید HTTPS معتبر داشته باشد، Redirectهای غیرمنتظره کنترل شوند و در اتصال‌های سروربه‌سرور خطر SSRF در نظر گرفته شود. در سناریوهای داخلی، بهتر است سرویس‌ها بدون نیاز عمومی روی اینترنت در دسترس قرار نگیرند مگر معماری و محصول چنین الزامی داشته باشد.
چرا «MCP Server قابل اعتماد» مهم است؟
راهنمای رسمی OpenAI نیز هشدار می‌دهد که اتصال به MCP Server نامطمئن می‌تواند خطرهایی مانند Prompt Injection ایجاد کند. بنابراین قبل از اضافه‌کردن یک App یا MCP سفارشی باید سازنده، عملیات قابل اجرا، مجوزها و مسیر نگهداری داده آن بررسی شود.
Developer mode و MCP apps در ChatGPT — راهنمای رسمی OpenAI
وصلک چگونه این مسئله را مدل می‌کند؟
در وصلک اتصال سرویس از اتصال هوش مصنوعی جداست. سازمان می‌تواند کانکتورها را مدیریت کند و سپس تعیین کند هر عضو یا اتصال AI به کدام ابزارها دسترسی داشته باشد. عملیات حساس نیز می‌تواند نیازمند تأیید داخل پنل باشد. این جداسازی باعث می‌شود تغییر مدل یا کلاینت AI به معنی دادن دوباره همه اعتبارنامه‌های سرویس‌ها نباشد.
هدف Gateway این نیست که امنیت سرویس مقصد را جایگزین کند؛ بلکه یک نقطه مرکزی برای سیاست‌گذاری، کنترل دسترسی، ثبت رویداد و مدیریت اتصال‌ها ایجاد می‌کند.
MCP Gateway چیست و چه تفاوتی با MCP Server دارد؟
چک‌لیست قبل از اتصال یک ابزار به AI
- آیا دقیقاً می‌دانید این اتصال چه داده‌هایی را می‌خواند؟
- آیا عملیات نوشتنی و حذف جدا از خواندن تعریف شده‌اند؟
- آیا Scopeها حداقلی هستند؟
- آیا رمز و توکن خارج از گفتگو نگهداری می‌شوند؟
- آیا عملیات مالی و مخرب تأیید انسانی دارند؟
- آیا Idempotency برای عملیات حساس وجود دارد؟
- آیا Audit Log قابل جست‌وجو دارید؟
- آیا لغو دسترسی عضو بلافاصله روی AI هم اثر می‌گذارد؟
- آیا ابزارهای جدید بدون بازبینی خودکار فعال نمی‌شوند؟
- آیا برای حادثه امنیتی مسیر Revoke و Rotation مشخص دارید؟
اگر حادثه امنیتی رخ داد
- اتصال یا کلید درگیر را فوراً غیرفعال یا Revoke کنید.
- نشست‌های فعال مرتبط را ببندید.
- Audit Log را بر اساس کاربر، ابزار و بازه زمانی بررسی کنید.
- در صورت احتمال افشای Secret، آن را Rotate کنید؛ صرفاً تغییر وضعیت اتصال کافی نیست.
- تغییرات انجام‌شده روی سرویس مقصد را جداگانه بررسی و در صورت امکان بازگردانی کنید.
- قبل از اتصال مجدد، علت اصلی حادثه و مرز دسترسی را اصلاح کنید.
جمع‌بندی
امنیت اتصال هوش مصنوعی با «اعتماد به مدل» ساخته نمی‌شود. کنترل واقعی باید در هویت، مجوز ابزار، Scope، تأیید عملیات، Idempotency، ذخیره امن Secret و Audit Log پیاده شود. هرچه AI توانایی اجرای کار بیشتری داشته باشد، اهمیت این مرزها بیشتر می‌شود.
اتصال خوب اتصالی نیست که بیشترین ابزار را در اختیار AI بگذارد؛ اتصالی است که دقیقاً ابزار لازم را، برای کاربر درست، در زمان درست و با امکان حسابرسی ارائه کند.
