مه آهسته: آیا واقعاً سپردن پولتان به یک عامل هوش مصنوعی مانند «لابستر» امن است؟

عنوان اصلی: گزارش امنیتی هوش مصنوعی «SlowMist × Bitget»: آیا واقعاً سپردن پولتان به «لابستر» و دیگر عوامل هوش مصنوعی امن است؟

منبع اصلی: فناوری SlowMist

۱. پیشینه

با توسعه سریع فناوری مدل‌های بزرگ، عامل‌های هوش مصنوعی از دستیاران هوشمند ساده به سیستم‌های خودکاری که قادر به اجرای وظایف هستند، در حال تکامل هستند.

در اکوسیستم web3-278">وب ۳ ، این تغییر به طور ویژه‌ای برجسته است. کاربران بیشتر و بیشتری شروع به آزمایش مشارکت نمایندگان هوش مصنوعی در تحلیل بازار، تدوین استراتژی و معاملات خودکار کرده‌اند و مفهوم «دستیار معاملات خودکار ۲۴ ساعته» را به واقعیت تبدیل می‌کنند. با راه‌اندازی چندین مهارت هوش مصنوعی توسط بایننس و OKX، معرفی مرکز عامل ایستگاه منابع مهارت‌ها توسط بیت‌گت و افزونه‌ی بدون نیاز به نصب GetClaw توسط لابستر، عامل‌ها می‌توانند مستقیماً به APIهای پلتفرم معاملاتی، داده‌های درون زنجیره‌ای و ابزارهای تحلیل بازار دسترسی داشته باشند و از این طریق تا حدودی کار تصمیم‌گیری و اجرای معاملات را که در ابتدا نیاز به مداخله‌ی انسانی داشت، بر عهده بگیرند.

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

با این حال، گسترش قابلیت‌ها به معنای گسترش سطح حمله نیز هست.

در سناریوهای معاملاتی سنتی، خطرات امنیتی معمولاً حول مسائلی مانند اعتبارنامه حساب، نشت کلید API یا حملات فیشینگ می‌چرخند. در معماری عامل هوش مصنوعی، خطرات جدیدی در حال ظهور هستند. برای مثال، تزریق سریع می‌تواند بر منطق تصمیم‌گیری یک عامل تأثیر بگذارد، افزونه‌ها یا مهارت‌های مخرب می‌توانند به عنوان نقاط ورود جدید برای حمله به زنجیره تأمین عمل کنند و پیکربندی‌های نامناسب زمان اجرا می‌توانند منجر به سوءاستفاده از داده‌های حساس یا مجوزهای API شوند. وقتی این مسائل با سیستم‌های معاملاتی خودکار ترکیب شوند، تأثیر بالقوه ممکن است فقط به افشای اطلاعات محدود نشود، بلکه می‌تواند مستقیماً منجر به از دست رفتن دارایی‌های واقعی نیز شود.

همزمان، همزمان با اینکه کاربران بیشتری شروع به ادغام عوامل هوش مصنوعی در حساب‌های معاملاتی خود می‌کنند، مهاجمان نیز به سرعت خود را با این تغییر وفق می‌دهند. انواع جدید کلاهبرداری که کاربران Agent را هدف قرار می‌دهند، مسمومیت با افزونه‌های مخرب و سوءاستفاده از کلید API به تدریج در حال تبدیل شدن به تهدیدات امنیتی جدید هستند. در سناریوی وب ۳، عملیات دارایی‌ها اغلب شامل ارزش بالا و برگشت‌ناپذیری است. هنگامی که سیستم‌های خودکار مورد سوءاستفاده یا گمراه‌سازی قرار گیرند، تأثیر ریسک ممکن است بیشتر شود.

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

دوم. تهدیدات امنیتی واقعی عوامل هوش مصنوعی | SlowMist

ظهور عامل‌های هوش مصنوعی، سیستم‌های نرم‌افزاری را از «عملیات مبتنی بر انسان» به «تصمیم‌گیری و اجرای مدل‌محور» تغییر داده است. این تغییر معماری، قابلیت‌های اتوماسیون را به طور قابل توجهی افزایش داده است، اما سطح حمله را نیز گسترش داده است.

