Инъекции инструкций часто выглядят как лабораторный трюк против игрушечного чат-бота. Новый отчёт PromptArmor об Atlassian Rovo важнее: он показывает практический риск для корпоративных систем. AI-ассистент читает приватные рабочие данные, обрабатывает недоверенный текст и при этом сохраняет способ обратиться к внешнему адресу. Именно здесь должна проходить защитная граница.

AI-ассистент упирается в защитный шлюз, который не даёт отправить корпоративные документы наружу

PromptArmor опубликовала отчёт 5 августа 2026 года. Исследователи утверждают, что Rovo можно заставить отправить содержимое тикетов Jira и документов Confluence на сайт злоумышленника через скрытую инструкцию. По их словам, они сообщили Atlassian о проблеме 23 мая, получили номер обращения 25 мая, повторно писали в июне и июле, а затем опубликовали материал после более чем двух месяцев без публичного исправления или ответа. На момент подготовки статьи я не нашёл открытого сообщения Atlassian, которое опровергало бы эти выводы.

Это не означает, что у всех клиентов Atlassian уже произошла утечка. Публичные материалы описывают уязвимый сценарий и демонстрацию атаки, а не массовую эксплуатацию. Правильная реакция — не паника, а спокойная проверка: относиться к AI-ассистенту внутри рабочих сервисов как к программе с доступом к данным и сетевыми возможностями, а не как к более умному поиску.

Важен не только доступ к чтению

Rovo — AI-слой Atlassian для работы с Jira, Confluence и подключёнными внешними сервисами. На продуктовой странице Atlassian описывает его как ассистента, который знает бизнес компании, собирает контекст по людям, проектам и коду, а также подключается к сторонним SaaS-сервисам. В списке коннекторов есть Google Drive, GitHub, GitLab, Microsoft SharePoint, Outlook Mail, Gmail, Zendesk, Box, Dropbox, Figma, Azure DevOps, ServiceNow, Slack и другие источники.

Это ценность продукта и одновременно его модель риска. В Jira и Confluence часто лежат дорожные карты, обращения клиентов, заметки об инцидентах, обсуждения безопасности, планы разработки, юридические фрагменты и ссылки на другие системы. Полезному ассистенту нужен этот контекст. Безопасному ассистенту нужны строгие правила: куда этот контекст можно передавать.

Страницы Atlassian о доверии к AI говорят, что права платформы и права сторонних коннекторов учитываются при корректной настройке. Там же сказано, что администрируемые коннекторы не включены по умолчанию и что для Google Drive или SharePoint можно настраивать списки разрешённого и запрещённого содержимого. Это важные меры, но они отвечают не на весь вопрос. Доступ на чтение определяет, что Rovo может увидеть. Защита от вывода данных определяет, куда Rovo может отправить увиденное.

Что произошло по версии исследователей

Сценарий можно объяснить без вредных технических деталей. Сначала недоверенный текст попадает в область, которую ассистент может читать. В примере PromptArmor это файл со скрытыми инструкциями, но исследователи отдельно пишут, что похожий текст может прийти из обращений поддержки, внешних документов, подключённых приложений или веб-данных при включённом поиске.

Затем пользователь просит Rovo выполнить обычную рабочую задачу, например разобрать тикеты. Ассистент просматривает Jira и Confluence, потому что именно для этого он создан. Скрытая инструкция пытается заставить его добавить чувствительное содержимое во внешний адрес. После этого инструмент открытия URL обращается к адресу, а принимающий сервер может увидеть данные в журналах.

Ключевая деталь — инструмент открытия URL. PromptArmor утверждает, что сценарий работает даже при отключённом веб-поиске Rovo, потому что настройка поиска не убирает инструмент, который открывает найденные адреса. Иными словами, выключенная видимая функция поиска не обязательно выключает все сетевые пути, которыми может воспользоваться ассистент.

Именно это должны проверять администраторы. Настройка с названием “веб-поиск” звучит как пользовательская функция. Риск находится глубже: может ли модель попросить систему открыть адрес, который она сама составила? Если да, у ассистента остаётся канал наружу.

Почему это не просто “модель поверила инструкции”

Удобно сказать, что модель слишком доверчива. Но это не главный вывод. Модель работает внутри системы инструментов. Если эта система одновременно даёт ей приватные данные и средство внешней связи, решение модели становится слабым местом для контроля.

Полезна формула Саймона Уиллисoна: приватные данные, недоверенный контент и внешняя коммуникация. Любые два элемента ещё можно удержать под контролем. Все три вместе создают путь для вывода данных. Rovo здесь не уникален: похожая схема возможна у браузерных агентов, ассистентов для кода, офисных помощников, ботов поддержки и внутренних поисковых систем.

Защита должна быть детерминированной. Инструмент открытия адресов не должен ходить по произвольным URL, собранным моделью. Безопаснее разрешать только адреса, явно указанные пользователем или возвращённые доверенным поисковым компонентом, и блокировать параметры, куда могли попасть чувствительные данные. Удалённые изображения в Markdown тоже надо рассматривать как сетевые запросы: если ассистент может вставить картинку с секретом в адресе, запрос к изображению становится маяком.

Что уже видно из документации Atlassian

