Morgan Stanley заблокировал AI-агентов, входивших в клиентские аккаунты с учётными данными пользователей. JPMorgan и ряд других крупных американских банков движутся в том же направлении. Общая позиция пока одна: агентам — только чтение, транзакции — только человек.
Контекст
Agentic AI — не концепция из будущего, а текущая реальность. Пользователи уже сегодня подключают AI-инструменты к своим финансовым аккаунтам, нередко передавая им банковский логин и пароль напрямую. Иногда это происходит без чёткого осознания: инструмент запрашивает доступ к данным, пользователь соглашается — и агент идёт логиниться как живой человек.
Ничего принципиально нового здесь нет. Финансовые агрегаторы годами использовали так называемый screen scraping — автовход под чужими кредами для сбора данных о счетах. Банки это не любили, но терпели. Принципиальная разница сейчас — в действиях. Агрегатор читал баланс. AI-агент может переводить деньги, оплачивать счета, менять настройки — если дать ему такие права.
Morgan Stanley — один из крупнейших финансовых институтов мира по управлению состояниями. Их решение заблокировать агентский доступ через credential sharing — чёткий сигнал всей отрасли. Банки несут юридическую ответственность за транзакции. Когда непонятно, кто совершил действие — клиент или его AI — это не просто техническая проблема, это юридическая катастрофа.
Аналитика
За этой историей — фундаментальный конфликт архитектур. Agentic AI строится на идее делегирования: агент действует от имени человека автономно — читает, решает, совершает действия. Банковская безопасность строится на противоположной логике: каждое действие должно быть авторизовано конкретным человеком в конкретный момент. Эти две идеи несовместимы без правильного протокола делегирования.
Индустрия движется к стандарту агентской авторизации. OAuth 2.0 существует давно, но проектировался для приложений, а не для автономных агентов, которые действуют асинхронно и могут принимать решения без подтверждения пользователя в реальном времени. Дискуссии вокруг MCP и смежных протоколов показывают: технологическое сообщество понимает проблему. Банковский сектор пока отвечает запретом — и это прагматичное, хотя и временное решение.
Для AI-first бизнеса здесь важный урок. Строить финансовую автоматизацию на credential sharing — значит строить на фундаменте, который в любой момент рухнет по решению банка. Будущее за официальными API с гранулярными правами: агент видит транзакции, анализирует — но не переводит деньги без явного подтверждения пользователя. Банки, которые это поймут первыми и выпустят agent-ready API, получат серьёзное конкурентное преимущество.
Кейсы применения в бизнесе
B2B SaaS финтех-стартап: если вы строите продукт, читающий банковские данные клиентов, — интеграция через официальные open banking API теперь не просто хорошая практика, а необходимость. Банки будут блокировать сторонние входы по логинам. Архитектура через официальные партнёрские программы и открытые стандарты — единственный устойчивый путь к масштабированию без риска внезапного отключения.
Корпоративная финансовая команда: автоматизация казначейства через AI — реальная задача, но не через передачу паролей от банк-клиента. Рабочая схема: AI-агент получает данные через официальный экспорт или корпоративный API, анализирует движение средств, предлагает решения — финансист нажимает «подтвердить». Агент без права транзакции, но с полным аналитическим доступом — безопасная и работающая конфигурация уже сейчас.
SMB и локальный бизнес в КР/СНГ: искушение дать AI доступ к интернет-банку «чтобы сам следил» понятно. Но ни один банк в регионе не проектировал такой сценарий. Блокировки возможны в любой момент, и апеллировать будет некуда. Надёжнее: подключить бухгалтерскую систему с официальным форматом обмена с банком и уже через неё передавать данные AI-инструменту.
Кейсы в личной жизни
Разработчик, строящий персонального финансового агента: credential sharing технически простой, но ненадёжный путь. Официальные open banking стандарты и CSV/OFX-выгрузки выписок — менее «агентно», зато не ломается при смене пароля, не нарушает условия использования банка и не приводит к блокировке счёта как подозрительного.
Пользователь с AI-ассистентом для личных финансов: не стоит давать сторонним AI-инструментам банковский логин — даже если сервис выглядит надёжным. Банк может расценить автоматизированный вход как мошенничество и заблокировать аккаунт. Альтернатива: приложения для трекинга расходов с официальными банковскими интеграциями, которые отдают AI структурированные данные без прямого доступа к аккаунту.
Фрилансер, автоматизирующий учёт: AI отлично анализирует финансы — если вы сами периодически выгружаете выписку и передаёте её агенту. Полуавтоматическая схема, но она работает сегодня и не зависит от банковских ограничений. Анализ расходов по категориям, налоговые шаблоны, напоминания о крупных платежах — всё это реально без единого пароля.
Как применить сегодня
- Не передавать банковские логин и пароль AI-агентам и сторонним сервисам — ни лично, ни корпоративно.
- Разработчикам: строить финансовые интеграции через официальные API и open banking стандарты, а не через автологин с паролем.
- Перед подключением AI-инструмента к финансовым данным: проверить, что именно он запрашивает — если требует пароль, а не OAuth-токен, искать альтернативу.
- Для бизнеса: провести быстрый аудит всех AI-интеграций с банковскими системами — какие из них используют credential sharing и несут риск внезапной блокировки.
- Следить за стандартами агентской авторизации: MCP-протоколы для финансовых данных и OAuth-расширения для автономных агентов — это ближайший горизонт, который изменит правила игры в fintech.