از دیدگاه ساختار فنی فعلی، یک سیستم عامل هوش مصنوعی معمولی معمولاً شامل چندین مؤلفه مانند لایه تعامل کاربر، لایه منطق برنامه، لایه مدل، لایه فراخوانی ابزار (ابزارها/مهارت‌ها)، سیستم حافظه و محیط اجرای زیربنایی است. مهاجمان معمولاً یک ماژول واحد را هدف قرار نمی‌دهند، بلکه تلاش می‌کنند تا به تدریج از طریق مسیرهای چند لایه، کنترل رفتاری عامل را تحت تأثیر قرار دهند.

۱. دستکاری ورودی و حملات تزریق سریع

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

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

مشخصه این الگوی حمله این است که اغلب به آسیب‌پذیری‌های سنتی متکی نیست، بلکه از مکانیسم اعتماد مدل در اطلاعات زمینه‌ای برای تأثیرگذاری بر منطق رفتاری آن سوءاستفاده می‌کند.

۲. مهارت‌ها / افزونه مسمومیت زنجیره تامین اکوسیستم

در اکوسیستم فعلی عامل هوش مصنوعی، افزونه‌ها و سیستم‌های مهارت (مهارت‌ها / MCP / ابزارها) راهی مهم برای گسترش قابلیت‌های عامل هستند. با این حال، این نوع اکوسیستم افزونه نیز در حال تبدیل شدن به یک مسیر حمله جدید به زنجیره تأمین است.

SlowMist در نظارت خود بر مرکز رسمی افزونه‌های OpenClaw، یعنی ClawHub، دریافت که با افزایش تعداد توسعه‌دهندگان، برخی از مهارت‌های مخرب شروع به نفوذ کرده‌اند . پس از ادغام و تجزیه و تحلیل IOC های بیش از ۴۰۰ Skill مخرب توسط SlowMist، مشخص شد که تعداد زیادی از نمونه‌ها به چند دامنه ثابت یا چندین مسیر تصادفی تحت یک IP یکسان اشاره دارند که نشان‌دهنده‌ی یک ویژگی واضح استفاده مجدد از منابع است که بیشتر شبیه رفتار حمله‌ی دسته‌ای سازمان‌یافته و در مقیاس بزرگ است.

در سیستم مهارت OpenClaw، فایل اصلی معمولاً SKILL.md است.

برخلاف کد سنتی، این فایل‌های Markdown اغلب نقش «دستورالعمل‌های نصب» و «نقطه ورود اولیه» را ایفا می‌کنند، اما در اکوسیستم Agent، آنها اغلب مستقیماً توسط کاربران کپی و اجرا می‌شوند و بنابراین یک زنجیره اجرای کامل را تشکیل می‌دهند. مهاجمان فقط باید دستورات مخرب را به عنوان مراحل نصب وابستگی پنهان کنند، مانند استفاده از curl | bash یا رمزگذاری Base64 برای پنهان کردن دستور واقعی، تا کاربران را به اجرای اسکریپت‌های مخرب ترغیب کنند.

در نمونه‌های واقعی، برخی از مهارت‌ها یک استراتژی معمول «بارگذاری دو مرحله‌ای» را اتخاذ می‌کنند:

· اسکریپت مرحله اول فقط مسئول دانلود و اجرا است

· بار مفید مرحله دوم، که در نتیجه میزان موفقیت تشخیص استاتیک را کاهش می‌دهد.

به عنوان مثال، یک مهارت «X (Twitter) Trends» با تعداد دانلود بالا را در نظر بگیرید، SKILL.md آن بخشی از دستور کدگذاری شده Base64 را پنهان می‌کند.

پس از رمزگشایی، مشخص می‌شود که اساساً در حال دانلود و اجرای یک اسکریپت از راه دور است:

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

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

۳. ریسک لایه تصمیم‌گیری عامل و هماهنگ‌سازی وظایف

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

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

در یک مورد حسابرسی امنیتی قبل از SlowMist، پیام‌های مخرب به MCP تزریق شدند تا نماینده را وادار کنند تا یک افزونه کیف پول را برای انجام نقل و انتقالات درون زنجیره‌ای فراخوانی کند.

