نشت کلیدهای خصوصی کیف‌پول‌ها از طریق روترهای واسط هوش مصنوعی

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

بسیاری از توسعه‌دهندگان به لاگ‌های حسابرسی (Audit Logs) روترهای مدل زبانی بزرگ — مثل دفتری که تمام تراکنش‌ها را ثبت می‌کند تا بعداً بررسی شوند — به چشم یک ترمز اضطراری نگاه می‌کنند؛ اما در واقعیت، این لاگ‌ها تنها رسیدِ سرقت هستند، نه مانعی برای آن. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش هزینه‌های استنتاج با خروج از سرویس‌های گران‌قیمت (مانند OpenAI) اشاره کردیم، جایی که هزینه‌های ماهانه از ۴۲۰۰ دلار به ۳۱۲ دلار کاهش یافت، حالا باید به هزینه‌های پنهان امنیتی این واسطه‌ها توجه کنیم. وقتی ترافیک خود را برای مدیریت هزینه، ردیابی یا جایگزینی مدل‌ها (Failover) از یک درگاه یا گیت‌وی عبور می‌دهید، در واقع کلیدهای قلعه خود را به دست یک شخص ثالث می‌سپارید.

زنگ خطر ۵۰۰ هزار دلاری

این خطر فرضی یا تئوریک نیست. در ۹ آوریل ۲۰۲۶، گروهی از پژوهشگران به سرپرستی Chaofan Shou مقاله‌ای با عنوان «عامل شما مال من است: اندازه‌گیری حملات واسطه‌های مخرب در زنجیره تأمین LLM» (با کد arXiv 2604.08407) منتشر کردند. این تیم ترافیک واقعی عامل‌های هوشمند را به ۴۲۸ روتر تجاری و رایج هدایت کردند و متوجه شدند که یک فقدان سیستماتیک در یکپارچگی رمزنگاری (Cryptographic Integrity) بین کلاینت‌ها و مدل‌های بالادستی وجود دارد.

به گزارش این تیم پژوهشی و پوشش خبری بعدی توسط CoinDesk در ۱۳ آوریل ۲۰۲۶، نتایج تکان‌دهنده بود:

• ۹ روتر به‌طور مستقیم کدهای مخرب را به پاسخ‌های مدل تزریق کردند.
• ۱۷ روتر سعی کردند به اعتبارنامه‌های AWS (دسترسی‌های ابری) پژوهشگران دسترسی پیدا کنند.
• ۲۶ روتر به‌صورت مخفیانه فراخوانی‌های ابزار (Tool Calls) مخرب را تزریق و اعتبارنامه‌ها را سرقت کردند.
• یک روتر خاص موفق شد ۵۰۰ هزار دلار از کیف‌پول یکی از مشتریان را به‌طور کامل تخلیه کند.

سازوکار نشت داده‌ها

این روترها به‌عنوان پروکسی‌های لایه اپلیکیشن عمل می‌کنند و دسترسی کامل به محتوای متن ساده (Plaintext) تمام بسته‌های JSON در حال انتقال دارند. اگر عامل (Agent) — سیستمی که مثل یک دستیار دیجیتال می‌تواند به‌تنهایی تصمیم بگیرد و ابزارها را اجرا کند — یک راز یا کلید را در آرگومان‌های یک فراخوانی ابزار ارسال کند، پردازشگر روتر بلافاصله آن را می‌خواند. اشتباه حیاتی در اینجا، باور به نقش لاگ‌های حسابرسی است. لاگ، یک رسید است، نه ترمز. تا زمانی که یک اعتبارنامه در لاگ ظاهر شود، پردازشگر روتر پیش‌تر آن را در حالت متن ساده خوانده و کپی کرده است.

