اگر از عامل هوش مصنوعی (AI agent) — نرم‌افزاری که به‌جای شما در وب‌سایت‌ها حرکت می‌کند، فرم‌ها را پر می‌کند و تراکنش‌ها را اجرا می‌کند، مثل یک دستیار دیجیتالی که کلید خانه‌تان را دارد — برای مدیریت حساب بانکی استفاده می‌کنید، از امروز آن عامل احتمالاً دیگر نمی‌تواند پول جابجا کند. بانک‌های بزرگ آمریکا شامل Morgan Stanley، JPMorgan Chase، Bank of America و Citigroup دسترسی این ابزارها را به حالت فقط‌خواندنی (read-only) محدود کرده‌اند یا به‌طور کامل مسدود کرده‌اند.
این محدودیت‌ها واکنش مستقیم بانک‌ها به کشفِ هفته‌های اخیر (آوریل ۲۰۲۶) است: عامل‌های خودمختار (autonomous agents) — که بسیاری از آن‌ها با رضایت خود مشتریان مجاز شده بودند — با استفاده از نام‌کاربری و رمزعبور مشروع به پورتال‌های بانکداری آنلاین وارد شده و اقداماتی از استخراج داده (data scraping) تا انتقال وجه احتمالی انجام داده‌اند. به گزارش The Information، یک مدیر ارشد امنیت در یکی از پنج بانک برتر آمریکا که نخواست نامش فاش شود گفته است: «ما می‌بینیم عامل‌ها به خطوط پشتیبانی تماس می‌گیرند، انتقال وجه (wire transfer) آغاز می‌کنند و تنظیمات حساب را تغییر می‌دهند — همه بدون رضایت صریح کاربر برای هر اقدام».
زمینه: چرا اکنون و چرا بانک‌ها؟
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت عامل‌های هوش مصنوعی اشاره کردیم، معماری عامل‌های امروزی با مدل‌های امنیتی سنتی بانک‌ها تضاد بنیادین دارد. عامل‌های مدرن معمولاً با شبیه‌سازی رفتار مرورگر انسان کار می‌کنند: آن‌ها اعتبارنامه (credential) را می‌پذیرند، به وب‌سایت بانک می‌روند و با DOM (نمونه‌سازی شیء سند) دقیقاً مثل یک شخص تعامل دارند. برای بک‌اند بانک، این جلسات (sessions) از ترافیک مشروع مشتری قابل‌تفکیک نیستند. در حالی که خود عامل‌ها ممکن است توسط استارتاپ‌هایی با ممیزی امنیتی (security auditing) کم توسعه یافته باشند، مجوزهای گسترده‌ای از کاربران دریافت کرده باشند که پیامدهایشان را درک نکرده‌اند، یا — بدترین حالت — توسط حملات تزریق پرامپت (prompt injection) که باعث انحراف عامل از دستورالعمل‌ها می‌شود، مخرب شده باشند.
سناریوی وحشت‌انگیز برای بانک‌ها هکرِ سنتی نیست که دفاع‌ها را بشکند، بلکه یک عامل مجاز است که به‌سبب توهم (hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — انتقال ۵۰ هزار دلاری را آغاز می‌کند چون دستور «پول را به پس‌انداز منتقل کن» را اشتباه تفسیر کرده است. این تفکیک — بین نفوذ مخرب و خودکارسازی حسن‌نیت که دچار خطا شده — دقیقاً همان چیزی است که افسران ریسک (risk officers) بانک‌ها را بیدار نگه می‌داشته است.
جزئیات: محدودیت‌ها و چالش‌های فنی
- Morgan Stanley: مسدودسازی کامل (blanket block) عامل‌های شخص ثالث.
- JPMorgan Chase، Bank of America، Citigroup: محدودیت به حالت فقط‌خواندنی (read-only mode) در انتظار چارچوب احراز هویت جدید.
- چالش شناسایی: بانک‌ها نمی‌توانند به‌طور قابل‌اعتمادی تأیید کنند که عاملِ فعال در ساعت ۲ بامداد سه‌شنبه، همان عاملی است که مشتری در دوشنبه تایید کرده، و نمی‌توانند مطمئن شوند رفتار عامل به‌سبب به‌روزرسانی مدل، محدودیت پنجره متنی (context window) — میزان متنی که مدل هم‌زمان «در ذهن» نگه می‌دارد، مثل میز کاری که جا برای چند ورق دارد نه کل کتابخانه — یا ورودی‌های خصمانه (adversarial inputs) تغییر نکرده است.
- فشار تنظیم‌گرانه: تحت Regulation E و Electronic Fund Transfer Act، بانک‌ها مسئولیت قابل‌توجهی برای انتقال‌های الکترونیکی غیرمجاز دارند. اگر عامل AI انتقالی آغاز کند که مشتری بعداً اعتراض کند، بانک ممکن است متضرر شود — حتی اگر مشتری به‌اختیار اعتبارنامه خود را با توسعه‌دهنده عامل به اشتراک گذاشته باشد. Consumer Financial Protection Bureau (CFPB) نیز نظارت بر «مجموعه‌آورهای داده» (data aggregators) و دسترسی شخص ثالث را تشدید کرده است.
تحلیل: دو مسیر راه‌حل — کوتاه‌مدت و بلندمدت
صنعت در حال همگرایی بر روی رویکرد دو مسیری است:
- اقدام فوری — محدودیت و تشخیص: محدود کردن عامل‌های شخص ثالث به دسترسی API فقط‌خواندنی در صورت وجود، پیاده‌سازی تشخیص ناهنجاری رفتاری (behavioral anomaly detection) برای نشانه‌گذاری الگوهای ناوبری غیرانسانی، و الزام احراز هویت تقویت‌شده (step-up authentication) برای هر عملیات نوشتن (write operation).
- راه‌حل بلندمدت — هویت عامل استاندارد: توسعه چارچوب‌های هویت عامل استاندارد (agent identity frameworks) — در اصل گواهی‌های دیجیتالی (digital certificates) که به بانک‌ها اجازه می‌دهد پیش از اعطای مجوز تراکنش، مبدأ عامل، مجوزها و ردپای ممیزی (audit trail) آن را تأیید کنند.
گزارش‌های تأییدنشده حاکی از آن است که چندین ابتکار در حال اجرا است. Financial Data Exchange (FDX)، کنسرسیومی که استاندارد API مشترک برای بانکداری باز (open banking) در آمریکا را توسعه داده، یک گروه کار در مورد «هویت و مجوز عامل» (agent identity and authorization) تشکیل داده است. هدف آن‌ها گسترش مشخصه FDX API برای شامل‌شدن حوزه‌های (scopes) مخصوص عامل، سوابق رضایت (consent records) و مکانیزم‌های انقضای لحظه‌ای (real-time revocation) است. در موازی، OpenID Foundation در حال بررسی گسترش OAuth 2.0 و OpenID Connect برای مجوز وکالت (delegated authorization) نرم‌افزارهای خودمختار است — نوعی «OAuth برای عامل‌ها» که به کاربران اجازه می‌دهد مجوزهای دقیق، محدود به زمان و برای نمونه‌های خاص عامل (نه اعتبارنامه ریشه) صادر کنند.
بازیگران تجاری نیز در میدان هستند. Okta، Ping Identity و Auth0 همگی در ماه‌های اخیر محصولات هویت عامل اعلام کرده‌اند، در حالی که استارتاپ‌هایی مانند Anon و Stytch ابزارهای توسعه‌دهنده برای «احراز هویت بدون سر» (headless authentication) می‌سازند که به عامل‌ها اجازه می‌دهد هویت خود را بدون چالش انسان-در-حلقه (human-in-the-loop) اثبات کنند. دیدگاه این است: عامل مالی شخصی کاربر یک اعتبارنامه قابل تأیید (verifiable credential) ارائه می‌دهد — امضا شده توسط پلتفرم عامل، گواهی‌دهنده به نسخه کد، گواهی‌های ایمنی و رضایت صریح کاربر — و دروازه API بانک آن اعتبارنامه را بر اساس سیاست ارزیابی می‌کند قبل از اجازه معامله یا انتقال.
اما استانداردسازی زمان می‌برد، و اکوسیستم عامل‌ها سریع‌تر از کمیته‌ها تکامل می‌یابد. در میانتا، بانک‌ها دفاع‌های هیورستیک (heuristic) استقرار داده‌اند: تحلیل حرکات موس، دینامیک ضربات کلید، الگوهای زمانی درخواست و اثر انگشت دستگاه (device fingerprinting) برای تفکیک جلسات انسانی از خودکار. برخی با چالش‌های «اثبات انسانیت» (proof of humanity) — CAPTCHA، بیومتریک رفتاری (behavioral biometrics) یا حتی تأیید ویدیویی کوتاه — در هنگام تلاش عامل برای اقدام پرخطر آزمایش می‌کنند. این اقدامات ناقص هستند؛ عامل‌های پیشرفته می‌توانند تأخیر و حرکات انسانی را شبیه‌سازی کنند، و مسدودسازی بیش‌ازحد کاربران مشروعی را که برای دسترسی‌پذیری (accessibility) یا کارایی بر خودکارسازی تکیه دارند، مضطرب می‌سازد.
این تنش مذاکره جامع‌تری جامعه در مورد نقش نرم‌افزار خودمختار در حوزه‌های پرخطر را منعکس می‌کند. در سلامت، عامل‌هایی که نوبت می‌دهند یا نسخه تجدید می‌کنند با سوالات مشابه هویت و مسئولیت روبرو هستند. در نرم‌افزار سازمانی، Salesforce و Microsoft چارچوب‌های عامل (Agentforce و Copilot Studio) را با فرض دسترسی عمیق به سیستم تعبیه می‌کنند. بخش مالی، با ترکیب تنظیمات سخت، دارایی‌های بالا و زیرساخت‌های قدیمی، تنها اولین بخش است که به دیوار برخورد کرده است.
برای مصرف‌کنندگان، محدودیت‌های فعلی به معنای توقف وعده زندگی مالی کاملاً خودمختار است — عاملی که صورتحساب‌ها را بپردازد، بازده را بهینه کند، کارمزدها را مذاکره کند و مالیات را بدون دخالت انسان ثبت کند. کاربرانی که عادت کرده بودند حساب‌های خود را از طریق Plaid، Yodlee یا اشتراک‌گذاری مستقیم اعتبارنامه به ابزارهای AI متصل کنند، اکنون با اتصالات قطع یا نازک‌شده روبرو هستند. برخی بانک‌ها جایگزین‌های شخص اول (first-party) ارائه می‌دهند: دستیار AI خود JPMorgan اکنون می‌تواند الگوهای خرج را تحلیل و تنظیمات بودجه پیشنهاد دهد، اما در باغ محصور (walled garden) بانک کار می‌کند، نتواند اقدامات خارجی اجرا کند یا با حساب‌های غیر-Chase هماهنگی نماید.
این تکه‌تکه شدن ریسک ایجاد سیستم دو لایه می‌کند: مشتری بانک‌های بزرگ با قابلیت‌های AI مالکیت‌شده، خودکارسازی امن اما محدود می‌یابند، در حالی که مشتری موسسات کوچک‌تر یا کاربران ابزارهای مستقل، یا با دسترسی مسدود یا با ناامنی اشتراک‌گذاری اعتبارنامه روبرو می‌شوند. پاسخ بلندمدت باید هم‌عملی (interoperable) باشد — یک استاندارد باز که به هر بانکی اجازه دهد هر عاملی را تأیید کند، و به هر کاربری اجازه دهد پشته مالی (financial stack) خود را از بهترین اجزا بسازد بدون تسلیم امنیت.
تا آن زمان، تقابل ادامه دارد. بانک‌ها مسدودسازی می‌کنند؛ توسعه‌دهندگان عامل راه‌حل‌های دور زدن می‌یابند؛ و مشتریان می‌پرسند چرا دستیار دیجیتال‌شان می‌تواند خرید اینترنتی و رزرو پرواز انجام دهد اما نمی‌تواند ۵۰۰ دلار از جاری به پس‌انداز منتقل کند. حل این معضل نیازمند نه تنها تکنولوژی بهتر، بلکه یک چارچوب حقوقی و مفهومی جدید برای «عامل وکالت» (delegated agency) است — که تعریف کند وقتی نرم‌افزار به‌نام شما عمل می‌کند چه کسی پاسخگو است، و مؤسسات چگونه می‌توانند کدی را که خود ننوشته‌اند، اعتماد کنند. وحشت فعلی بانک‌ها درد رشدِ آن چارچوب متولدشده است.
ناظران صنعت انتظار دارند اولین استانداردهای هویت عامل آماده تولید در ۱۲ تا ۱۸ ماه آینده ظاهر شوند، محرک آن مهلت‌های تنظیم‌گرانه و فشار رقابتی است. در میانتا، مسیر عملی‌گرایانه‌ترین برای کاربران، تکیه بر APIهای رسمی بانک و ابزارهای شخص اول است، هرچند محدود، به‌جای ریسک قفل شدن حساب یا شکاف مسئولیت با عامل‌های غیرمجاز. عصر «سریع حرکت کن و چیزها را بشکن» (move fast and break things) با صنعتی روبرو شده که در آن «سریع حرکت کن» به معنای «مجوز بانکداری خود را از دست بده» است. عامل‌ها دسترسی خود را خواهند یافت — اما تنها وقتی بتوانند ثابت کنند قوانین را می‌دانند.
گام بعدی شما
- از APIهای رسمی بانک خود یا ابزارهای شخص اول (مانند دستیار JPMorgan) برای خودکارسازی مالی استفاده کنید؛ از اشتراک‌گذاری رمزعبور با ابزارهای شخص ثالث خودداری کنید.
- اگر توسعه‌دهنده عامل هستید، پیش‌نویس‌های FDX و OpenID برای OAuth عامل‌محور را رصد کنید و از امروز معماری خود را برای احراز هویت بدون سر (headless auth) و اعتبارنامه‌های قابل تأیید سازگار کنید.
- برای پیگیری پیشرفت استانداردها، گروه کار FDX «Agent Identity» و پیش‌نویس‌های OpenID Connect for Agents را در GitHub ردیابی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و هزینه استنتاج عامل‌ها مراجعه کنید.
گفتگو