ویژگی چنین حملاتی این است که خطا از کد تولید شده توسط مدل ناشی نمی‌شود، بلکه از دستکاری منطق تنظیم وظایف ناشی می‌شود.

۴. نشت اطلاعات حساس و حریم خصوصی در محیط‌های IDE/CLI

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

این محیط‌ها معمولاً حاوی حجم زیادی از اطلاعات حساس مانند فایل‌های پیکربندی .env، توکن‌های API، اعتبارنامه‌های سرویس ابری، فایل‌های کلید خصوصی و کلیدهای دسترسی مختلف هستند. اگر یک عامل بتواند این دایرکتوری‌ها یا فایل‌های پروژه را در حین اجرای وظیفه بخواند، ممکن است ناخواسته اطلاعات حساس را در زمینه مدل وارد کند.

در برخی از فرآیندهای توسعه خودکار، Agentها ممکن است فایل‌های پیکربندی را در دایرکتوری پروژه در حین اشکال‌زدایی، تحلیل لاگ یا نصب وابستگی‌ها بخوانند. بدون سیاست‌های صریحِ حذف یا کنترل دسترسی، این اطلاعات ممکن است ثبت شوند، به یک API مدل از راه دور ارسال شوند یا حتی توسط افزونه‌های مخرب فاش شوند.

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

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

بنابراین، در سناریوی ادغام عامل هوش مصنوعی با IDE/CLI، ایجاد یک استراتژی واضح و حساس برای حذف دایرکتوری (مانند مکانیزمی شبیه به .agentignore یا .gitignore) و اجرای اقدامات جداسازی مجوز، پیش‌نیازهای کلیدی برای کاهش خطر نشت داده‌ها هستند.

۵. عدم قطعیت مدل و ریسک اتوماسیون

مدل هوش مصنوعی خود یک سیستم کاملاً قطعی نیست، خروجی آن سطح خاصی از عدم قطعیت احتمالی را نشان می‌دهد . به اصطلاح «توهم مدل»، که در آن مدل به دلیل فقدان اطلاعات، نتایج به ظاهر معقول اما در واقع نادرستی تولید می‌کند. در سناریوهای کاربردی سنتی، چنین خطاهایی معمولاً فقط بر کیفیت اطلاعات تأثیر می‌گذارند، اما در معماری عامل هوش مصنوعی، خروجی مدل ممکن است مستقیماً عملیات سیستم را آغاز کند.

برای مثال، در برخی موارد، مدل در طول استقرار پروژه پارامترهای صحیح را جستجو did-133">نکرده ، بلکه در عوض یک شناسه نادرست ایجاد کرده و فرآیند استقرار را ادامه داده است. اگر وضعیت مشابهی در تراکنش‌های درون زنجیره‌ای یا سناریوهای عملیات دارایی رخ دهد، تصمیمات اشتباه می‌تواند منجر به ضررهای مالی جبران‌ناپذیری شود.

۶. ریسک عملیاتی با ارزش بالا در محیط وب 3

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

در برخی از پروژه‌های اکتشافی، توسعه‌دهندگان شروع به بررسی مشارکت مستقیم نماینده در استراتژی‌های تراکنش‌های درون زنجیره‌ای، مانند آربیتراژ خودکار، مدیریت صندوق یا عملیات DeFi ، کرده‌اند.

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

بنابراین، در سناریوی وب ۳، اتصال یک عامل هوش مصنوعی به سیستم کنترل دارایی، طرحی با ریسک بالا است.

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

۷. ریسک‌های سیستمی ناشی از اجرای با مجوز بالا

بسیاری از عامل‌های هوش مصنوعی در پیاده‌سازی‌های واقعی، مجوزهای سیستمی بالایی دارند، مانند دسترسی به سیستم فایل محلی، اجرای دستورات shell یا حتی اجرا با امتیازات root. هنگامی که رفتار عامل دستکاری شود، تأثیر آن ممکن است بسیار فراتر از یک برنامه واحد باشد.