ثبت لاگ در آن سوی مرز شبکه اتفاق می‌افتد؛ یعنی راز شما پیش‌تر ارسال شده و رفته است. شما نمی‌توانید با خواندن یک کپی کربنی، نامه‌ای را که ارسال شده است پس بگیرید. این موضوع برای متریال‌های امضا‌کننده (Signer Material) فاجعه‌بار است؛ چرا که در حالی که یک کلید API را می‌توان روز دوشنبه تغییر داد (Rotate)، یک کلید خصوصی کیف‌پول تنها برای امضای یک تراکنش کافی است. پس از آن که شخص ثالث کلید را به دست آورد، دارایی‌ها تنها با یک فراخوانی sign_tx جابه‌جا می‌شوند.

کاوشگر نشت مرزی (Boundary Leak Probe)

برای حل این مشکل، ابزار boundary_leak_probe.py توسعه یافته است تا امنیت را به مراحل قبل از ارسال (Upstream) منتقل کند. ایده اصلی این است: ابتدا مقصد را طبقه‌بندی کن، هر چه نباید عبور کند را حذف (Redact) کن و سپس بایت‌ها را ارسال کن. این‌گونه لاگ‌ها تبدیل به سندی از «آنچه اجازه خروج داشت» می‌شوند، نه هشدار پس از وقوع خسارت. این رویکرد مکمل راهکارهای پیشرفته‌تری است که با استفاده از سدهای ریاضی در Aegis-Layer تلاش می‌کنند نشت داده‌ها را در میلی‌ثانیه‌ها متوقف کنند.

این ابزار یک «نقشه خروجی» (Egress Map) را تحلیل می‌کند؛ یک فایل JSON شامل درخواست‌های خروجی، میزبان‌های مقصد، نوع درخواست، هدرها و بدنه‌ها. این نقشه می‌تواند از یک بازرس درخواست (Request Interceptor) یا یک محیط تست استخراج شود. این کاوشگر بسیار سبک و ایمن است: فقط از کتابخانه‌های استاندارد پایتون (sys, json, re) استفاده می‌کند، هیچ درخواست شبکه‌ای نمی‌فرستد، از هیچ مدلی استفاده نمی‌کند و هیچ کدی را اجرا نمی‌نماید. اجرای این ابزار به‌صورت بایت-به-بایت قطعی (Deterministic) است.

شناسایی نشت‌ها بر دو گیت منطقی استوار است:

۱. اعتماد به مقصد (Destination Trust): کاربر میزبان‌های شخص اول (first_party_hosts) مانند بک‌اند شخصی یا ارائه‌دهنده مستقیم مدل را تعریف می‌کند. ارسال هدر Authorization به این میزبان‌ها مسیر مورد انتظار است و علامت‌گذاری نمی‌شود. هر مقصد دیگری — از جمله روترها، گیت‌وی‌ها و پروکسی‌های پروتکل زمینه مدل (MCP) — به‌طور پیش‌فرض شخص ثالث تلقی می‌شود. هر رازی در بدنه یا آرگومان‌های ابزاری که به این مقاصد می‌رود، به معنای عبور از مرزی است که شما مالک آن نیستید.

۲. متریال‌های حساس (Signer Material): برخی رازها «همواره نشت‌کننده» تعریف می‌شوند. کلید خصوصی اتریوم یا عبارت بازیابی (Mnemonic) BIP-39 هرگز نباید از هیچ واسطی عبور کنند، حتی اگر مقصد شخص اول باشد. هیچ مسیر قانونی برای ارسال یک عبارت seed از طریق پروکسی وجود ندارد. اگر کاوشگر چنین موردی ببیند، بدون توجه به مقصد، آن را با وضعیت CRITICAL (بسیار حساس) علامت می‌زند.

جزئیات فنی و قواعد تشخیص

منطق شناسایی رازها (Secret Detection Logic)
این ابزار از مجموعه‌ای از عبارات منظم (Regular Expressions) برای شناسایی شکل‌های خاص رازها استفاده می‌کند. متغیر SECRET_RULES هم الگو و هم سطح حساسیت (critical بودن یا نبودن) را تعریف می‌کند:

