Как Asana решает проблему «смертельной триады»: взгляд на безопасность агентного ИИ
Агентный ИИ представляет собой класс рисков безопасности, который отрасль ещё не решила. Вот как мы в Asana рассматриваем эту проблему и какие инварианты безопасности мы применяем ко всем нашим функциям ИИ.
Проблема
Агентные системы ИИ не просто отвечают на вопросы. Они читают документы, выполняют действия и координируют работу между инструментами. Чем больше они могут делать, тем больше их поверхность атаки.
В отличие от обычного кода, LLM обладают свойством, которое принципиально усложняет эту задачу: они не могут надёжно отличать инструкции от данных. Всё, что подаётся в LLM, попадает в один и тот же поток, поэтому тщательно созданный фрагмент данных может захватить модель так же, как и легитимная инструкция. В этом заключается суть внедрения в подсказку, которое Саймон Уиллисон называет «первородным грехом» приложений на основе LLM.
Это не просто теория. Исследователи продемонстрировали этот класс атак против Microsoft 365 Copilot, сервера MCP GitHub, Slack AI и многих других. Брюс Шнайер прямо заявил: в отрасли пока нет надёжной защиты от этого класса атак.
Так как же ответственно создавать агентный ИИ, если отрасль не разобралась с основами?
Смертоносная триада
Уиллисон выделяет три основные возможности, которые в сочетании создают условия для причинения вреда:
Доступ к конфиденциальным данным. Агент может читать конфиденциальную или частную информацию.
Воздействие ненадёжного контента. Агент обрабатывает входные данные, которые могут содержать скрытые вредоносные инструкции.
Возможность внешней коммуникации. Агент может отправлять информацию за пределы системы.
Полезное уточнение по третьему пункту: на самом деле речь идет о способности создавать побочные эффекты, а не только об исходящем общении. Передача данных на сервер злоумышленника — классический пример, но вредоносная инструкция, которая незаметно переименовывает каждый проект в рабочем пространстве или отправляет конфиденциальный контент в неправильный внутренний канал, представляет собой проблему того же типа. Мы используем термин «внешнее общение» в качестве сокращения, но на самом деле защищаемся от более широкого понятия.
Любой из трёх китов можно контролировать. Даже двумя одновременно — обычно тоже. Но когда сходятся все три, у вас есть жизнеспособный путь атаки.
Важный вывод: устранение любой из этих составляющих существенно снижает общий риск. Нам не нужно идеально решать проблему внедрения через подсказку. Никто этого не сделал. Нам нужно сделать так, чтобы все три условия не могли легко сосуществовать.
Корни Ситсма опирается на это, сопоставляя три фактора с такими мерами по снижению риска, как песочница, декомпозиция задач, наименьшие привилегии и участие человека в цикле. Это строительные блоки. Вопрос в том, как их реализовать.
Контекст, контрольные пункты и меры контроля
Мы организуем наше мышление вокруг трёх столпов, которые напрямую связаны со смертельной триадой. Каждый из них ограничивает одну ножку.
В Asana есть несколько интерфейсов ИИ. ИИ-ассистенты — это агенты, которые являются участниками команды и имеют свои собственные уровни участника и разрешения в рабочем пространстве. Другие функции ИИ действуют как пользователь, при этом границей является то, к чему у этого пользователя уже есть доступ. Приведенные ниже инварианты относятся к случаю агента, где поверхность наибольшая, и мы укажем, где реализация отличается в зависимости от поверхности.
Контекст: управление тем, что видит ИИ
Этап Trifecta: доступ к конфиденциальной информации
Чтобы агентный ИИ был полезен, ему нужен контекст. Задача заключается в том, чтобы предоставить ему достаточно информации, чтобы он мог быть полезным, но не давать ему «мастер-ключ».
Нашим основополагающим инвариантом является принцип наименьших необходимых прав, точное выражение которого зависит от интерфейса. Для ИИ-ассистентов, которые имеют свой собственный уровень участника, отдельный от любого отдельного пользователя, границей является пересечение разрешений участника команды и пользователя. Для функций ИИ, которые действуют как пользователь, границей является просто собственный доступ этого пользователя. В каждом случае доступ ИИ регулируется тем же уровнем авторизации на стороне сервера, который управляет всеми остальными взаимодействиями в Asana. Функции ИИ не получают повышенных разрешений. Они работают в рамках системы контроля доступа Asana, а не в обход неё.
Определение контекста — это не только регулирование внутреннего доступа к данным в Asana; оно в равной степени охватывает внешние интеграции, с которыми может взаимодействовать агент. Хотя в настоящее время интеграции требуют явной авторизации пользователя, мы разрабатываем детализированные пути управления для конкретных агентов. Это позволяет организациям ограничивать права интеграции для ИИ-ассистентов, обрабатывающих входные данные с высоким уровнем риска. Наш основной архитектурный инвариант ясен: граница того, что может видеть ИИ, должна быть динамичной и определяться владельцами данных, а не быть жёстко заданной по умолчанию в продукте.
Даже если злоумышленник внедрит вредоносные инструкции в контекст ИИ, то, что ИИ действительно может видеть, ограничено той же моделью разрешений, что и всё остальное.
Контрольные пункты: фильтрация того, что слушает ИИ
Этап трифекты: воздействие ненадёжного контента
Это самый сложный этап. На платформе для управления работой ИИ в основном считывает контент, созданный пользователями: задачи, комментарии, прикреплённые документы. Часть этого контента поступает извне организации. Вы не можете отказаться от его прочтения.
Вместо этого мы устанавливаем контрольные пункты: места, где мы отличаем доверенное намерение от произвольного контента и где люди могут вмешаться, если что-то выглядит неправильно.
Обработка инструкций с учётом источника. Функции ИИ помечают контент по доверию к автору и по источнику, поэтому модель может придавать больший вес инструкциям от авторизованных пользователей, чем инструкциям, встречающимся в произвольном контенте в процессе работы. Это сужает поверхность атаки для внедрения подсказок, но не закрывает её полностью; модель по-прежнему считывает всё в контексте, и гарантия безопасности является частичной, а не абсолютной. Ограничения этого подхода мы обсудим ниже.
Ведение журналов и экспертное расследование. Каждый вызов модели регистрируется в журнале с указанием входных и выходных данных, субъекта, контекста функции и последующих событий, включая то, какие объекты рабочего графа затронула автоматизация и какие URL-адреса появились в выходных данных. Мы автоматически оповещаем об операционных сигналах, таких как частота ошибок и резкое увеличение затрат. В случае аномалий, связанных с безопасностью, эти же журналы используются для последующего расследования людьми. Как отмечает Уиллисон, даже обнаружение на основе шаблонов, которое позволяет выявить большинство атак, само по себе было бы недостаточным; видимость и возможность расследования — это прочный фундамент, на котором мы строим, а не стена.
Дизайн с участием человека. Функции ИИ предоставляют результаты своей работы на проверку человеку, а не выполняют необратимые действия в фоновом режиме.
Разбивка задач и ограниченные действия. Сложные рабочие процессы разбиваются на более мелкие этапы, а действия, доступные функциям ИИ, намеренно ограничиваются, а не являются открытыми.
Ни один из этих элементов по отдельности не является абсолютно надежным. Вместе они образуют глубокоэшелонированную защиту.
Меры контроля: ограничение действий ИИ
Третья составляющая: способность создавать побочные эффекты
Третья опора — это то место, где происходит большинство реальных атак. Если злоумышленник убедит ИИ внедрить конфиденциальные данные в URL-адрес, отправить их через интеграцию или изменить запись, на которую полагаются другие люди, атака будет успешной.
Здесь мы развиваем несколько категорий контроля:
Относитесь к результатам LLM как к ненадежным. Сгенерированный контент не получает повышенного доверия только потому, что он создан Asana AI. Он проходит через те же пути проверки и рендеринга, что и любой другой контент, созданный пользователем.
Обязательное подтверждение человеком для действий с высоким уровнем воздействия. Определённые категории действий всегда требуют явного подтверждения человеком, независимо от того, насколько уверен ИИ или насколько рутинным выглядит запрос. Для ИИ-ассистентов это включает действия, которые расширяют доступ (изменение разрешений, добавление участников), и действия, которые уничтожают данные (удаление). ИИ может предлагать такие действия, но не может выполнять их самостоятельно.
Ограничения на обработку ссылок. Внешние URL-адреса в контенте, сгенерированном ИИ, обрабатываются до того, как они попадут к пользователю. Новые URL-адреса, которых не было во входных данных, проходят дополнительную проверку и отображаются в своей полной, нескрытой форме, а не в виде переименованного якорного текста, поэтому ИИ нельзя использовать в качестве оружия, чтобы замаскировать конечную точку для извлечения данных под дружелюбную фразу «нажмите здесь, чтобы посмотреть сводку».
Отсутствие универсального исходящего HTTP. Функции ИИ не имеют открытого примитива «сделать запрос к любому URL». Внешние интеграции проходят через ограниченные каналы с собственной авторизацией.
Журнал аудита действий. Каждая запись, изменение и исходящее действие, выполняемое функцией ИИ, регистрируется вместе с вызовом модели, который его вызвал, поэтому специалист по расследованию может восстановить, что сделал ИИ, а не только то, что ему было предложено.
Цель не в том, чтобы сделать внешнее общение невозможным. Функции ИИ должны ссылаться на ссылки, обновлять задачи и выдавать полезные результаты. Цель состоит в том, чтобы они не могли делать это скрытно, вопреки намерениям пользователя.
Шаблон для значений, выдаваемых ИИ
Внутри этой структуры постоянно возникает одна и та же конкретная подпроблема: функция ИИ производит что-то (идентификатор объекта, получателя, URL-адрес), а последующий код воздействует на это, часто с более широкими разрешениями, чем у самого ИИ. Галлюцинации и внедрение подсказок приводят к одному и тому же: значение, выдаваемое моделью, считается достоверным.
Мы используем шаблон из четырех частей в качестве контрольного списка для проверки дизайна этих значений:
Ограничьте то, что ИИ может создавать, прежде чем запускать проверку.
Проверяйте каждое значение, созданное ИИ, на стороне сервера с использованием того же уровня авторизации, что и для всего остального. Модель рассматривается как ненадёжный клиент.
Обоснуйте выбор, сохранив достаточно структурированного контекста, чтобы объяснить, почему ИИ выбрал именно это. Именно это делает возможным последующее расследование, оценку и реагирование на инциденты.
Используйте эскалацию с фрикшном, откат или проверку человеком, когда значение сопряжено с высоким риском или выходит за рамки ожидаемого диапазона.
Ключевой момент: поведение модели не должно быть основным средством контроля безопасности. Улучшенные подсказки и заявления типа «мы сказали модели не делать этого» являются полезной глубокоэшелонированной защитой, но надежные средства контроля находятся в системе вокруг модели.
Основано на принципах
Эти решения не являются ситуативными. Они вытекают из опубликованных принципов Asana в отношении ИИ.
Люди несут ответственность за решения, и это определяет дизайн, ориентированный на контрольные точки. ИИ помогает, но люди остаются в курсе событий и несут ответственность.
Мы стремимся обеспечить безопасность, что оправдывает инвестиции в многоуровневые средства контроля, даже если они создают дополнительные сложности. Альтернативный подход усугубляет риск, поскольку функции ИИ берут на себя более сложную работу.
Мы продвигаем прозрачность, поэтому и пишем эту публикацию. Мы ещё не решили проблему безопасности агентного ИИ. Но открытость в отношении того, как мы рассуждаем об этих рисках и мерах по их снижению, помогает более широкому сообществу добиться прогресса в решении общей проблемы и способствует тщательной проверке, которая делает нас лучше.
Честные ограничения
Проблема внедрения в подсказки до сих пор принципиально не решена, а косвенное внедрение в подсказки (вредоносные инструкции внедряются в контент, который ИИ получает в ходе работы, а не в контент, который пользователь передаёт ему напрямую) — это вариант, от которого отрасль пострадала больше всего в 2026 году. Тегирование с учетом источника помогает, но не полностью устраняет эту проблему, поскольку модель всё равно должна принимать решение о том, учитывать ли теги. Наши контрольные пункты значительно снижают риск, но не устраняют его. Пока инструкции и данные находятся в одном контекстном окне, вредоносные входные данные, полученные с помощью поиска, публичных форм или интеграций, иногда будут проскальзывать. Мы рассматриваем это как активную, постоянно развивающуюся область инвестиций, где мы тщательно проверяем любой путь, по которому контент, созданный внешними авторами, может попасть в агентную функцию. Работа над шаблонами дизайна для защиты агентов LLM указывает на многообещающие направления, но консенсус в отрасли всё ещё формируется.
Ситуация с угрозами быстро меняется. Постоянно появляются новые векторы: от невидимого внедрения подсказок на основе изображений до многоэтапных цепочек кражи данных. Мы разрабатываем многоуровневые и комбинируемые средства контроля, чтобы по мере появления новых угроз можно было добавлять новые меры по их нейтрализации. Это гонка вооружений, а не проблема, которую можно решить раз и навсегда. OWASP Top 10 для приложений LLM — полезный постоянно обновляемый справочник.
Мы не считаем эти пробелы поводом для замедления. Мы рассматриваем их как причины действовать осознанно. Смертельная триада говорит нам о том, что поставлено на карту. Контекст, контрольные пункты и средства контроля дают нам фреймворк для действий. И поскольку ни одна команда не решает эту проблему в одиночку, мы активно инвестируем вместе с нашими партнёрами по исследованиям и клиентами, чтобы укрепить эти поверхности по мере развития ландшафта угроз.
Справочные материалы
Саймон Уиллисон, «Смертельная трифекта для агентов ИИ», июнь 2025 г.
Корни Ситсма, «Агентный ИИ и безопасность», Martin Fowler, октябрь 2025 г.
Брюс Шнайер, «We Are Still Unable to Secure LLMs from Malicious Inputs», август 2025 г.
OWASP, «Топ-10 для приложений LLM»
