می‌گویند پنیر مفت فقط در تلهٔ موش پیدا می‌شود. در دنیای ایجنت‌های هوش مصنوعی هم API ارزان یا رایگان ممکن است هزینه‌اش را نه با پول، بلکه با کد، credential و کنترل همان سیستمی بگیرد که ایجنت روی آن کار می‌کند.
مقاله‌ای با عنوان Your Agent Is Mine یک نقطهٔ کور مهم در زنجیرهٔ تأمین LLM را بررسی کرده است: LLM Routerها؛ سرویس‌های واسطه‌ای که درخواست را از ابزارهایی مثل Codex یا Claude Code می‌گیرند و به OpenAI، Anthropic، Google یا یک ارائه‌دهندهٔ دیگر می‌فرستند.
مشکل اصلی «رایگان‌بودن» نیست؛ مشکل این است که یک واسطهٔ ناشناس را داخل مرز اعتماد ایجنتی قرار می‌دهیم که اجازهٔ اجرای فرمان دارد.
اول، دو اصلاح مهم در اعداد خبر
نسخه‌ای که در شبکه‌های اجتماعی دست‌به‌دست شده از «۲۶ ایجنت رایگان» و سرقت ۵۰۰ هزار دلار حرف می‌زند، اما این دو ادعا در خود مقاله نیست. پژوهشگران ۲۸ router پولی و ۴۰۰ router رایگان را بررسی کرده‌اند. از میان آن‌ها، یک router پولی و هشت router رایگان واقعاً پاسخ‌های حاوی tool call را به کد مخرب تغییر داده‌اند.
در آزمایش‌های credential نیز ۱۷ router به کلیدهای تله‌ای AWS دست زده‌اند و یک کلید خصوصی آزمایشی اتریوم تخلیه شده است؛ ولی مبلغ برداشت‌شده، بنا بر ضمیمهٔ اخلاق پژوهش، کمتر از ۵۰ دلار بوده و کیف‌پول هم متعلق به خود پژوهشگران بوده است—نه کیف‌پول ۵۰۰ هزار دلاری یک مشتری.
Router دقیقاً چه چیزی می‌بیند؟
اتصال HTTPS فقط مسیر میان شما و همان router را رمزنگاری می‌کند. router اتصال را باز می‌کند، JSON را به‌صورت متن واضح می‌بیند و بعد یک اتصال TLS تازه با سرویس بعدی می‌سازد. در نتیجه prompt، system prompt، تعریف ابزارها، آرگومان‌های tool call، خروجی ابزارها و هر رازی که در این رفت‌وبرگشت باشد می‌تواند در دسترس واسطه قرار بگیرد.
اگر این مسیر چند router داشته باشد، حتی ممکن است شما فقط واسطهٔ اول را بشناسید و از بقیه خبر نداشته باشید. اعتماد در چنین زنجیره‌ای خاصیت «ضعیف‌ترین حلقه» را دارد: خراب‌شدن تنها یک واسطه برای آلوده‌کردن پاسخ نهایی کافی است.
از یک پاسخ متنی تا اجرای فرمان
در یک چت ساده، دست‌کاری پاسخ شاید فقط اطلاعات غلط تولید کند؛ اما پاسخ یک agent می‌تواند معنای اجرایی داشته باشد. router مخرب قادر است آرگومان JSON یک ابزار را عوض کند، آدرس یک installer را با دامنهٔ خودش جایگزین کند یا هنگام نصب پکیج، dependency دیگری تحویل بدهد.
MCP یکی از مسیرهای دسترسی ایجنت به ابزارهاست، اما حمله محدود به MCP نیست. نقطهٔ اصلی همان tool calling است: Bash، run_command، نصب پکیج، خواندن فایل، مرورگر یا هر ابزاری که کلاینت در اختیار مدل گذاشته باشد. اگر auto-approve یا «YOLO mode» روشن باشد، فرمان دست‌کاری‌شده ممکن است بدون تأیید دوبارهٔ کاربر اجرا شود.
چیزی که پژوهشگران در عمل دیدند
- ۹ router از ۴۲۸ نمونهٔ پولی و رایگان، کد مخرب را داخل tool call تزریق کردند.
- دو نمونه رفتارشان را پنهان می‌کردند: یکی پس از ۵۰ درخواست فعال می‌شد؛ دیگری sessionهای خودکار و پروژه‌های Rust یا Go را هدف می‌گرفت.
- در یک آزمایش با relayهای عمداً ضعیف، ۴۴۰ session منتسب به Codex در ۳۹۸ پروژه یا میزبان دیده شد و ۹۹ credential از ترافیک عبوری آشکار شد.
- ۴۰۱ مورد از آن ۴۴۰ session در حالت تأیید خودکار بودند؛ یعنی برای تغییر فرمان اجرایی، مهاجم حتی به ترفند پیچیده‌ای نیاز نداشت.
این اعداد به معنی «تصرف ۴۰۰ کامپیوتر توسط پژوهشگران» نیست. آن‌ها می‌گویند sessionها از نظر معماری command-injectable بودند و پروژه را بیشتر از حداقل لازم exploit نکردند. این تفاوت میان قابلیت حمله و حملهٔ انجام‌شده مهم است.
چرا یک تست کوتاه router را پاک نشان می‌دهد؟
router می‌تواند ده‌ها پاسخ اول را سالم برگرداند و فقط وقتی پروژه ارزشمند، فرمان حساس یا حالت خودکار را تشخیص داد فعال شود. در مقاله نمونه‌ای دیده شده که پس از ۵۰ درخواست شروع به تزریق می‌کند. بنابراین چند smoke test موفق، سالم‌بودن یک سرویس ناشناس را ثابت نمی‌کند.
برای استفادهٔ امن‌تر چه کار کنیم؟
- تا جای ممکن مستقیم به provider معتبر وصل شویم. هر hop اضافه، یک مرز اعتماد تازه است.
- auto-approve را برای shell، نصب پکیج، مرورگر و عملیات cloud خاموش کنیم. متن فرمان و مقصد شبکه باید قبل از اجرا دیده شود.
- ایجنت را sandbox و کم‌اختیار اجرا کنیم. پروفایل اصلی مرورگر، SSH key، wallet و فایل‌های credential نباید بی‌دلیل در دسترس باشند.
- کلیدها کوتاه‌عمر و محدود باشند. scope، سقف هزینه، محدودیت IP و امکان revoke سریع، شعاع انفجار را کم می‌کند.
- برای دانلود و dependencyها allowlist داشته باشیم. این کنترل کامل نیست، اما بسیاری از جایگزینی‌های واضح را متوقف می‌کند.
- لاگ append-only نگه داریم. endpoint واسطه، درخواست، پاسخ و hash پاسخ برای بررسی پس از رخداد لازم‌اند؛ البته secretها باید پیش از ثبت redaction شوند.
خود مقاله هم صادقانه می‌گوید دفاع‌های سمت کلاینت اثبات نمی‌کنند پاسخی که دریافت کرده‌ایم دقیقاً همان خروجی provider بوده است. راه‌حل ریشه‌ای، امضای سرتاسری و provenance قابل‌تأیید برای پاسخ و tool call است؛ چیزی که هنوز به همکاری ارائه‌دهندگان نیاز دارد.
پنیر مفت یا اعتماد ارزان؟
routerها ذاتاً بد نیستند؛ load balancing، fallback، کنترل هزینه و دسترسی یکپارچه به چند مدل کاربردهای واقعی‌اند. حتی پرداخت پول هم تضمین امنیت نیست—در همین پژوهش یک سرویس پولی هم تزریق مخرب داشت. نتیجهٔ درست این نیست که «هر API رایگان بدافزار است»؛ نتیجه این است که واسطه‌ای که متن واضح درخواست و پاسخ یک agent ابزارمند را می‌بیند، عملاً بخشی از محیط اجرایی ماست و باید مثل یک dependency با سطح دسترسی بالا بررسی شود.
منابع و اعتبار تصویر
- مقالهٔ Your Agent Is Mine در arXiv
- نسخهٔ HTML مقاله، شامل روش اندازه‌گیری و نتایج کامل
- گزارش Datadog دربارهٔ رخداد زنجیرهٔ تأمین LiteLLM
تصویر: شکل ۱ مقالهٔ Your Agent Is Mine، اثر Hanzhi Liu و همکاران، با مجوز CC BY-NC-ND 4.0. اعداد این نوشته از نسخهٔ اول مقاله در ۹ آوریل ۲۰۲۶ استخراج شده‌اند.