• eth_private_key: الگوی \b0x[0-9a-fA-F]{64}\b (بسیار حساس/Critical)
• bip39_mnemonic: الگوی \b(?:[a-z]{3,8}\s+){11,23}[a-z]{3,8}\b (بسیار حساس/Critical)
• aws_access_key: الگوی \bAKIA[0-9A-Z]{16}\b
• openai_key: الگوی \bsk-[A-Za-z0-9]{20,}\b
• bearer_token: الگوی Bearer\s+[A-Za-z0-9._\-]{16,}
• github_pat: الگوی \bghp_[A-Za-z0-9]{36}\b

مدیریت ارجاعات امن (Safe Reference Handling)
ابزار از قاعده SAFE_REF برای شناسایی مقادیری استفاده می‌کند که پیش از ارسال خنثی شده‌اند. الگوهای شناسایی شده عبارتند از:

• ارجاعات محیطی: ${OPENAI_KEY}
• دستگیره‌های والت: $VAULT_REF:openai
• مقادیر ماسک‌شده: sk-*** یا ****
• تگ‌های حذف شده: <REDACTED:...>

اگر یک مقدار تنها یک «دستگیره» (Handle) باشد، راز واقعی در لبه‌ی مورد اعتماد جایگزین می‌شود و نه در بدنه پیام. کاوشگر این معماری را تشویق کرده و در این حالت سکوت می‌کند.

فرآیند طبقه‌بندی (Classification Process)
کاوشگر به‌صورت بازگشتی (Recursively) تمام رشته‌های موجود در لایه‌های JSON درخواست را پیمایش می‌کند. یک نشت زمانی رخ می‌دهد که: مقصد «شخص ثالث» باشد یا راز «بسیار حساس» (Critical) باشد. تنها استثنا، ارسال یک راز غیر-حساس از طریق هدر Authorization به یک میزبان «شخص اول» است.

آزمایش و پیاده‌سازی

اثربخشی این ابزار از طریق دو مجموعه داده (Fixture) مصنوعی اثبات شده است. اولی یک سناریوی «پاک» (Clean) است که با دو واسطه شخص ثالث ارتباط برقرار می‌کند اما فقط ارجاعات امن (Handle References) می‌فرستد که منجر به خروجی بدون خطا (Exit 0) می‌شود.

در سناریوی «نشت‌کننده» (Leaky)، ابزار توانست ۳ درخواست مشکوک را شناسایی کند که ۲ مورد از آن‌ها مربوط به واسطه‌های شخص ثالث بود. یافته‌ها شامل موارد زیر بود:

• ۵ فیلد متمایز که از مرز امن عبور کرده بودند.
• ۶ مورد تطابق کلی با قواعد (برای مثال، یک توکن GitHub PAT در هدر Authorization باعث فعال شدن هر دو قاعده bearer_token و github_pat شد).
• ۲ راز بسیار حساس: یک کلید خصوصی اتریوم و یک عبارت بازیابی BIP-39 که هر دو در آرگومان‌های ابزارهای MCP در مسیر یک پروکسی قرار داشتند.

نکته مهم این است که کاوشگر به‌درستی بین یک راز واقعی و یک دستگیره (Handle) تفاوت قائل می‌شود. همچنین بافتار (Context) را می‌فهمد؛ مثلاً توکن sk-... ارسال شده به api.openai.com را علامت نمی‌زند چون این یک میزبان شخص اول است و توکن در حال انجام وظیفه اصلی خود است.

پیاده‌سازی گیت حذف (Redaction Gate)
این ابزار دارای یک حالت --redact است که نقشه خروجی را به نسخه‌ای ماسک‌شده تبدیل می‌کند. در این حالت، هدرهای Authorization شخص اول دست‌نخورده می‌مانند اما هر فیلدی که باعث نشت شود، ماسک می‌شود.

با بازگرداندن خروجی ماسک‌شده به خودِ کاوشگر (python3 boundary_leak_probe.py --redact fixtures/egress_leaky.json | python3 boundary_leak_probe.py /dev/stdin)، سیستم به وضعیت «Exit 0» می‌رسد. این ثابت می‌کند که در حالی که گام‌های واسطه‌ای (Hops) همچنان وجود دارند، اما هیچ رازی دیگر به آن‌ها ارسال نمی‌شود و توکن‌های ماسک‌شده با الگوی SAFE_REF مطابقت دارند.

