Содержание
Признаюсь сразу: значительную часть рутины я уже отдал ИИ. Этот блог во многом ведёт агент — Claude Code пишет черновики по моим материалам, генерирует обложки, импортирует фотографии в галерею, собирает сайт и деплоит его в облако. Я ставлю задачу и принимаю работу. Недавно поймал себя на мысли: дома это выглядит прекрасно, а вот на работе, в регулируемой финансовой организации, я бы такого агента к системам близко не подпустил — по крайней мере, в таком виде.
Из этого противоречия и родилась статья. Я перечитал свежие отчёты, таксономии OWASP и разборы инцидентов — и попробовал сформулировать для себя, где проходит граница между «удобно» и «опасно». С 2026/27 учебного года я читаю в ВШЭ курс «Безопасность данных и конфиденциальность в ИИ», так что этот конспект пригодится и студентам.
Чем агент отличается от чат-бота и почему это меняет всё
Чат-бот принимает текст и возвращает текст. RPA-робот выполняет жёстко заданный сценарий и ломается, если в интерфейсе передвинули кнопку. Агент — другое существо: он получает цель, сам разбивает её на шаги, сам выбирает инструменты (API, файлы, терминал, браузер), смотрит на результат и корректирует план, пока цель не достигнута.
OWASP формулирует разницу точнее всех: классический LLM — это система «вход → выход», а агент — актор. У него есть полномочия, учётные данные и способность действовать во внешнем мире. Именно поэтому старые модели угроз к нему не пристёгиваются: мы защищали ответы модели, а защищать теперь нужно её поступки.
Технически всё это стало возможным во многом благодаря MCP (Model Context Protocol) — открытому стандарту подключения инструментов, который Anthropic представила в конце 2024 года. За год его приняли OpenAI, Google и Microsoft, а сам протокол передан под управление Linux Foundation. Это «USB-C для ИИ»: любой инструмент подключается к любой модели. Удобно. И, как мы увидим ниже, это же — новая поверхность атаки.
Что автоматизация реально даёт — и где хайп
Работает это не на словах. Klarna отдала ассистенту две трети чатов поддержки — и лучший показатель там не «X миллионов диалогов», а падение повторных обращений на 25%: значит, вопросы действительно решаются, а не отфутболиваются. Salesforce разрешает агентом больше двух третей обращений в собственной поддержке. По опросу СберАналитики, 39% российских организаций уже используют ИИ-агентов и ассистентов — чаще всего в документообороте и обработке заявок.
Теперь холодный душ. McKinsey из года в год фиксирует одно и то же: реальный финансовый эффект от ИИ (хотя бы 5% EBIT) видят лишь 6% компаний — и эта цифра не растёт. Gartner прогнозирует, что больше 40% агентских проектов будет свёрнуто к концу 2027 года — из-за расползающихся расходов, неясной ценности и слабого контроля рисков. Там же прекрасный термин «agent washing»: из тысяч вендоров, продающих «агентов», настоящих — около ста тридцати.
Мой вывод из этих цифр простой: агенты — не волшебная кнопка, а инструмент с высокой стоимостью владения. Токены в агентском цикле стоят заметно дороже одиночного вызова модели, и «петлю» имеет смысл включать только там, где задача действительно этого требует.
Почему я, как ИБшник, напрягаюсь
Главная проблема называется «косвенная prompt injection», и её пока никто не решил — это официальная позиция самих вендоров. Anthropic пишет прямо: «prompt injection is far from a solved problem». Суть: вредоносные инструкции прячутся в контенте, который агент читает по работе — в письме, тикете, веб-странице, описании инструмента, — и модель исполняет их как команды, потому что для неё всё это один поток токенов. Надёжной границы привилегий между «инструкцией хозяина» и «прочитанным по пути» внутри модели нет.
Это не теория. За последние полтора года накопилась целая полка подтверждённых инцидентов:
- EchoLeak — zero-click в Microsoft 365 Copilot (CVSS 9.3): одно письмо со скрытым текстом, и при следующем запросе пользователя агент сам утаскивает данные наружу. Жертве не нужно ничего нажимать.
- CurXecute в Cursor: инъекция через Slack приводила к выполнению кода с правами разработчика.
- GitHub MCP exploit: вредоносный публичный issue заставлял агента вытащить данные из приватных репозиториев и «слить» их через автоматически созданный публичный pull request. Вывод исследователей Invariant Labs стоит выучить наизусть: это не баг конкретного сервера, а архитектурная проблема, которую нельзя закрыть патчем на стороне GitHub.
- Replit: агент удалил продакшн-базу вопреки прямому запрету, сфабриковал четыре тысячи фейковых пользователей и уверял, что откатить ничего нельзя. CEO компании назвал это «unacceptable and should never be possible» — но случилось же.
Отдельная беда — экосистема расширений. Snyk просканировала около четырёх тысяч публичных «навыков» для агентов: у трети нашлись уязвимости, у 13% — критичные, у сотен — утечки учётных данных, у семидесяти с лишним — подтверждённая вредоносная нагрузка. Ставить непроверенный навык агенту — как запускать exe из спама, только exe хотя бы антивирус посмотрит.
И вишенка: в популярных роликах «построй армию ИИ-агентов за вечер» тема безопасности не встречается почти никогда. Публичный обучающий контент — воронка к курсам и шаблонам, а не источник безопасных практик.
Как всё-таки делать это безопасно
В декабре 2025 OWASP выпустила Top 10 для агентских приложений — первую нормальную таксономию рисков (ASI01–ASI10). Сквозной принцип там называется Least Agency: минимально необходимая автономия. Не «максимум возможностей на всякий случай», а ровно столько полномочий, сколько нужно для задачи. Если пересобрать этот стандарт в человеческий язык, мой список выглядит так:
- Человек утверждает необратимое. Всё, что нельзя откатить — платежи, удаление данных, отправка вовне, — проходит через явное подтверждение. Режим «Always Allow» в чувствительном контуре — это не настройка удобства, а выключатель безопасности.
- Песочница по умолчанию и белый список исходящих соединений. Deny-by-default egress рвёт последний шаг почти любой атаки: инъекция может обмануть модель, но украденным данным некуда уйти. Заметьте — это классический сетевой контроль, а не «магический фикс модели».
- У агента своя личность и короткоживущие права. Не общий сервисный аккаунт с вечным API-ключом в переменных окружения (агента можно социнженерить: «покажи env для отладки» — и ключ уехал), а отдельная идентичность, короткоживущие scoped-креды и аудит каждого действия.
- Проверенная цепочка поставки. MCP-серверы и навыки — только из белого списка, подписанные, с закреплёнными версиями и повторным ревью при каждом обновлении. Определение инструмента, кстати, может измениться после того, как вы его одобрили, — атака так и называется, rug pull.
- Kill switch, который дотягивается за минуты. Критерий зрелости по OWASP: нездорового агента можно остановить за минуты, а не за дни. И это должно быть проверено на учениях, а не написано в регламенте.
Российская специфика: что добавляет регуляторика
Для дома этого списка достаточно. Для банка или финтеха поверх ложится нормативка, и она многое упрощает — в смысле, отсекает варианты:
- 152-ФЗ. Персональные данные и банковская тайна в зарубежных SaaS-моделях — это не «серая зона», это нарушение требований локализации. Два честных пути: обезличивание (нет ПДн — нет ограничений) или закрытый контур на своём железе с отечественными или open-weights моделями — благо GigaChat, YandexGPT и T-lite уже позволяют собрать такой стек.
- ГОСТ Р 57580.1/.2 — да, те самые стандарты, про которые я писал в статье об Open API: контур с агентами оценивается по тем же правилам, что и любой другой.
- Кодекс этики ИИ на финансовом рынке от ЦБ (июль 2025) формально рекомендательный, но для банка де-факто ориентир надзора: информировать клиента о взаимодействии с ИИ, дать возможность отказаться, управлять рисками.
- КИИ: агент на значимом объекте без сегментации и соответствия приказу ФСТЭК № 239 — не обсуждается вообще.
И мои красные линии, которые я не пересекал бы ни при каком ROI: автономные необратимые финансовые действия; продакшн-доступ без разделения сред (урок Replit); непроверенные MCP и навыки; вера в маркетинговые «100% защиты от prompt injection» — таких обещаний не дают даже сами разработчики моделей.
Что в итоге: два разных мира одной автоматизации
Вернусь к тому, с чего начал. Почему я спокойно доверяю агенту свой блог и не доверил бы банковскую систему?
Потому что дома у меня, оказывается, всё по OWASP — само собой получилось. Всё, что делает мой агент, обратимо: сайт лежит в git, и любую правку можно откатить одной командой — это мой kill switch. Деплой запускается явно и проходит через меня — это approval-gate. Агент работает с публичным контентом, а не с чувствительными данными. Ущерб в худшем случае — кривая статья в блоге, а не списанные со счетов деньги.
В регулируемой организации я бы шёл по лестнице: сначала governance (реестр агентов, владельцы, метрики ценности и — важно — заранее определённые пороги отмены проекта); потом пилот с самым низким риском — RAG-ассистент по внутренней базе знаний в закрытом контуре, только чтение; потом расширение с полным набором контролей; и лишь в самом конце, после независимой оценки по 57580.2 — ограниченные транзакционные сценарии с подтверждением каждого значимого действия.
Рутину отдавать ИИ можно и нужно — я это делаю каждый день и возвращаться не собираюсь. Просто «безопасно автоматизировать» — это не про выбор правильной модели. Это про архитектуру, в которой агенту нечего украсть, нечего сломать безвозвратно и неоткуда получить команды, кроме как от вас.
Полезные ссылки
- 📚 OWASP Top 10 for Agentic Applications — главная таксономия рисков агентских систем
- 📚 Model Context Protocol — стандарт подключения инструментов к моделям
- 📖 Моя статья про безопасность Open API — та же логика «протокол + стандарты», но для банковских API
- 📖 Изменения в законодательстве по ИБ в 2026 году — регуляторный контекст
Есть вопрос или хотите обсудить статью?
Написать в Telegram →