Открытые материалы Atlassian дают администраторам несколько опорных фактов. Rovo работает с приложениями Atlassian и внешними источниками. Поиск может показывать результаты из Jira, Confluence и подключённых сервисов с учётом прав пользователя. Страница доверия к AI говорит, что администраторы организации могут отключать AI-функции Rovo в Atlassian Administration, но также уточняет: функции Rovo без генеративного AI, например Rovo Search, отключить нельзя.

Это различие важно. Одни настройки управляют генерацией. Другие — поиском. Третьи — индексированием коннекторов. Четвёртые — тем, какие данные видит конкретный пользователь. Отчёт PromptArmor говорит о пути через инструмент, который может остаться доступным несмотря на настройку веб-поиска. Значит, нельзя считать, что один переключатель закрывает все внутренние возможности.

Что известно и чего мы не знаем

Известно: PromptArmor заявляет о демонстрации вывода данных из Jira и Confluence через скрытую инструкцию и инструмент открытия URL. Известно: по словам исследователей, после попадания вредного текста в контекст ассистент не требовал дополнительного подтверждения человека. Известно: они утверждают, что отключение веб-поиска не убирало нужный сетевой путь. Известно: Atlassian сама описывает Rovo как широкого корпоративного ассистента с коннекторами к важным рабочим системам.

Не известно из публичных источников: были ли реальные кражи данных у клиентов. Не известно: выпустила ли Atlassian тихое исправление после публикации. Не известно: считает ли Atlassian это уязвимостью, ограничением продукта или вопросом конфигурации. Открытого CVE или бюллетеня Atlassian по этому конкретному отчёту на момент проверки я не нашёл.

Эти неизвестные детали снижают уровень шума, но не отменяют практических действий. Командам безопасности часто приходится реагировать на убедительные архитектурные риски до того, как появятся сведения о массовой эксплуатации.

Что проверить администраторам

Сначала выясните, включены ли Rovo и AI-функции Atlassian в вашей организации. Не опирайтесь только на маркетинговую страницу: проверьте реальную административную консоль своего тенанта.

Затем составьте список коннекторов. Особое внимание — широким хранилищам документов вроде Google Drive и SharePoint, системам разработки GitHub и GitLab, сервисам поддержки Zendesk и ServiceNow, почте Gmail и Outlook. Коннектор, безопасный для обычного поиска, может стать опаснее, если ассистент смешивает его результаты с недоверенными инструкциями и внешними запросами.

Ограничьте подключённые данные по принципу минимальных прав. Не подключайте весь диск или корневой SharePoint-сайт, если достаточно узкого списка разрешённых папок. Проверьте группы, гостей, подрядчиков и старые учётные записи.

Задайте Atlassian конкретный вопрос: если веб-поиск отключён, может ли Rovo открыть URL, составленный моделью? Если да, можно ли выключить эту возможность, ограничить её доверенными источниками или журналировать каждый такой запрос? Если нет, где это документировано и с какой даты действует гарантия?

По возможности блокируйте внешние адреса, собранные моделью. Если продукт не умеет делать это сам, используйте сетевые журналы, прокси или правила предотвращения утечек, которые замечают чувствительные данные в параметрах запросов. Это не идеальная защита, но она превращает невидимый канал в наблюдаемый.

Отдельно проверяйте удалённые изображения. Предпросмотр или Markdown-картинка — это тоже сетевой запрос. Он не должен уходить на произвольный внешний домен вместе с внутренними данными в адресе.

Для действий наружу требуйте подтверждение человека. В окне подтверждения должны быть видны назначение, тип данных и причина обращения. Фразы “ассистент хочет открыть ссылку” недостаточно.

Что делать обычным пользователям

Пользователь не исправит архитектуру продукта, но может снизить риск. Не загружайте случайные внешние файлы в ассистента, который одновременно подключён к чувствительным тикетам и документам. Осторожно просите привилегированного ассистента пересказывать неизвестные вложения клиентов, документы поставщиков, веб-страницы и обращения поддержки. Если ассистент неожиданно предлагает открыть внешние ссылки, вставляет странные ссылки на изображения или выдаёт текст, похожий на скрытые инструкции, сообщите администраторам.

Командам тоже стоит перестать воспринимать AI-ассистента как личный черновик. Если у него есть доступ к проектным данным, он уже часть рабочего контура и должен подчиняться тем же правилам, что поиск, автоматизация и интеграции.

Главный урок

Фраза “модель должна понять, что нельзя сливать данные” не является мерой безопасности. Граница должна быть на уровне инструментов. Нужны списки разрешённых адресов, проверки класса данных, правила происхождения контента, подтверждения, журналы и безопасные настройки по умолчанию.

Корпоративные AI-ассистенты встраиваются в рабочие продукты, потому что они полезны. Они быстрее находят контекст, пересказывают шумные тикеты, помогают с черновиками и связывают данные между системами. Риск не делает их бесполезными. Он означает, что ассистента с доступом к Jira, Confluence, почте, документам и коду нужно описывать не словами “умный поиск”, а списком прав: что он читает, что отображает, какие инструменты вызывает, куда может отправлять данные и кто это проверяет.

Инъекция инструкций в корпоративном SaaS — уже не только проблема текста. Это проблема прав доступа и исходящих каналов. Спокойный ответ: проверять границы до того, как ассистент получает путь во внешний мир.