وصل‌کردن یک مدل زبانی به داده‌ی واقعی کسب‌وکار — مشتری، فاکتور، موجودی — طبیعتاً یک سؤال امنیتی جدی است. این مقاله چهار خطر واقعی MCP (Model Context Protocol) را از هم باز می‌کند و می‌گوید یک پیاده‌سازی جدی چطور هرکدام را می‌بندد؛ نه به‌عنوان تبلیغ یک محصول، بلکه به‌عنوان چک‌لیستی که پیش از اتصال هر سرور MCP (نه فقط سرور ابرک) باید ارزیابی کنید.
خطر اول: مدل چیزی می‌نویسد که نمی‌خواستید
مدل زبانی گاهی دستور را اشتباه می‌فهمد یا بیش از حد «کمک‌کننده» عمل می‌کند — مثلاً به‌جای خواندن یک سفارش، آن را لغو می‌کند. راه‌حل درست، تأیید دوفازی است: هر ابزار نوشتن در فراخوانی اول فقط پیش‌نمایش دقیق تغییر را برمی‌گرداند (چه فیلدی، از چه مقداری، به چه مقداری) و تا کاربر صریح تأیید نکند، چیزی روی دیتابیس اعمال نمی‌شود. نکته‌ی فنی مهم: تأیید باید به همان آرگومان‌های اول امضا شود، وگرنه مدل می‌تواند در تلاش دوم چیز دیگری بفرستد و همان تأیید را دور بزند.
خطر دوم: کلید بیش از آنچه لازم است می‌بیند
اگر یک کلید MCP به تمام مدل‌های دیتابیس دسترسی داشته باشد، نشتش خطر بزرگی است. راه‌حل، اصل کمترین امتیاز روی دو لایه است: کلید به یک کاربر اودو وصل می‌شود (پس ACL و قواعد رکورد همان کاربر همیشه اعمال می‌شود)، و یک لایه‌ی دوم مستقل تعیین می‌کند کدام مدل‌ها اصلاً از مسیر MCP قابل‌دیدن‌اند — حتی اگر کاربر در اودو به آن دسترسی داشته باشد. دو لایه یعنی یک باگ در یکی، دیگری را نمی‌شکند.
خطر سوم: روی سرویس چندمستأجره، درخواست به دیتابیس اشتباه برود
یک نگرانی خاص محیط‌های ابری چندمستأجره: اگر سرور MCP از روی هدر اشتباه دیتابیس را تشخیص دهد، ممکن است داده‌ی یک شرکت به کلید شرکت دیگری برسد. رفتار درست، تشخیص فضای کاری از روی نام میزبان درخواست است — و اگر درخواست به نود اشتباه برسد، پاسخ باید خطای صریح بدهد (نه یک پاسخ خالی که به‌اشتباه «امن» به نظر برسد).
خطر چهارم: هیچ رد پایی از کاری که مدل انجام داده نیست
وقتی چیزی اشتباه می‌شود، اولین سؤال این است: «دقیقاً چه کسی، با کدام کلید، چه چیزی را صدا زد؟» بدون لاگ کامل هر فراخوانی (موفق یا رد‌شده، همراه با کد وضعیت و دلیل رد) این سؤال بی‌جواب می‌ماند. لاگ باید فراخوانی را ثبت کند ولی خودِ توکن حساس را هرگز ذخیره نکند.
چک‌لیست پیش از اتصال هر سرور MCP
پیش از دادن هر کلید MCP به یک کلاینت هوش مصنوعی، این چهار سؤال را بپرسید: نوشتن دوفازی با تأیید انسانی دارد؟ دسترسی روی سطح کاربر و مدل مجاز محدود می‌شود؟ روی چندمستأجری خطای صریح می‌دهد نه پاسخ ساکت؟ هر فراخوانی لاگ می‌شود؟ جزئیات پیاده‌سازی این چهار اصل روی اودو در صفحه‌ی اپ سرور MCP و آموزش اتصال آمده است.
ماتریس ریسک؛ کدام تهدید چقدر جدی است
| تهدید | احتمال | شدت اثر | کنترل اصلی |
|---|---|---|---|
| نوشتن ناخواسته توسط مدل | متوسط | بالا | تأیید انسانی برای هر عمل نوشتن |
| دسترسی بیش از حد کلید | بالا | بالا | دامنهٔ حداقلی در سطح مدل و رکورد |
| رسیدن درخواست به مستأجر اشتباه | پایین | بحرانی | گره‌زدن کلید به مستأجر + خطای صریح |
| تزریق دستور از راه محتوا | متوسط | متوسط | محتوای خوانده‌شده داده است، نه دستور |
| نشت در لاگ | متوسط | متوسط | حذف کلید و داده‌ی حساس از لاگ |
تزریق دستور از راه محتوا؛ تهدیدی که کمتر جدی گرفته می‌شود
اگر ایجنت توضیح یک محصول یا متن یک تیکت را می‌خواند، آن متن را یک انسان بیرونی نوشته است. اگر سیستم آن را به‌عنوان دستور تفسیر کند، مهاجم می‌تواند با نوشتن یک جملهٔ ساده در فرم تماس، رفتار ایجنت را تغییر دهد. قاعدهٔ محافظ ساده است: هر چیزی که از دیتابیس خوانده می‌شود داده است و هرگز نباید مثل دستور اجرا شود — و ابزارهای نوشتن باید مستقل از متن ورودی، تأیید بخواهند.
حداقل کنترل‌ها پیش از اتصال به داده‌ی واقعی
- دسترسی خواندنی پیش‌فرض؛ نوشتن فقط با تأیید صریح.
- سقف نرخ روی هر کلید، تا حلقهٔ اشتباه به فاجعهٔ مالی تبدیل نشود.
- ثبت ممیزی کامل: چه پرسیده شد، چه خوانده شد، چه تغییر کرد.
- تست با دو مستأجر هم‌زمان، چون باگ‌های جداسازی با یک مستأجر ظاهر نمی‌شوند.
جزئیات احراز هویت در Bearer یا OAuth 2.1، معماری چندمستأجره در چرا سرورهای MCP خراب می‌شوند و چک‌لیست عملیاتی در امنیت کلیدهای MCP.
هوش مصنوعی و MCP؛ ادامهٔ مسیر
از مبانی MCP و انتخاب مدل تا کاربردهای عملی روی اودو.
- MCP (Model Context Protocol) چیست؟ راهنمای کامل برای کسب‌وکار ایرانی
- هوش مصنوعی در کسب و کار ایرانی؛ راهنمای عملی ERP + AI
- هوش مصنوعی اودو (Odoo AI) چیست؟ راهنمای کامل AI Agent و AI Composer
- GPT یا Claude یا Gemini برای کسب‌وکار شما؟
- OIDC یا SAML برای ورود یکپارچه ERP؟
- راهنمای کاربری تلفن ابری ابرک: از نصب تا اولین تماس