SlowMist اتصال OpenClaw را با نرم‌افزارهای پیام‌رسان فوری مانند تلگرام برای دستیابی به کنترل از راه دور آزمایش کرده است. اگر کانال کنترل توسط یک مهاجم تصاحب شود، می‌توان از عامل (Agent) برای اجرای دستورات دلخواه سیستم، خواندن داده‌های مرورگر، دسترسی به فایل‌های محلی یا حتی کنترل سایر برنامه‌ها استفاده کرد. با داشتن یک اکوسیستم افزونه و قابلیت‌های فراخوانی ابزار، این نوع Agent تا حدودی ویژگی‌های «کنترل از راه دور هوشمند» را به دست آورده است.

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

مهاجمان می‌توانند از طریق اعلان‌ها، رفتار یک عامل را دستکاری کنند، یا می‌توانند در مهارت‌ها یا وابستگی‌های مخرب در سطح زنجیره تأمین، درهای پشتی (backdoor) تعبیه کنند و تأثیر حمله را در یک محیط عملیاتی با مجوز بالا، بیشتر گسترش دهند.

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

سوم. شیوه‌های امنیتی تراکنش عامل هوش مصنوعی | بیت‌گت

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

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

بر این اساس، این زیربخش، همراه با تجربه عملی تیم امنیتی Bitget در پلتفرم معاملاتی، به طور سیستماتیک استراتژی‌های امنیتی را معرفی می‌کند که هنگام استفاده از عامل‌های هوش مصنوعی برای معاملات خودکار، از دیدگاه‌های مختلفی مانند امنیت حساب، مدیریت مجوز API، جداسازی وجوه و نظارت بر معاملات، نیاز به توجه ویژه دارند.

۱. خطرات امنیتی کلیدی در صحنه تجارت عامل هوش مصنوعی

۲. امنیت حساب

با ظهور عوامل هوش مصنوعی، مسیر حمله تغییر کرده است:

· نیازی به ورود به حساب کاربری خود ندارید - فقط باید کلید API خود را دریافت کنید

· نیازی به اطلاع شما نیست - عامل به طور خودکار 24 ساعته و 7 روز هفته اجرا می‌شود، عملیات غیرعادی می‌تواند برای روزها ادامه یابد

· نیازی به برداشت نیست - دارایی‌های خود را از طریق معاملات روی پلتفرم، که آن هم یک هدف حمله است، خالی کنید

ایجاد، اصلاح و حذف کلیدهای API همگی باید از طریق یک حساب کاربری وارد شده انجام شوند - تصاحب حساب به معنای تصاحب کنترل کلید است. سطح امنیتی حساب کاربری مستقیماً حد بالای امنیتی کلید API را تعیین می‌کند.

کاری که باید انجام دهید:

· Google Authenticator را به عنوان روش اصلی 2FA فعال کنید، نه پیامک (سیم کارت قابل سرقت است)

· فعال کردن رمز عبور برای ورود بدون رمز عبور: بر اساس استاندارد FIDO2/WebAuthn، رمزگذاری کلید عمومی-خصوصی جایگزین رمزهای عبور سنتی می‌شود و حملات فیشینگ را در سطح معماری بی‌اثر می‌کند.

· تنظیم کد ضد فیشینگ

· مرتباً مرکز مدیریت دستگاه را بررسی کنید، در صورت یافتن دستگاه‌های ناآشنا، فوراً از سیستم خارج شوید و رمز عبور را تغییر دهید

۳. امنیت API

در معماری معاملات خودکار عامل هوش مصنوعی، کلید API به عنوان «مدرک مجوز اجرا»ی عامل عمل می‌کند. خودِ عامل (Agent) مستقیماً کنترل حساب را در دست ندارد و تمام عملیاتی که می‌تواند انجام دهد به محدوده‌ی مجوز اعطا شده به کلید API بستگی دارد. بنابراین، مرزهای مجوز API مشخص می‌کند که یک عامل چه کاری می‌تواند انجام دهد و همچنین میزان افزایش خسارات در صورت وقوع یک حادثه امنیتی را تعیین می‌کند.

ماتریس پیکربندی مجوز - حداقل امتیاز، نه راحتی:

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

خطاهای رایج کاربران:

· قرار دادن مستقیم کلید API حساب اصلی در پیکربندی عامل - افشای مجوزهای کامل حساب اصلی

· کلیک روی «انتخاب همه» برای انواع کسب‌وکار برای راحتی، ناخواسته همه حوزه‌های عملیاتی را باز می‌کند

