تصور کنید یک توسعه‌دهنده هستید که باید امنیت ترافیک هوش مصنوعی را در محیط‌های ابری پراکنده مدیریت کند؛ جایی که درگاه‌های API استاندارد عملاً ناتوان‌اند. طبق گزارشی که در ۴ سپتامبر ۲۰۲۶ در dev.to منتشر شد، Kong AI Gateway 2.0 با تغییر نگاه به مدل‌ها و عامل‌ها به‌عنوان موجوداتی درجه‌یک (به‌جای نقاط انتهایی HTTP ساده)، این شکاف امنیتی را پر می‌کند.
بسیاری از سازمان‌ها امروزه محاسبات خود را بین Google Kubernetes Engine (GKE) برای سرویس‌های حالت‌دار و Cloud Run برای APIهای بدون سرور تقسیم می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی چارچوب تصمیم‌گیری بین Gemini API و Vertex AI اشاره کردیم، این پراکندگی اغلب تیم‌ها را مجبور می‌کند تا برای فراخوانی‌های مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — و عامل‌های خودکار، لایه‌های امنیتی تکراری بسازند.
درگاه‌های سنتی از یک جریان خطی «کلاینت $\rightarrow$ درخواست $\rightarrow$ پاسخ» استفاده می‌کنند. اما معماری‌های هوش مصنوعی بر حلقه‌های عامل‌محور (Agentic) غیرخطی متکی هستند که کنترل‌های خاصی می‌طلبند. این نیاز به کنترل دقیق‌تر زمانی حیاتی می‌شود که با عامل‌های خودمختاری که قادر به کشف و استثمار حفره‌های امنیتی API هستند روبرو هستیم. به نقل از گزارش dev.to، نسخه ۲.۰ این درگاه، این نیازها را از طریق یک مدل انتزاعی جدید پیاده‌سازی کرده است:
- تأمین‌کنندگان و مدل‌های AI: بک‌اندهایی مجزا که مدیریت استخر اتصال و مسیریابی اعتبارنامه‌ها را بر عهده دارند.
- سرورهای AI MCP: موجوداتی درجه‌یک برای تأمین‌کنندگان ابزار که از پروتکل زمینه مدل (MCP) استفاده می‌کنند.
- عامل‌های AI و مسیریابی A2A: مجراهای امن برای مذاکرات بین‌عاملی.
- مصرف‌کنندگان و سیاست‌های AI: مرزهای آگاه از هویت برای کنترل هزینه‌ها و حفاظ‌های پرامپت.
نحوه استقرار بسته به محیط اجرا تغییر می‌کند تا از نقاط قوت گوگل‌کلاود استفاده شود. در GKE، صفحه داده از Kong Kubernetes Operator (KKO) و هویت کاری (Workload Identity) استفاده می‌کند تا نیاز به کلیدهای استاتیک حساب‌های سرویس را از بین ببرد. در Cloud Run، درگاه به‌عنوان یک لایه امنیتی متمرکز عمل می‌کند و سرویس‌های بدون سرور را در ورودی‌های داخلی خصوصی نگه می‌دارد.
یکپارچگی با مدل‌های Vertex AI و Gemini از طریق خروجی‌های مبتنی بر IAM مدیریت می‌شود. این ساختار به درگاه اجازه می‌دهد تا توکن‌های OAuth را صادر کرده و جایگزین‌های مجازی برای مدل‌ها تعریف کند؛ مثلاً اگر درخواست Gemini Ultra شکست بخورد، آن را بدون تغییر در کد کلاینت به Gemini Flash مسیریابی کند.
حاکمیت پیشرفته بر عامل‌ها
یکی از حیاتی‌ترین قابلیت‌های جدید، بسته‌بندی سرورهای MCP است. به‌جای اینکه یک عامل (Agent) — شبیه دستیاری که می‌تواند ابزارهای مختلف را برای انجام یک کار به کار بگیرد — به ده‌ها نقطه انتهایی متصل شود، Kong این‌ها را در یک نقطه واحد تجمیع می‌کند. درگاه، مذاکرات لیست ابزارها را رهگیری می‌کند؛ اگر عاملی اجازه دسترسی به ابزاری خاص را نداشته باشد، آن قابلیت از پاسخ حذف می‌شود تا از اجراهای غیرمجاز جلوگیری شود. این سطح از مدیریت دسترسی، پیش‌نیاز توسعه سیستم‌های مالی مستقل برای ربات‌هاست که در آن عامل‌های AI باید با امنیت کامل تراکنش‌های خود را مدیریت کنند.
علاوه بر این، حاکمیت عامل-به-عامل (A2A) احراز هویت متقابل را برقرار کرده و گراف‌های اجرا را ردیابی می‌کند. این سازوکار از حلقه‌های بازگشتی بی‌رویه که اغلب باعث کرش کردن خط لوله‌های عامل‌های خودکار در محیط عملیاتی می‌شود، جلوگیری می‌کند.
این تغییر، فرض بنیادی زیرساخت AI را از «مدیریت نقاط انتهایی» به «حاکمیت بر primitives» تغییر می‌دهد. با جداسازی پیکربندی از طریق Kong Konnect از صفحه داده، سازمان‌ها می‌توانند عملیات AI خود را در شبکه‌های خصوصی مقیاس کنند بدون اینکه صفحات کنترل خود را در معرض جریان مستقیم داده‌ها قرار دهند.
برای یک توسعه‌دهنده، این یعنی انتخاب بین GKE و Cloud Run دیگر تعیین‌کننده سطح امنیت عامل AI نیست. درگاه، پیچیدگی‌های محاسباتی زیرین را جذب کرده و یک سطح واحد برای مشاهده‌پذیری و مدیریت هزینه‌ها فراهم می‌کند.
گام بعدی شما
- بررسی کنید که آیا درگاه API فعلی شما از محدودیت نرخ توکن‌محور پشتیبانی می‌کند یا صرفاً بر اساس تعداد درخواست‌ها عمل می‌کند.
- اگر از معماری چندعاملی استفاده می‌کنید، مدل A2A Kong را برای جلوگیری از حلقه‌های بازگشتی (Recursion Loops) ارزیابی کنید.
- استراتژی Fallback مدل‌ها را برای کاهش تأخیر و هزینه در Vertex AI پیاده‌سازی کنید.
اما مدیریت هزینه‌های استنتاج در مقیاس میلیونی داستان پیچیده‌تری دارد — به تحلیل ما درباره بهینه‌سازی GPUها مراجعه کنید.
گفتگو