ProxyKey دسترسی عامل‌های هوش مصنوعی به API را بدون افشای کلیدها ممکن کرد

اگر امروز کلید API خود را به یک عامل هوش مصنوعی می‌دهید، در واقع آن را در اختیار یک اسکریپت ناشناس در اینترنت قرار داده‌اید. این ریسک امنیتی اکنون با راهکاری از سوی Hikmah Labs به نام ProxyKey که در ۱۱ سپتامبر ۲۰۲۶ منتشر شد، به پایان می‌رسد. این پروژه راهکاری را ارائه می‌دهد که اشتراک‌گذاری اسرار (Secret-sharing) را با یک مجموعه ابزار در سطح پروتکل از طریق پروتکل زمینه مدل (MCP) جایگزین می‌کند.

بسیاری از توسعه‌دهندگان در حال حاضر کلیدهای خود را در فایل‌های .env یا متغیرهای محیطی (Environment Variables) ذخیره می‌کنند. اما عامل‌هایی مانند Claude Code یا Cursor معمولاً اقدامات خود را ثبت می‌کنند، تنظیمات را روی دیسک می‌نویسند و متغیرهای محیطی را نمایش می‌دهند. طبق گزارش‌های امنیتی، هر داده‌ای که وارد پنجرهٔ زمینه (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — شود، باید به عنوان دادهٔ منتشرشده تلقی شود؛ زیرا این داده‌ها لاگ می‌شوند، ردیابی می‌شوند و می‌توانند از طریق تزریق پرامپت (Prompt Injection) استخراج شوند. بنابراین، برخورد با یک رمز به عنوان یک متغیر ساده، یک نقص امنیتی بحرانی است. این چالش‌ها در تحلیل ما درباره‌ی پروتکل MCP و مرزهای امنیتی جدید در مواجهه با تزریق پرامپت به تفصیل بررسی شده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به سیاست‌های داخلی مدل برای حفظ اسرار، یک اشتباه استراتژیک است. ProxyKey پارادایم را تغییر می‌دهد و به جای دادن «رمز»، به عامل یک «ابزار» می‌دهد. در این ساختار، عامل با یک سرور پروکسی تعامل می‌کند که تماس‌های واقعی با ارائه‌دهندگانی مثل OpenAI یا تلگرام را مدیریت می‌کند. عامل می‌تواند دستور اجرا دهد، اما هرگز به متن خام کلید دسترسی ندارد. سرور MCP در ProxyKey این مسئله را در سطح پروتکل حل می‌کند، به جای اینکه به سیاستی تکیه کند که انتظار می‌رود عامل از آن پیروی کند.

ادغام با MCP

برای اتصال این سامانه، یک انسان باید در سایت app.proxykey.org با استفاده از GitHub OAuth یا یک لینک جادویی (Magic Link) که به صورت رایگان در دسترس است، وارد شود. کاربر بخش MCP را باز کرده و توکنی با فرمت mcp_... می‌سازد. این توکن تنها اعتبارنامه‌ای است که به عامل می‌رسد و کلیدهای واقعی ارائه‌دهندگان هرگز با عامل تماس ندارند.

برای Claude Code، کاربران می‌توانند سرور را با یک دستور واحد اضافه کنند:
claude mcp add --transport http proxykey https://mcp.proxykey.org/mcp --header "Authorization: Bearer mcp_YOUR_TOKEN"

برای Cursor و Claude Desktop، این ادغام از طریق یک ورودی در فایل mcp.json انجام می‌شود:

{
  "mcpServers": {
    "proxykey": {
      "url": "https://mcp.proxykey.org/mcp",
      "headers": {
        "Authorization": "Bearer mcp_YOUR_TOKEN"
      }
    }
  }
}

پس از اتصال، عامل قابلیت‌های ProxyKey را به عنوان ابزارهای استاندارد MCP می‌بیند و این به او اجازه می‌دهد بدون نیاز به حضور انسان در حلقه (Human-in-the-loop) برای هر درخواست، عملیات را پیش ببرد.

۱۳ ابزار برای مدیریت اسرار

سرور MCP این پروژه ۱۳ متد تخصصی را در سه دسته عملکردی ارائه می‌دهد:

• کاتالوگ و متادیتا (Catalogue and Metadata):
  • list_providers: لیست ارائه‌دهندگان موجود و مدل‌های احراز هویت خاص آن‌ها را نمایش می‌دهد.
  • list_secrets: کلیدهای ذخیره شده و متادیتا را نشان می‌دهد؛ اما هرگز مقادیر کلید را برنمی‌گرداند.
  • get_manual_secret_setup: لینکی را برمی‌گرداند تا یک انسان بتواند کلید واقعی را وارد کند.
• مدیریت دسترسی (Pass Management):
  • عامل می‌تواند چرخه کامل یک توکن مجازی را با استفاده از متدهای create_pass ،create_pending_pass ،update_pass ،rotate_pass ،revoke_pass ،delete_pass و rebind_pass_ip اجرا کند.
• قابلیت مشاهده (Observability):
  • ابزارهایی مانند list_passes ،get_pass_logs و get_pass_stats به عامل اجازه می‌دهند وضعیت هر Pass، اتصال IP، تاریخچه درخواست‌ها و محدودیت‌ها را نظارت کند.

به نقل از مستندات ProxyKey، قرارداد API به‌طور عمدی هرگونه عملیات «خواندن کلید» را حذف کرده است. این یک سیاست اخلاقی نیست که مدل به آن اعتماد کند، بلکه نقطه انتهایی (Endpoint) برای این کار در API وجود ندارد. به همین دلیل، سطح MCP نمی‌تواند لاگ‌های بدنه درخواست (Request-body logging) را فعال کند. این قابلیت فقط برای انسان در پنل مدیریت در دسترس است تا از بازسازی غیرمستقیم کلید از طریق لاگ‌ها جلوگیری شود. این رویکرد مشابه راهکاری است که Infisical برای حذف اعتبارنامه‌ها از لاگ‌ها در Agent Vault به کار گرفته است.

حل بن‌بست «اسرار در انتظار»

یکی از کاربردهای اصلی این سیستم، استقرار بات‌هایی است که هنوز توکن ندارند. برای مثال، عاملی که در حال استقرار یک بات تلگرام است، کد را می‌نویسد و وب‌هوک (Webhook) را متصل می‌کند، اما هنوز توکن BotFather وجود ندارد زیرا بات هنوز ساخته نشده است.

به جای متوقف شدن و انتظار برای انسان، عامل متد create_pending_pass را فراخوانی می‌کند. این دستور بلافاصله یک توکن مجازی (vlt_...) صادر می‌کند. عامل می‌تواند این توکن را مستقیماً در تنظیمات بات قرار دهد. با این حال، پروکسی کردن ترافیک واقعی با وضعیت original_key_required مسدود می‌ماند تا زمانی که رمز واقعی وارد شود.

سپس عامل متد get_manual_secret_setup را فراخوانی کرده و لینک حاصل را به انسان می‌دهد. کاربر لینک را باز کرده، توکن واقعی را یک بار در پنل می‌چسباند و Pass به‌طور خودکار فعال می‌شود. هیچ تماس دومی از سوی عامل لازم نیست و بات فعال می‌شود. در هیچ مرحله‌ای، مقدار رمز از بستر مدل عبور نکرد و مستقیماً از طریق پنل منتقل شد.

مکانیزم پروکسی

زمانی که یک Pass صادر شد، اپلیکیشن یا عامل به جای ارائه‌دهنده، به پروکسی اشاره می‌کند. در این حالت فقط میزبان (Host) و کلید تغییر می‌کنند؛ مسیر (Path) و بدنه (Body) درخواست ثابت می‌مانند.

مثال تماس OpenAI:

• قبل از ProxyKey: curl https://api.openai.com/v1/chat/completions -H "Authorization: Bearer sk-..."
• بعد از ProxyKey: curl https://api.proxykey.org/p/openai/v1/chat/completions -H "Authorization: Bearer vlt_openai_..."

استریم‌ها (SSE)، بدنه‌های درخواست و هدرها بدون تغییر منتقل می‌شوند. بات‌های تلگرام نیز شکل معمول URL خود را از طریق /p/telegram-bot/<pass>/getMe حفظ می‌کنند.

تحلیل تبادلات امنیتی

Hikmah Labs صراحتاً اشاره می‌کند که هیچ پروکسی میزبانی‌شده‌ای نمی‌تواند به دلیل طراحی، کاملاً «دانش-صفر» (Zero-Knowledge) باشد. برای قرار دادن یک کلید در درخواستی که به ارائه‌دهنده ارسال می‌شود، پروکسی باید در لحظه مدیریت آن درخواست، کلید را در حافظه رمزگشایی کند. این بدان معناست که یک فرآیند با دسترسی کامل — و اپراتور سرویس — در اصل می‌توانند به متن ساده دسترسی پیدا کنند.

این یک ویژگی کلی در تمام راهکارهای میزبانی‌شده در این دسته است و نه یک نقص خاص در ProxyKey. این معماری در برابر رایج‌ترین نشت‌ها مانند نفوذ به دیتابیس، سرقت بک‌آپ‌ها و نشت لاگ‌ها محافظت می‌کند، اما در برابر نفوذ کامل به سرور محافظت نمی‌کند. دسترسی MCP عامل ریسک جدیدی اضافه نمی‌کند؛ بلکه محدودتر از دسترسی انسان از طریق پنل است. برای تکمیل این زنجیره امنیتی، می‌توان از آداپتور Universal Trust برای تأیید اعتبار هویت عامل‌ها در کنار لایه‌های پروکسی استفاده کرد.

چه زمانی از ProxyKey استفاده نکنیم؟

این راهکار برای هر سناریویی مناسب نیست. این سیستم یک نقطه شکست (Point of failure) و مقدار کمی تأخیر (در حد تک‌رقمی میلی‌ثانیه) به دلیل پرش اضافی و جستجوی کشِ اعتبارسنجی اضافه می‌کند. در حالی که این تأخیر برای زمان تولید متن توسط LLM نامحسوس است، اما ممکن است برای APIهای غیر LLM که به تأخیر بسیار کم حساس هستند، اهمیت داشته باشد.

از ProxyKey اجتناب کنید اگر:

• تنها یک کلید و یک مصرف‌کننده دارید، در محیطی که کاملاً تحت کنترل شماست و هیچ عاملی هرگز به آن دسترسی ندارد.
• مدل تهدید شما هرگونه شخص ثالث در زنجیره درخواست را ممنوع می‌کند، زیرا پروکسی ترافیک را می‌بیند (حتی اگر فقط متادیتا را لاگ کند). در این حالت، نمونه شخصی (Self-hosted) از این الگو را اجرا کنید.

این تغییر در مدیریت اعتبارنامه‌ها به این معناست که پنجره زمینه مدل دیگر یک نقطه ضعف برای امنیت API نیست. با محدود کردن قرارداد بین عامل و رمز، توسعه‌دهندگان می‌توانند استقرارهایی را خودکار کنند که پیش از این به دلیل نیاز به حضور انسان برای وارد کردن کلیدها، مسدود شده بودند.

گام بعدی شما

• اگر از Cursor یا Claude Code برای مدیریت پروژه‌های واقعی استفاده می‌کنید، توکن‌های خود را از محیط .env به یک لایه پروکسی منتقل کنید.
• برای بات‌هایی که در حال توسعه هستند، از متد create_pending_pass استفاده کنید تا چرخه استقرار را بدون توقف انسانی پیش ببرید.
• در صورت نیاز به امنیت حداکثری، نسخه شخصی (Self-hosted) این الگو را روی سرورهای خود پیاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.