· عدم تعیین رمز عبور یا استفاده از همان رمز عبور به عنوان رمز عبور حساب کاربری

· کدگذاری سخت کلید API در کد، که ظرف ۳ دقیقه پس از ارسال به گیت‌هاب توسط یک خزنده، خراشیده می‌شود.

· مجاز کردن یک کلید واحد برای چندین عامل و ابزار، و افشای همه چیز در صورت به خطر افتادن هر یک از آنها

· عدم لغو فوری کلید پس از افشای آن، که به مهاجمان فرصت ادامه بهره‌برداری را می‌دهد.

مدیریت چرخه حیات کلیدی:

کلید API را هر ۹۰ روز یکبار تغییر دهید، کلیدهای قدیمی را فوراً حذف کنید. استفاده از Agent را متوقف کنید، کلید مربوطه را فوراً حذف کنید و هیچ سطح حمله‌ای باقی نگذارید. مرتباً سوابق فراخوانی API را بررسی کنید، بلافاصله پس از کشف IP های ناآشنا یا دوره‌های زمانی غیرعادی، آن را لغو کنید.

۴. امنیت صندوق

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

مکانیسم جداسازی حساب فرعی:

· ایجاد یک حساب کاربری فرعی اختصاصی برای نماینده، کاملاً جدا از حساب اصلی

· فقط وجوه واقعی مورد نیاز نماینده را از حساب اصلی تخصیص دهید، نه همه دارایی‌ها را

حتی اگر کلید حساب فرعی دزدیده شود، حداکثر مبلغی که مهاجم می‌تواند جابجا کند = وجوه موجود در حساب فرعی، حساب اصلی تحت تأثیر قرار نمی‌گیرد

· استراتژی‌های چند عاملی با چندین حساب فرعی به طور جداگانه و جدا از یکدیگر مدیریت می‌شوند

رمز عبور صندوق به عنوان خط دوم دفاع:

· رمز عبور صندوق کاملاً جدا از رمز ورود است؛ حتی اگر وارد حساب کاربری شده باشید، بدون رمز عبور صندوق نمی‌توان برداشت انجام داد.

· رمز عبور صندوق و رمز عبور ورود به سیستم به عنوان رمزهای عبور متفاوتی تنظیم شده‌اند

· فعال کردن لیست سفید برداشت: فقط آدرس‌های از پیش اضافه شده می‌توانند وجه را برداشت کنند و آدرس‌های جدید نیاز به یک دوره بررسی ۲۴ ساعته دارند.

· پس از تغییر رمز عبور صندوق، سیستم به طور خودکار برداشت‌ها را به مدت 24 ساعت مسدود می‌کند - این یک مکانیسم حفاظتی است.

۵. امنیت تراکنش

در سناریوی معاملات خودکار عامل هوش مصنوعی، مسائل امنیتی اغلب به صورت رفتار غیرعادی یک‌باره ظاهر نمی‌شوند، بلکه ممکن است به تدریج در طول عملکرد مداوم سیستم رخ دهند. بنابراین، علاوه بر امنیت حساب و کنترل مجوزهای API، لازم است سازوکارهای نظارت مداوم بر تراکنش‌ها و تشخیص ناهنجاری نیز ایجاد شود تا مشکلات به سرعت شناسایی و در مراحل اولیه مداخله شوند.

سیستم نظارتی ضروری:

شناسایی سیگنال غیرطبیعی - در صورت بروز شرایط زیر، فوراً توقف کرده و بررسی کنید:

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

· دریافت اعلان‌های معاملاتی برای جفت ارزهایی که هرگز تنظیم نشده‌اند

· تغییرات موجودی غیرقابل توضیح در حساب

· عامل مکرراً «مجوزهای اضافی مورد نیاز برای اجرا» را درخواست می‌کند - قبل از تصمیم‌گیری در مورد مجوز دادن، دلیل آن را بفهمید.

مدیریت منابع مهارت و ابزار:

· فقط مهارت‌های ارائه شده از طریق کانال‌های رسمی و حسابرسی شده را نصب کنید

· از نصب افزونه‌های شخص ثالث از منابع ناشناخته یا تأیید نشده خودداری کنید

· مرتباً لیست مهارت‌های نصب‌شده را بررسی کنید و آن‌هایی را که دیگر استفاده نمی‌شوند حذف کنید

