31 января 2026 года стало известно об утечке данных из Moltbook — социальной сети, созданной специально для AI-агентов. Наружу вышла незашифрованная база данных: 35 000 адресов электронной почты, 1,5 миллиона API-токенов агентов, 770 000 активных агентов под угрозой компрометации. Но куда хуже другое: в приватных сообщениях хранились открытые учётные данные третьих сторон — в том числе ключи OpenAI API — в той же таблице, что и токены, которых достаточно для полного перехвата агентов. Один запрос к базе, и атакующий получает и агентов, и доступ к чужим системам.
Этот случай хорошо иллюстрирует то, что специалисты по безопасности называют «токсичными связками» (toxic combinations). Речь идёт о ситуации, когда два или более приложения соединяются через посредника — AI-агента, OAuth-грант, MCP-сервер или интеграционный коннектор — и каждое из них по отдельности выглядит безопасным, а вот их комбинация создаёт зону риска, которую никто намеренно не санкционировал и никто не контролирует.
Механика проблемы довольно проста. Разработчик устанавливает MCP-коннектор, чтобы публиковать фрагменты кода из IDE прямо в Slack. Администратор Slack одобряет бота, администратор IDE одобряет исходящее соединение — и каждый видит только свою часть. Но связка работает в обе стороны: prompt-инъекции из IDE могут утечь в Slack, а вредоносные инструкции из Slack — попасть обратно в контекст среды разработки. Похожая схема возникает, когда AI-агент соединяет Google Drive и Salesforce или бот связывает репозиторий с командным каналом. Комбинации разные, логика одна.
По данным отчёта State of SaaS Security 2025, опубликованного Cloud Security Alliance (CSA), 56% организаций уже обеспокоены избыточным доступом API в своих SaaS-to-SaaS интеграциях. И это только те, кто вообще осознаёт проблему.
Традиционные проверки доступа построены вокруг одного приложения за раз. Это имело смысл, когда SaaS-продуктов было мало и они почти не взаимодействовали между собой. Сегодня среда принципиально другая: нечеловеческих идентичностей — сервисных аккаунтов, ботов, AI-агентов — стало больше, чем людей. Они не устают, не уходят в отпуск, и за ними никто не смотрит. Доверительные отношения между системами возникают не при первоначальной настройке, а в рантайме — и никакой централизованный каталог управления идентичностями об этом не знает.
OAuth и MCP-мосты соединяют приложения без ведома систем идентификации и governance-каталогов. Когда токен, выданный однажды, начинает со временем использоваться за пределами изначально согласованных scope'ов, это никого не оповещает автоматически. Именно в этом зазоре и живут токсичные связки.
Закрыть этот зазор процедурными мерами можно, но только если пересмотреть саму логику проверок. Вместо аудита внутри каждого приложения нужен аудит между приложениями. Каждый AI-агент, бот, MCP-сервер и OAuth-интеграция должны иметь владельца и дату пересмотра — как обычные пользователи. Появление нового «write»-права у идентичности, у которой уже есть «read» в другом приложении, должно флагироваться до одобрения, а не после. Каждый связывающий коннектор при создании должен проходить проверку с явным указанием обеих сторон моста. Токены, вышедшие за пределы исходных scope'ов, подлежат отзыву, не продлению. Аномалии в межприложеном доступе — когда идентичность вдруг начинает работать с новыми комбинациями приложений — это ранние признаки формирующейся токсичной связки.
Но вручную это не масштабируется. Дюжина интеграций ещё поддаётся ручной проверке, несколько сотен — уже нет. Здесь нужны платформы, которые непрерывно наблюдают за рантаймовым графом связей. Системы класса IGA (Identity Governance and Administration) инвентаризируют роли в онбордированных системах — но они смотрят на момент подключения, а не на то, что происходит после. Динамические платформы SaaS-безопасности работают иначе: они следят за тем, какие идентичности к каким приложениям обращались, какие scope'ы реально использовались и какие трасты возникли уже после первоначальной настройки.
Одним из примеров таких платформ является Reco. Она оценивает комбинацию Slack, Drive и Salesforce не как три отдельных разрешения, а как единую поверхность риска. Инструмент обнаруживает несанкционированных AI-агентов и OAuth-идентичности, в том числе теневые, которые никто официально не регистрировал. Knowledge Graph платформы отображает связи между человеческими и нечеловеческими идентичностями и приложениями, которых они касаются: в частности, он способен обнаружить токсичную связку между Slack и Cursor (популярной IDE), а также показать, какие агенты подключены к GitHub. Выявленный аномальный доступ блокируется до того, как успевает быть использован.
Следующие крупные инциденты, скорее всего, не будут связаны с эксплуатацией новых zero-day уязвимостей. Они будут выглядеть как штатная работа авторизованных агентов — всё легитимно, всё по протоколу, вплоть до момента, когда данные окажутся там, где им быть не следует. Видеть всю цепочку целиком, а не отдельные её звенья — это и есть то, чего сейчас не хватает большинству команд безопасности.
Изображение носит иллюстративный характер
Этот случай хорошо иллюстрирует то, что специалисты по безопасности называют «токсичными связками» (toxic combinations). Речь идёт о ситуации, когда два или более приложения соединяются через посредника — AI-агента, OAuth-грант, MCP-сервер или интеграционный коннектор — и каждое из них по отдельности выглядит безопасным, а вот их комбинация создаёт зону риска, которую никто намеренно не санкционировал и никто не контролирует.
Механика проблемы довольно проста. Разработчик устанавливает MCP-коннектор, чтобы публиковать фрагменты кода из IDE прямо в Slack. Администратор Slack одобряет бота, администратор IDE одобряет исходящее соединение — и каждый видит только свою часть. Но связка работает в обе стороны: prompt-инъекции из IDE могут утечь в Slack, а вредоносные инструкции из Slack — попасть обратно в контекст среды разработки. Похожая схема возникает, когда AI-агент соединяет Google Drive и Salesforce или бот связывает репозиторий с командным каналом. Комбинации разные, логика одна.
По данным отчёта State of SaaS Security 2025, опубликованного Cloud Security Alliance (CSA), 56% организаций уже обеспокоены избыточным доступом API в своих SaaS-to-SaaS интеграциях. И это только те, кто вообще осознаёт проблему.
Традиционные проверки доступа построены вокруг одного приложения за раз. Это имело смысл, когда SaaS-продуктов было мало и они почти не взаимодействовали между собой. Сегодня среда принципиально другая: нечеловеческих идентичностей — сервисных аккаунтов, ботов, AI-агентов — стало больше, чем людей. Они не устают, не уходят в отпуск, и за ними никто не смотрит. Доверительные отношения между системами возникают не при первоначальной настройке, а в рантайме — и никакой централизованный каталог управления идентичностями об этом не знает.
OAuth и MCP-мосты соединяют приложения без ведома систем идентификации и governance-каталогов. Когда токен, выданный однажды, начинает со временем использоваться за пределами изначально согласованных scope'ов, это никого не оповещает автоматически. Именно в этом зазоре и живут токсичные связки.
Закрыть этот зазор процедурными мерами можно, но только если пересмотреть саму логику проверок. Вместо аудита внутри каждого приложения нужен аудит между приложениями. Каждый AI-агент, бот, MCP-сервер и OAuth-интеграция должны иметь владельца и дату пересмотра — как обычные пользователи. Появление нового «write»-права у идентичности, у которой уже есть «read» в другом приложении, должно флагироваться до одобрения, а не после. Каждый связывающий коннектор при создании должен проходить проверку с явным указанием обеих сторон моста. Токены, вышедшие за пределы исходных scope'ов, подлежат отзыву, не продлению. Аномалии в межприложеном доступе — когда идентичность вдруг начинает работать с новыми комбинациями приложений — это ранние признаки формирующейся токсичной связки.
Но вручную это не масштабируется. Дюжина интеграций ещё поддаётся ручной проверке, несколько сотен — уже нет. Здесь нужны платформы, которые непрерывно наблюдают за рантаймовым графом связей. Системы класса IGA (Identity Governance and Administration) инвентаризируют роли в онбордированных системах — но они смотрят на момент подключения, а не на то, что происходит после. Динамические платформы SaaS-безопасности работают иначе: они следят за тем, какие идентичности к каким приложениям обращались, какие scope'ы реально использовались и какие трасты возникли уже после первоначальной настройки.
Одним из примеров таких платформ является Reco. Она оценивает комбинацию Slack, Drive и Salesforce не как три отдельных разрешения, а как единую поверхность риска. Инструмент обнаруживает несанкционированных AI-агентов и OAuth-идентичности, в том числе теневые, которые никто официально не регистрировал. Knowledge Graph платформы отображает связи между человеческими и нечеловеческими идентичностями и приложениями, которых они касаются: в частности, он способен обнаружить токсичную связку между Slack и Cursor (популярной IDE), а также показать, какие агенты подключены к GitHub. Выявленный аномальный доступ блокируется до того, как успевает быть использован.
Следующие крупные инциденты, скорее всего, не будут связаны с эксплуатацией новых zero-day уязвимостей. Они будут выглядеть как штатная работа авторизованных агентов — всё легитимно, всё по протоколу, вплоть до момента, когда данные окажутся там, где им быть не следует. Видеть всю цепочку целиком, а не отдельные её звенья — это и есть то, чего сейчас не хватает большинству команд безопасности.
