دادن کنترل یک کیف پول ارز دیجیتال به یک عامل هوشمند بدون حفاظهای سختگیرانه، دقیقاً مثل این است که کارت اعتباری خود را به دست یک کودک نوپا بدهید. عامل شما شاید بهترین نیت را داشته باشد، اما بدون محدودیتهای قطعی، یک تصمیم اشتباه میتواند تمام داراییهای شما را در چند ثانیه به باد دهد. WAIaaS برای حل این بحران، یک معماری امنیتی را طراحی کرده است که از وقوع حوادث فاجعهبار در عملیاتهای خودکار روی زنجیره (on-chain) جلوگیری میکند. طبق مستندات فنی منتشر شده در ۲۹ سپتامبر ۲۰۲۶، این سیستم بر این اصل استوار است که استقلال عامل نباید به معنای نبود نظارت باشد.
عدم تقارن ریسک در زنجیره (On-Chain)
وعده عاملهای هوشمند مستقل برای مدیریت عملیات روی زنجیره کاملاً واقعی است. عاملهایی که میتوانند موقعیتهای DeFi را بازتنظیم کنند، هزینه فراخوانیهای API را بپردازند، معاملات را اجرا کنند و داراییهای چندزنجیرهای را بدون دخالت مداوم انسان مدیریت کنند، میتوانند هزینههای عملیاتی را کاهش داده و دستههای جدیدی از محصولات را ایجاد کنند. با این حال، «مستقل» بودن با «بدون نظارت» بودن تفاوت دارد.
عاملی که بتواند تراکنشهای دلخواه را به آدرسهای نامشخص ارسال کند، اجازه خرج کردن نامحدود توکنها را صادر کند یا بدون هیچ محدودیتی موقعیتهای اهرمی (Leveraged Perpetual) بگیرد، یک محصول نیست، بلکه یک ریسک (Liability) است. چالش اصلی این است که تراکنشهای کریپتو بازگشتناپذیر هستند. در یک سیستم مالی سنتی، اگر قانونی نقض شود، تراکنش لغو و علامتگذاری میشود. اما یک انتقال روی زنجیره که نباید اتفاق میافتاد، دائمی است.
این عدم تقارن ایجاب میکند که اجرای امنیت در سمت «چپ» یا پیش از اجرا اتفاق بیفتد؛ یعنی مسدود کردن تراکنش قبل از اینکه اصلاً به بلاکچین برسد. برای توسعهدهندگانی که عاملهای DeFi میسازند، هدف انتقال از استقلال «بدون نظارت» به استقلال «محدودشده» (Bounded Autonomy) است. این رویکرد در واقع پاسخی به چالشهای مدیریت ریسک در عاملهای AI است که در آن تأییدیههای ایستا معمولاً در برابر نیازهای پویا شکست میخورند. WAIaaS این هدف را از طریق سه لایه امنیتی متمایز، یک موتور سیاستگذاری با ۲۱ نوع سیاست در ۴ سطح امنیتی و یک مدل اجرایی «رد پیشفرض» محقق میکند.
لایه اول: جداسازی احراز هویت
برای جلوگیری از افزایش سطح دسترسی (Privilege Escalation)، WAIaaS سه نقش احراز هویت متمایز را پیادهسازی کرده است. این جداسازی تضمین میکند که یک عامل هوشمند که فقط توکن جلسه (Session Token) دارد، نمیتواند کیف پولهای جدید بسازد، سیاستها را تغییر دهد یا تراکنشهای خودش را تایید کند.
- masterAuth: این نقش مربوط به مدیر سیستم است. از آن برای ساخت کیف پول، مدیریت جلسات و تنظیم سیاستها استفاده میشود. برای امنیت بالا، از هشینگ رمز عبور Argon2id استفاده میکند. عامل هوشمند هرگز به این اعتبار دسترسی ندارد. مثال هدر:
X-Master-Password: my-secret-password. - sessionAuth: این همان چیزی است که عامل هوشمند در زمان اجرا برای تراکنشها، پرسوجوی موجودی و اقدامات DeFi استفاده میکند. این لایه از توکنهای JWT HS256 بهره میبرد. برای جلوگیری از جلسات خارج از کنترل، این توکنها دارای تنظیمات TTL (زمان عمر)،
maxRenewals(حداکثر تمدید) وabsoluteLifetime(عمر مطلق) هستند. مثال هدر:Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9.... - ownerAuth: این نقش متعلق به مالک انسانی دارایی است. از آن برای تایید تراکنشها و بازیابی از طریق کلید توقف (Kill-switch) استفاده میشود. این لایه از امضاهای SIWS/SIWE (با الگوریتمهای ed25519 یا secp256k1) استفاده میکند. مثال هدرها:
X-Owner-Signature: <signature>وX-Owner-Message: <signed-message>.
لایه دوم: موتور سیاستها و رد پیشفرض
قلب تپنده این سیستم، موتور سیاستهایی است که ۲۱ نوع قانون متمایز را اجرا میکند. هر تراکنش باید از یک خط لوله سختگیرانه هفتمرحلهای عبور کند: اعتبارسنجی $ \rightarrow $ احراز هویت $ \rightarrow $ سیاست $ \rightarrow $ انتظار $ \rightarrow $ اجرا $ \rightarrow $ تایید. مرحله «سیاست» جایی است که اجرای واقعی قوانین صورت میگیرد.
اجرای رد پیشفرض (Default-Deny)
رد پیشفرض یک تنظیم ساده نیست، بلکه حالت پیشفرض موتور است. وقتی ALLOWED_TOKENS یا CONTRACT_WHITELIST پیکربندی نشده باشند، آن نوع تراکنشها بهطور خودکار مسدود میشوند. عامل شما نمیتواند با توکنها یا قراردادهایی که صراحتاً اجازه ندادهاید، تعامل کند. برای فعال کردن این قابلیت نیازی به انتخاب (Opt-in) نیست؛ بلکه شما باید با پیکربندی موارد مجاز، صراحتاً از این حالت خارج شوید (Opt-out). این مدل سختگیرانه برای پر کردن شکافهای حاکمیتی در عاملهای خودمختار طراحی شده است تا کنترل دقیقتری بر رفتار سیستم ایجاد شود.
چهار سطح امنیتی تراکنشها
هر سیاستی که مبالغ تراکنش را ارزیابی میکند، اقدام را به یکی از چهار سطح امنیتی زیر اختصاص میدهد:
- INSTANT: اجرا فوری، بدون هیچ اعلانی.
- NOTIFY: اجرا فوری، اما ارسال یک اعلان برای مالک.
- DELAY: تراکنش برای مدت
delay_secondsدر صف قرار میگیرد و سپس اجرا میشود. این کار یک پنجره زمانی قابل لغو برای مالک ایجاد میکند. - APPROVAL: نیاز به تایید صریح انسانی از طریق WalletConnect، تلگرام یا اعلانهای Push.
به عنوان مثال، یک سیاست SPENDING_LIMIT را میتوان از طریق درخواست POST به /v1/policies با قوانینی مانند instant_max_usd: 100 (تا ۱۰۰ دلار فوری)، notify_max_usd: 500 (تا ۵۰۰ دلار با اعلان)، delay_max_usd: 2000 (تا ۲۰۰۰ دلار با تأخیر)، delay_seconds: 900 (تأخیر ۱۵ دقیقهای) و daily_limit_usd: 5000 (سقف روزانه ۵۰۰۰ دلار) تنظیم کرد. در این ساختار، تراکنشهای زیر ۱۰۰ دلار فوری هستند، مبالغ ۱۰۰ تا ۵۰۰ دلار به مالک خبر میدهند، ۵۰۰ تا ۲۰۰۰ دلار به مدت ۱۵ دقیقه در صف میمانند و هر مبلغ بالای ۲۰۰۰ دلار نیاز به تایید دستی دارد. سقف روزانه نیز مجموع هزینهها را فارغ از اندازه هر تراکنش محدود میکند.
۲۱ سیاست کنترلی برای مدیریت ریسک
WAIaaS مجموعهای جامع از ۲۱ سیاست را برای مدیریت ریسک ارائه میدهد:
- هزینه و دسترسی:
SPENDING_LIMIT(سطوح مبتنی بر مبلغ)،WHITELIST(آدرسهای گیرنده مجاز)،TIME_RESTRICTION(ساعات مجاز)،RATE_LIMIT(حداکثر تراکنش در هر بازه زمانی). - کنترل توکن و قرارداد:
ALLOWED_TOKENS(لیست سفید توکنها)،CONTRACT_WHITELIST(لیست سفید فراخوانی قراردادها)،METHOD_WHITELIST(انتخابگرهای تابع مجاز)،APPROVED_SPENDERS(لیست سفید تاییدکنندگان توکن). - حفاظهای تاییدیه:
APPROVE_AMOUNT_LIMIT(مسدود کردن تاییدیه نامحدود)،APPROVE_TIER_OVERRIDE(اجبار به سطح خاص برای تراکنشهای APPROVE). - شبکه و دامنه:
ALLOWED_NETWORKS(محدودیت شبکه)،X402_ALLOWED_DOMAINS(لیست سفید دامنههای پرداخت x402)،ERC8128_ALLOWED_DOMAINS(دامنههای امضای HTTP استاندارد ERC-8128). - موردهای خاص DeFi:
LENDING_LTV_LIMIT(حداکثر نسبت وام به ارزش)،LENDING_ASSET_WHITELIST(داراییهای مجاز برای وام)،PERP_MAX_LEVERAGE(حداکثر اهرم در معاملات آتی)،PERP_MAX_POSITION_USD(حداکثر اندازه موقعیت به دلار)،PERP_ALLOWED_MARKETS(بازارهای آتی مجاز)،VENUE_WHITELIST(پلتفرمهای معاملاتی مجاز)،ACTION_CATEGORY_LIMIT(محدودیت دستهبندی اقدامات DeFi). - هویت:
REPUTATION_THRESHOLD(حد نصاب اعتبار روی زنجیره بر اساس ERC-8004).
حفاظهای تخصصی DeFi
فراتر از محدودیتهای ساده هزینه، WAIaaS سیاستهای خاصی را برای مقابله با بردارهای حمله رایج در DeFi ارائه میدهد. سیاستهای APPROVE_AMOUNT_LIMIT و APPROVED_SPENDERS از رویه خطرناک صدور approve(spender, type(uint256).max) به آدرسهای نامشخص جلوگیری میکنند. این کار مانع از تخلیه کیف پول در صورتی میشود که یک پروتکل متصل شده مورد نفوذ قرار گیرد.
برای معاملات پرریسک، سیستم شامل PERP_MAX_LEVERAGE و PERP_MAX_POSITION_USD است. اینها یک سقف سخت برای ضرایب اهرم و اندازه مطلق موقعیتها در بازارهای آتی دائمی (مانند Hyperliquid که یکی از ۱۵ پروتکل DeFi یکپارچه شده است) ایجاد میکنند.
ریسکهای وامدهی از طریق LENDING_LTV_LIMIT مدیریت میشوند. اگر یک عامل موقعیتهایی را در Aave v3 یا Kamino مدیریت کند، این سیاست مانع از استقراض با نسبت وام به ارزشی میشود که در نوسانات عادی بازار منجر به لیکوئید شدن شود.
کنترلهای عملیاتی و شبیهسازی
کنترلهای ساده اما موثر شامل TIME_RESTRICTION و RATE_LIMIT هستند. با محدود کردن تراکنشها به ساعات کاری یا سقف تعداد معاملات در ساعت، توسعهدهندگان میتوانند «شعاع تخریب» (Blast Radius) یک عامل دچار نقص را بهطور قابل توجهی کاهش دهند. عاملی که به ۱۰ تراکنش در ساعت در ساعات کاری UTC محدود شده است، حتی در صورت نفوذ، آسیب محدودی میزند.
برای عاملهایی که هزینه فراخوانی API را از طریق پروتکل پرداخت HTTP x402 میپردازند، سیاست X402_ALLOWED_DOMAINS تضمین میکند که پرداختها فقط به نقاط انتهایی (Endpoints) تایید شده ارسال شوند و مانع از آن میشود که عامل به پرداخت برای دامنههای دلخواه ترغیب شود.
برای جلوگیری از ضررهای ناشی از آزمون و خطا، WAIaaS یک API شبیهسازی (dry-run) ارائه میدهد. با ارسال درخواست به /v1/transactions/send با مقدار dryRun: true ، یک عامل میتواند تراکنش را در کل خط لوله — از جمله ارزیابی سیاستها — شبیهسازی کند تا ببیند آیا قبل از تخصیص واقعی وجوه روی زنجیره، تایید میشود یا خیر.
لایه سوم: کانالهای تایید انسانی
وقتی تراکنشی به سطح APPROVAL میرسد، شکست نمیخورد، بلکه منتظر میماند. مالک دارایی از طریق push-relay، تلگرام یا WalletConnect اعلان دریافت میکند. این مکانیسم دقیقاً همان جایی است که بحث تایید انسانی در برابر اعتماد مطلق به مدل در جریانهای کاری فینتک اهمیت مییابد تا از خطاهای مدلهای زبانی در تراکنشهای حساس جلوگیری شود.
تایید تراکنش از طریق رمز عبور انجام نمیشود، بلکه از طریق امضاهای رمزنگاریشده ownerAuth صورت میگیرد. درخواست به /v1/transactions/<tx-id>/approve نیازمند X-Owner-Signature و X-Owner-Message است. یکپارچگی با WalletConnect بهویژه مفید است، زیرا به مالکان اجازه میدهد تراکنشها را با استفاده از رابطهای استاندارد کیف پول Web3، بدون نیاز به نرمافزارهای تخصصی، تایید کنند.
گردش کار پیادهسازی
راهاندازی یک عامل با اولویت امنیت شامل یک فرآیند پنج مرحلهای است:
۱. نصب و مقداردهی اولیه: اجرای npm install -g @waiaas/cli و سپس دستورات waiaas init و waiaas start.
۲. ساخت کیف پول: استفاده از درخواست POST به /v1/wallets با تعیین نام، زنجیره (مثلاً Solana) و محیط (مثلاً mainnet).
۳. پیکربندی سیاستهای پایه: تنظیم محدودیتهای هزینه، توکنهای مجاز و لیست سفید قراردادها. به یاد داشته باشید که بدون اینها، عامل تحت مدل «رد پیشفرض» عمل میکند.
۴. ایجاد جلسه: استفاده از /v1/sessions برای تولید توکن جلسه برای آن کیف پول خاص.
۵. استقرار توکن: دادن توکن جلسه (و فقط توکن جلسه) به عامل هوشمند.
وقتی نقض سیاستی رخ میدهد، سیستم یک پاسخ JSON ساختاریافته با کد POLICY_DENIED ، یک پیام خاص (مثلاً "Transaction denied by SPENDING_LIMIT policy") و فیلد domain: "POLICY" برمیگرداند. این به عامل هوشمند اجازه میدهد تا بهصورت برنامهنویسی شده با این رد پاسخ دهد — مثلاً با هشدار دادن به انسان یا تغییر استراتژی خود — بهجای اینکه آن را به عنوان یک خطای سیستمی کلی در نظر بگیرد.
خلاصه معماری
این معماری سه لایه تضمین میکند که ریسک صریح، محدود و قابل حسابرسی باشد:
- جداسازی احراز هویت مانع از آن میشود که عاملها محدودیتهای خود را تغییر دهند.
- موتور سیاستها ۲۱ نوع قانون را با رویکرد رد پیشفرض و ۴ سطح ریسک اجرا میکند.
- کانالهای تایید انسانی یک مسیر احراز هویت رمزنگاریشده برای مدیریت جابجاییهای با ارزش بالا فراهم میکنند.
توسعهدهندگان اکنون میتوانند این حفاظها را با استفاده از SDKهای TypeScript و Python شرکت WAIaaS در جریان کاری خود ادغام کنند یا از ۴۵ ابزار MCP موجود برای یکپارچگی با چارچوبهای عامل (Agent Frameworks) استفاده کنند. سورس کامل تمام ۲۱ نوع سیاست در گیتهاب موجود است و مرجع تعاملی API در مسیر /reference امکان بررسی زنده درخواستها را فراهم میکند.
گام بعدی شما
- اگر در حال توسعه عاملهای DeFi هستید، ابتدا مدل «رد پیشفرض» را جایگزین لیستهای سیاه کنید.
- برای تراکنشهای بالای ۱۰۰۰ دلار، حتماً سطح DELAY را فعال کنید تا پنجره زمانی برای واکنش انسانی داشته باشید.
- از SDKهای تایپاسکریپت و پایتون WAIaaS برای یکپارچهسازی سریع این حفاظها استفاده کنید.
اما مدیریت این کلیدها در مقیاس سازمانی چالشهای جدیدی ایجاد میکند — به تحلیل ما درباره مدیریت کلیدهای چندامضایی (Multi-sig) برای AI مراجعه کنید.
گفتگو