· مراقب نسخه‌های «بهبود یافته» یا «بومی‌سازی شده» مهارت‌ها باشید - هرگونه نسخه غیررسمی، خطری را به همراه دارد.

۶. امنیت داده‌ها

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

چه باید بکنید؟

· اصل حداقل داده: فقط داده‌های لازم برای انجام معاملات را در اختیار نماینده قرار دهید

· مبهم‌سازی داده‌ها برای داده‌های حساس: اجازه ندهید که Agent اطلاعات کامل حساب، کلیدهای API و سایر داده‌های حساس را در لاگ‌ها یا اطلاعات اشکال‌زدایی نمایش دهد.

· از آپلود کردن اطلاعات کامل حساب کاربری در مدل‌های هوش مصنوعی عمومی (مانند APIهای عمومی LLM) خودداری کنید.

· در صورت امکان، داده‌های استراتژی را از داده‌های حساب جدا کنید

· غیرفعال کردن یا محدود کردن نماینده از صادرات داده‌های معاملاتی تاریخی

اشتباهات رایج کاربران

· آپلود کل تاریخچه معاملات به هوش مصنوعی برای "بهینه‌سازی استراتژی"

· چاپ کلید/راز API در لاگ‌های Agent

· ارسال اسکرین‌شات از سوابق معاملاتی (شامل شناسه سفارش، اطلاعات حساب) در انجمن‌های عمومی

· آپلود پشتیبان‌های پایگاه داده به ابزارهای هوش مصنوعی برای تجزیه و تحلیل

۷. طراحی امنیتی در سطح پلتفرم عامل هوش مصنوعی

علاوه بر پیکربندی‌های امنیتی سمت کاربر، امنیت اکوسیستم معاملاتی عامل هوش مصنوعی تا حد زیادی به طراحی امنیتی در سطح پلتفرم بستگی دارد.

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

در معماری پلتفرم واقعی، طرح‌های امنیتی رایج معمولاً شامل جنبه‌های زیر هستند.

۱. سیستم جداسازی حساب فرعی

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

۲. پیکربندی دقیق مجوزهای API

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

۳. افزونه‌ی ایجنت و مکانیزم بررسی مهارت

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

۴. قابلیت‌های امنیتی بنیادی پلتفرم

علاوه بر مکانیسم‌های امنیتی مرتبط با نماینده، سیستم امنیتی حساب خود پلتفرم معاملاتی نیز تأثیر قابل توجهی بر کاربران نماینده خواهد داشت. برای مثال:

۸. کلاهبرداری‌های جدید که کاربران عامل را هدف قرار می‌دهند

جعل هویت پشتیبانی مشتری

«کلید API شما در معرض خطر امنیتی است.» لطفاً فوراً پیکربندی مجدد کنید." سپس آنها یک لینک فیشینگ در اختیار شما قرار می‌دهند.

→ پشتیبانی رسمی به طور فعال شما را برای درخواست کلید API هدایت نمی‌کند.

بسته مهارت مسموم

انجمن یک «مهارت معاملاتی پیشرفته» را به اشتراک می‌گذارد که کلید شما را بی‌صدا در زمان اجرا ارسال می‌کند.

→ مهارت‌ها را فقط از کانال‌های رسمی و تأیید شده نصب کنید.

اعلان‌های ارتقاء کاذب

«نیاز به مجوز مجدد» که منجر به یک صفحه فیشینگ می‌شود.

→ کد ضد فیشینگ ایمیل را بررسی کنید.

حمله تزریق سریع

جاسازی دستورالعمل‌ها در داده‌های بازار، اخبار و حاشیه‌نویسی‌های شمعدان برای دستکاری عامل در انجام عملیات غیرمنتظره.

→ یک محدودیت برای موجودی حساب فرعی تعیین کنید تا حتی در صورت تزریق، ضرر مرز مشخصی داشته باشد.

اسکریپت مخرب در پوشش «ابزار بررسی امنیتی»

ادعا می‌کند که بررسی می‌کند آیا کلید شما لو رفته است یا خیر، اما در واقع کلید را می‌دزدد.