محدودیت‌ها و هشدارها

کاربران باید توجه داشته باشند که این ابزار یک تحلیلگر استاتیک مبتنی بر Regex است، نه یک بازرس زنده (Live Interceptor) یا اثباتی برای پاکسازی مطلق. این ابزار «شکل‌ها» را شناسایی می‌کند، نه لزوماً رازهای تایید شده:

• مثبت‌های کاذب (False Positives): یک رشته هگز ممکن است هش تراکنش باشد نه کلید خصوصی. قاعده Mnemonic هر دنباله‌ای از ۱۲ تا ۲۴ کلمه کوتاه انگلیسی را شناسایی می‌کند؛ بنابراین یک جمله عادی در پرامپت می‌تواند باعث فعال شدن هشدار CRITICAL شود.
• منفی‌های کاذب (False Negatives): هر فرمت رازی که به‌طور صریح در Regexها تعریف نشده باشد، به‌سادگی و بدون هشدار عبور می‌کند.
• مدل اعتماد: اعتماد در سطح میزبان است. هر راز غیر-حساسی که در هر جای درخواست شخص اول (حتی در بدنه) قرار گیرد، نادیده گرفته می‌شود. همچنین، لیست first_party_hosts نیاز به تطبیق دقیق رشته‌ای دارد؛ یک غلط املایی در نام میزبان، آن را به‌طور خودکار به «شخص ثالث» تبدیل می‌کند.
• زمان اجرا (Runtime): این ابزار در مسیر درخواست یا شنود TLS قرار ندارد. برای تبدیل آن به یک گیت واقعی، کاربر باید کد خروجی (Exit Code) را به منطق ارسال بایت‌ها متصل کند.

این رویکرد جایگزینی برای mTLS یا کنترل‌های درگاه داخلی نیست؛ بلکه یک چک‌لیست قطعی برای کسانی است که برای راحتی از واسطه‌های شخص ثالث استفاده می‌کنند بدون اینکه مدل تهدید رسمی داشته باشند. علاوه بر این، ارجاعات امن تنها زمانی ایمن هستند که جایگزینی در لبه‌ای (Edge) اتفاق بیفتد که شما کنترل می‌کنید. اگر روتر جایگزینی را انجام دهد، متن ساده فقط یک گام دورتر منتقل شده است.

این ابزار محور جدیدی از اندازه‌گیری را معرفی می‌کند که پیش‌تر در تحلیل‌های ما درباره رازها در مصنوعات ساخت (Build Artifacts)، شعاع تخریب کلیدها، مبانی امنیتی مانیفست‌های MCP—که در آن مشاهده شد ۲۰٪ از تنظیمات این عامل‌ها دارای حفره‌های بحرانی هستند—و آلودگی‌های محیط ارزیابی (Eval Harness) بررسی شده بود. در حالی که آن ابزارها بر روی فایل‌ها یا دامنه‌ها متمرکز بودند، این کاوشگر بر روی ردپای خروجی و اعتماد به مقصد تمرکز دارد.

گام بعدی شما

• تمام مسیرهای خروجی داده‌های عامل‌های خود را با boundary_leak_probe.py بررسی کنید تا نقاط نشت احتمالی را بیابید.
• استراتژی «جایگزینی در لبه» (Substitution at the Edge) را جایگزین ارسال مستقیم کلیدها کنید. برای جلوگیری از خطاهای ابزاری و نشت‌های احتمالی، می‌توان استفاده از ماشین‌های حالت (FSM) را به جای پرامپت‌های ساده در مدیریت توالی اقدامات عامل‌ها بررسی کرد.
• از ارسال Seed Phrase یا کلیدهای خصوصی در بدنه درخواست‌های API به‌طور کامل خودداری کنید.

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