در توسعه نرم‌افزار، برخی قوانین و اصول آن‌قدر بنیادی هستند که شکستنشان تقریباً گناه کبیره محسوب می‌شود. برای مثال، قانون هوفستادر (Hofstadter’s Law) می‌گوید:
«هر کاری همیشه بیشتر از آنچه انتظار دارید زمان می‌برد، حتی زمانی که قانون هوفستادر را در نظر گرفته باشید!»
یا «قانون پیشاهنگ» (Boy Scout Rule) که می‌گوید همیشه باید کدی را تمیزتر از حالتی که تحویل گرفته‌اید، رها کنید.
قراردادهای API نیز در همین دسته قرار می‌گیرند.
بهترین APIها کاملاً قابل پیش‌بینی‌اند؛ تا حدی که برخی توسعه‌دهندگان آنها را «کسل‌کننده» می‌نامند. در این زمینه، «کسل‌کننده» بودن در واقع یک تعریف مثبت است. در مقابل، ابزارهای هوش مصنوعی و به‌ویژه مدل‌های زبانی بزرگ (LLMها) هیچ‌گاه کسل‌کننده نیستند — آنها قدرتمند، اما غیرقابل‌پیش‌بینی‌اند. برای توسعه‌دهندگان API در عصر هوش مصنوعی، این ترکیب می‌تواند دردسرساز باشد.
در ادامه، بررسی می‌کنیم که LLMها و ابزارهای هوش مصنوعی چگونه در حال بی‌توجهی به قراردادهای API هستند، این رفتار چه خطراتی دارد، و چه اقداماتی می‌توان برای کاهش خطرات امنیتی یا سوء‌استفاده از APIها انجام داد.
قرارداد API دقیقاً چیست؟
قراردادهای API اساس تعامل قابل‌اعتماد میان سرویس‌ها هستند. در ساده‌ترین شکل، آنها مجموعه‌ای از اصول‌اند که انتظار می‌رود هر API رعایت کند:
-
ورودی‌های قابل پیش‌بینی: API باید پارامترها و فرمت‌های خاصی را بپذیرد.
-
خروجی‌های قابل پیش‌بینی: پاسخ API باید ساختار و فیلدهای ثابتی داشته باشد.
-
پایداری: رفتار API نباید بدون دلیل بین نسخه‌ها تغییر کند.
-
مستندسازی شفاف: توابع و رفتارها باید در اسناد مشخص توضیح داده شوند.
-
سازگاری: ویژگی‌های جدید نباید باعث شکستن یکپارچگی نسخه‌های قبلی شوند.
-
مدیریت خطا: خطاها باید با قالب‌های مشخص و قابل‌درک گزارش شوند.
این قراردادها حتی اگر مکتوب نباشند، وجود دارند. اما ابزارهای هوش مصنوعی درک شهودی از این مفاهیم ندارند. به همین دلیل، اغلب می‌بینیم که آنها مشخصات را نادیده می‌گیرند، از محدودیت‌های احراز هویت و نرخ فراخوانی عبور می‌کنند، و حتی درخواست‌های ناامن یا نامعتبر تولید می‌نمایند.
گری مارشال (Gary Marshall)، از صداهای برجسته در حوزه هوش مصنوعی، LLMها را «غیرصادق، غیرقابل‌پیش‌بینی و بالقوه خطرناک» می‌نامد. صرف‌نظر از این‌که با او موافق باشید یا نه، تعامل LLMها با APIها باعث نگرانی جامعه توسعه‌دهندگان شده است.
به‌بیان ساده، LLMها بارها ثابت کرده‌اند که ناقض قراردادهای API هستند.
خطرات مصرف API توسط LLMها
نمونه‌های متعددی وجود دارد که نشان می‌دهد هوش مصنوعی می‌تواند تهدید امنیتی ایجاد کند.
برای مثال، در اوایل سال جاری، شرکت Invariant Labs آسیب‌پذیری‌ای را در سرور GitHub MCP افشا کرد که امکان دسترسی غیرمجاز به مخازن خصوصی را فراهم می‌کرد.
در جای دیگر، ربات پشتیبانی محصول Cursor به کاربران اعلام کرد که دیگر اجازه استفاده از محصول را روی چند دستگاه ندارند — خبری که بعداً مشخص شد کاملاً ساختگی و ناشی از «توهم» AI بوده است. بر اساس گزارش نیویورک تایمز، چنین توهماتی در حال افزایش‌اند.
اگر نمی‌توانیم به خروجی ابزارهای AI اعتماد کنیم، آیا واقعاً باید اجازه دهیم آنها APIها را فراخوانی یا مستندسازی کنند؟
مطالعه‌ای با عنوان Commercial LLM Agents Are Already Vulnerable to Simple Yet Dangerous Attacks نشان داد که عامل‌های LLM تجاری در برابر حملات ساده اما خطرناک آسیب‌پذیرند. در بخشی از این پژوهش آمده است:
«در استقرارهای واقعی، LLMها اغلب بخشی از یک زنجیره عامل‌محور بزرگ‌تر هستند که شامل سیستم‌های حافظه، بازیابی اطلاعات، دسترسی به وب و فراخوانی API است. این مؤلفه‌های اضافی آسیب‌پذیری‌هایی ایجاد می‌کنند که عامل‌های مبتنی بر LLM را بسیار آسان‌تر از مدل‌های ایزوله قابل حمله می‌سازند.»
پیش‌تر نوشته بودیم که کد تولیدشده توسط AI می‌تواند API شما را از بین ببرد — اما شاید باید پرسید: آیا مصرف API توسط AI نیز می‌تواند همین‌قدر خطرناک باشد؟
وایب‌کدینگ (Vibe-Coding)، تزریق پرامپت و Slopsquatting
طبق مقاله‌ای در TechRadar، خطرات جدیدی مانند «توهم بسته‌ها» و «slopsquatting» به شدت در حال گسترش است. مطالعه‌ای نشان داد که از میان ۵۷۶٬۰۰۰ نمونه و ۱۶ مدل LLM، حدود ۲۰٪ از ارجاعات بسته‌ها کاملاً توهمی بوده‌اند. از این میان، ۴۳٪ از این توهم‌ها تکرار شده‌اند — یعنی قابل سوءاستفاده‌اند.
تزریق پرامپت (Prompt Injection) نیز تهدیدی بزرگ است. OWASP اخیراً این نوع آسیب‌پذیری را در صدر فهرست «ده تهدید برتر امنیتی LLM» خود قرار داده است. APIها و نقاط پایانی بدون محافظت، بردارهای حمله‌ای مناسب برای چنین سناریوهایی محسوب می‌شوند.
در پژوهشی در سال ۲۰۲۴، محققان ۴۸ وظیفه برنامه‌نویسی را برای ۵ API امنیتی پرکاربرد بررسی کردند و دریافتند که:
در ۷۰٪ از کدهای تولیدشده توسط ChatGPT، خطا یا سوء‌استفاده از API امنیتی وجود داشته است، و ۲۰ نوع متفاوت از خطاها شناسایی شد.
افزایش محبوبیت ابزارهایی چون Lovable، Replit، Cursor و Bolt نیز منجر به پدیده‌ای به نام Vibe Coding شده است — یعنی تولید کد توسط افراد بدون سابقه فنی، صرفاً از طریق تعامل با هوش مصنوعی. هرچند این دموکراتیزه‌سازی برنامه‌نویسی جذاب است، اما خطرناک نیز هست، زیرا کاربران جدید بدون دانش کافی درباره احراز هویت، نرخ فراخوانی یا امنیت API، شروع به مصرف آنها می‌کنند.
نتیجه؟ ارائه‌دهندگان API باید آماده موجی از مصرف غیرمسئولانه توسط عامل‌های هوش مصنوعی باشند.
آینده مصرف API احتمالاً عامل‌محور است
خبر خوب این است که این خطرات تا حدی قابل پیشگیری‌اند. پژوهشی گسترده توسط Amazon نشان داد که نحوه مستندسازی می‌تواند توهم کد در LLMها را کاهش دهد. برخی از راهکارهای کلیدی عبارت‌اند از:
-
استفاده از مستندسازی ساختاریافته با مثال‌های واضح برای کمک به مدل‌ها در بازیابی دقیق‌تر داده‌ها
-
فرمت‌بندی منسجم و نام‌گذاری استاندارد برای بهبود بازیابی مبتنی بر RAG
-
نگهداری مستندات قابل‌خواندن توسط ماشین (مانند OpenAPI) برای اعتبارسنجی خودکار
-
استفاده از نام‌های توصیفی و یکنواخت (مثلاً get_item به جای fetch_item) برای جلوگیری از هم‌معنایی‌های اشتباه
-
نشانه‌گذاری APIهای منسوخ و ارائه یادداشت‌های مهاجرت برای جلوگیری از اشتباهات
«پل دوماس» اعلام کرد که آینده‌ی توسعه و مصرف APIها در دست عامل‌های هوش مصنوعی است. اکنون، تنها یک سال بعد، این آینده در حال وقوع است. آماده شدن برای «مصرف عامل‌محور» دیگر یک انتخاب نیست — بلکه یک ضرورت است.
از سوی دیگر، باید به خطر شماره ۶ در فهرست OWASP برای امنیت LLMها نیز توجه کرد: Excessive Agency (اختیارات بیش‌ازحد). دادن سطح دسترسی مشابه انسان‌ها به یک عامل LLM ممکن است فاجعه‌آفرین باشد.
آماده‌سازی و کاهش تأثیر LLMها بر APIها
در حالت ایده‌آل، کاربرانی که با LLMها تعامل دارند، باید تدابیر احتیاطی بیندیشند؛ از جمله:
-
تعریف نقش‌های دقیق برای جلوگیری از خروج مدل از محدوده مجاز
-
افزودن محدودیت‌ها برای رفتارهای پرخطر
-
واداشتن LLM به خودارزیابی یا تأیید کاربر پیش از اقدام.
اما در عمل، این مسئولیت اغلب بر دوش ارائه‌دهندگان API می‌افتد.
اقدامات پیشنهادی:
-
پیاده‌سازی کنترل دسترسی مبتنی بر نقش (RBAC) برای عامل‌های AI
-
افزودن فرایند تأیید انسانی (Human-in-the-Loop) برای عملیات حساس
-
استفاده از مدل اعتماد صفر (Zero Trust) برای افزونه‌ها
-
فعال‌سازی ثبت و نظارت بلادرنگ (Audit Logging & Observability) برای ردیابی درخواست‌های تولیدشده توسط LLM
به‌زودی، حاکمیت هوش مصنوعی (AI Governance) بخشی حیاتی از حاکمیت API (API Governance) خواهد شد. این شامل مهندسی ایمن پرامپت‌ها، کنترل‌های عملیاتی و مجوزهای عامل‌ها است.
در نهایت، مدل‌های زبانی بزرگ باید هم‌زمان به عنوان نرم‌افزار و عامل تصمیم‌گیرنده در نظر گرفته شوند. هدف همیشه این بوده که APIها را به‌گونه‌ای طراحی کنیم که نه تنها در برابر حملات، بلکه در برابر مصرف ناآگاهانه نیز مقاوم باشند — و اکنون این هدف بیش از هر زمان دیگری اهمیت دارد.
در دنیایی که LLMها می‌توانند هم خالق و هم مصرف‌کننده API باشند، غفلت از این واقعیت ممکن است به قیمتی سنگین تمام شود.