→ وضعیت فراخوانی API را از طریق گزارش یا عملکرد ثبت دسترسی ارائه شده توسط پلتفرم رسمی بررسی کنید.

۹. مسیر عیب‌یابی

در صورت مشاهده هرگونه ناهنجاری

→

فوراً کلیدهای API مشکوک را لغو یا غیرفعال کنید.

→

سفارش‌ها/پوزیشن‌های غیرعادی حساب را بررسی کنید، در صورت امکان فوراً برداشت کنید.

→

سوابق برداشت را بررسی کنید تا تأیید کنید که آیا وجهی منتقل شده است یا خیر

→

تغییر رمز ورود + رمز صندوق، خروج از تمام دستگاه‌های وارد شده

→

با پشتیبانی امنیتی پلتفرم تماس بگیرید، جزئیات دوره‌های غیرعادی و سوابق عملیات را ارائه دهید

→

بررسی مسیرهای نشت کلیدی (مخزن کد / فایل‌های پیکربندی / گزارش‌های مهارت)

اصل اساسی: در صورت هرگونه سوءظن، ابتدا کلید را باطل کنید، بعداً دلیل آن را بررسی کنید، دستور قابل لغو نیست.

چهارم. پیشنهادات و خلاصه

در این گزارش، SlowMist و Bitget موارد عملی را با تحقیقات امنیتی ترکیب می‌کنند تا مسائل امنیتی معمول عامل‌های هوش مصنوعی فعلی در سناریوی Web3، از جمله خطر تزریق سریع روی رفتار عامل، خطر زنجیره تأمین در اکوسیستم افزونه و مهارت، مسائل مربوط به سوءاستفاده از کلید API و مجوز حساب، و تهدیدات بالقوه مانند سوء استفاده از عملیات و گسترش مجوز ناشی از اتوماسیون را تجزیه و تحلیل کنند.

این مشکلات اغلب ناشی از یک آسیب‌پذیری واحد نیستند، بلکه نتیجه‌ی اثرات ترکیبی طراحی معماری عامل، استراتژی‌های کنترل مجوز و امنیت محیط عملیاتی هستند.

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

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

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

علاوه بر این، برای ورودی‌های خارجی که عامل به آنها متکی است، حملات تزریق سریع را از طریق طراحی سریع و مکانیزم‌های جداسازی ورودی معقول کاهش دهید و از گنجاندن مستقیم محتوای خارجی به عنوان دستورات سیستم در فرآیند استدلال مدل جلوگیری کنید. در طول مرحله استقرار و بهره‌برداری، مدیریت امنیت کلید API و حساب کاربری را تقویت کنید، مانند فعال کردن فقط مجوزهای ضروری، تنظیم لیست سفید IP، چرخش منظم کلیدها و اجتناب از ذخیره اطلاعات حساس به صورت متن ساده در مخازن کد، فایل‌های پیکربندی یا سیستم‌های ثبت وقایع؛

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

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

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

با تکیه بر این مبنا، L2 می‌تواند به طور مؤثر دامنه عملیات پرخطر را از طریق همگرایی مرزهای مجوز عامل، کنترل حداقلی مجوز برای فراخوانی ابزار و مکانیسم‌های تأیید انسان-ماشین برای رفتارهای بحرانی محدود کند.

همزمان، L3 آگاهی از تهدید را در سطح ورودی تعامل خارجی به صورت بلادرنگ معرفی می‌کند و پیش‌بررسی‌هایی را روی منابع خارجی مانند URLها، مخازن وابستگی و منابع افزونه انجام می‌دهد تا احتمال ورود محتوای مخرب یا مسمومیت زنجیره تأمین به زنجیره اجرا را کاهش دهد.

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

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

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

در مجموع، AI Agent سطح بالاتری از اتوماسیون و هوش را به اکوسیستم وب ۳ آورده است، اما چالش‌های امنیتی آن را نباید دست کم گرفت .

تنها با ایجاد سازوکارهای امنیتی صحیح در سطوح مختلف مانند طراحی سیستم، مدیریت مجوزها و نظارت بر عملیات، می‌توان خطرات بالقوه را به طور مؤثر کاهش داد و در عین حال نوآوری‌های تکنولوژیکی عامل هوش مصنوعی را ارتقا داد.

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

لینک مقاله اصلی