Безопасность AI-бота для бизнеса: доступы, данные и контроль действий
AI-бот может не только отвечать клиенту. Если он читает внутренние документы, ищет данные в CRM или вызывает инструменты, ошибка в ответе превращается в вопрос доступа, репутации, расходов или реального изменения в системе. Защита начинается не с «идеального промпта», а с границ: какие данные видит модель, что ей разрешено делать и кто проверяет результат.
В августе 2026 года OWASP опубликовала новую редакцию Top 10 для приложений на основе больших языковых моделей. Это полезная карта угроз, но не сертификат и не готовый чек-лист для конкретного продукта. Ниже — практический способ применить её к бизнес-процессу: от потока данных до прав агента и проверки перед запуском.
Где начинается риск AI-бота
Риск определяет не название технологии, а её место в процессе. Бот, который отвечает только по утверждённым сценариям, отличается от AI-ассистента с поиском по документам, а агент с правом менять записи в CRM требует ещё более строгих ограничений. Если сравниваете эти форматы, посмотрите, чем чат-бот отличается от AI-ассистента и агента.
Нарисуйте путь одного запроса: кто его отправляет, откуда система берёт контекст, какие компоненты его обрабатывают, куда может попасть ответ и какие действия запускаются. Отдельно отметьте внешние источники — письма, вложения, страницы и сообщения клиента — и внутренние системы: CRM, базу знаний, ERP и файловое хранилище. Неочевидные права часто возникают именно на переходах между ними.
Что изменилось в OWASP 2026
OWASP Top 10 for LLM Applications 2026 опубликован 3 августа 2026 года. OWASP описывает его как обновлённую карту рисков для приложений с LLM, основанную на анализе угроз и практик сообщества. Используйте список, чтобы не упустить классы проблем, а приоритеты определяйте по своим потокам данных, разрешениям и последствиям ошибки.
Для агентов важно и другое обновление: 1 сентября OWASP представила Agent Control Standard (ACS), посвящённый возможности видеть, ограничивать и проверять доступ и действия агента во время работы. Практический вывод для компании: агент должен быть наблюдаемым и управляемым в runtime, а не просто иметь ограничения в инструкции.
Пять зон контроля для бизнеса
1. Входные данные и prompt injection
Prompt injection — попытка изменить поведение модели через текст в запросе или источнике, который она читает. Инструкция может быть прямой («игнорируй предыдущие правила») или спрятанной в письме, документе или веб-странице. Граница доверия должна быть технической: содержимое источника передаётся как данные, не получает права менять системные правила, а команды из него не выполняются автоматически.
Разделяйте недоверенный текст, ограничивайте источники поиска, проверяйте ответы перед действием и тестируйте типовые сценарии атак. Одна защитная фраза в промпте не является достаточным барьером: OWASP рекомендует сочетать меры, включая ограничение поведения, валидацию вывода, минимальные привилегии, подтверждение человеком и тестирование.
2. Доступ к конфиденциальным данным
Модель может ответить только на основе данных, доступных ей через контекст, поиск или инструмент. Поэтому правило «не показывать лишнего» нужно реализовать до генерации ответа: проверять роль и права пользователя на уровне запроса к источнику, ограничивать поля и документы, а не просить модель самостоятельно решать, кому можно их раскрыть.
Проверьте также журналы, аналитику, передачу сторонним провайдерам и сроки хранения. Для чувствительного процесса зафиксируйте, какие данные вообще нужны, что маскируется, кто имеет доступ к логам и как удалять сведения по утверждённому процессу. Юридические основания и требования к персональным данным — отдельная тема; здесь речь о технических границах системы.
3. Права и инструменты агента
Если агент может создать сделку, изменить статус, отправить письмо или удалить запись, каждый инструмент становится частью поверхности атаки. Дайте ему узкий набор операций и минимально необходимые права. Например, поиск контактов не должен автоматически означать возможность выгрузить всю базу.
Разделите подготовку действия и его выполнение. Перед необратимым или финансово значимым изменением покажите человеку конкретные параметры для подтверждения. Проверяйте права на сервере при каждом вызове, а не только в интерфейсе или промпте. В контексте CRM определите, какие поля агент может читать и менять, а также как восстановить ошибочную операцию. Практику интеграций и обработки сбоев мы разобрали в материале о подключении чат-бота к CRM.
4. Вывод, действия и проверка человеком
Не считайте текст модели безопасным только потому, что он создан вашей системой. Перед показом, записью в CRM или передачей другому сервису проверьте формат и допустимые значения. Экранируйте вывод в соответствующем контексте, а запросы к базам строите параметризованно. Модель не должна самостоятельно формировать произвольные SQL-запросы или URL инструментов, если их можно заменить контролируемой схемой параметров.
Заранее определите, когда бот отвечает со ссылкой на источник, когда отказывается, а когда передаёт разговор человеку. Для важных процессов сохраняйте аудит: пользователь, источник контекста, вызванный инструмент, параметры, результат и факт подтверждения. Не записывайте в логи лишние секреты или полные персональные данные.
5. Зависимости, злоупотребления и расходы
У модели, библиотек, поискового индекса, коннекторов и внешних API есть собственные риски доступности и изменения версий. Ведите перечень зависимостей и ответственных, обновляйте компоненты, ограничивайте частоту запросов и бюджет. Задайте тайм-ауты, максимальную длину контекста и число шагов агента. Это помогает снизить вероятность зацикливания и локализовать последствия ошибки.
Контролируйте, кто добавляет или меняет документы базы знаний, как они индексируются и когда удаляются старые копии. Изменения источников должны отслеживаться, а восстановление — быть возможным. Измеряйте не только цену одного запроса, но и расходы на повторы, поиск, внешние инструменты, мониторинг и ручную обработку исключений.
Как ограничить агента, работающего с системами
До подключения инструментов составьте таблицу разрешений:
| Операция | Разрешение | Контроль |
|---|---|---|
| Найти клиента по согласованным полям | Чтение ограниченных полей | Проверка роли и журнал запроса |
| Подготовить новую сделку | Черновик без записи | Человек проверяет поля и источник |
| Создать или изменить сделку | Точечное действие через серверный API | Повторная проверка прав и аудит |
| Удалить запись или изменить финансовые условия | По умолчанию запрещено | Отдельное подтверждение уполномоченного человека |
Это пример структуры, а не универсальная схема доступа. Сверьте её с реальными ролями и API. Если задача решается чтением и подготовкой черновика, не давайте право записи «на всякий случай». Для каждого разрешения укажите владельца, причину, срок пересмотра и аварийный способ отзыва.
Практический план проверки перед запуском
- Опишите сценарий и границы. Перечислите пользователей, данные, системы, инструменты и результат, который считается успешным.
- Нарисуйте поток данных. Отметьте внешний и внутренний контекст, места хранения, журналы и передачу провайдерам.
- Назначьте разрешения. Для каждого инструмента укажите чтение или запись, конкретные поля, условия подтверждения и ответственного.
- Проверьте отказы и атаки. Тестируйте прямые и косвенные инструкции, доступ между ролями, некорректный вывод, дубли запросов, недоступность API и превышение лимитов. Записывайте ожидаемое и фактическое поведение; случайное число тестов не доказывает безопасность.
- Включите наблюдаемость и восстановление. Проверьте журналы, оповещения, отключение инструмента, отзыв ключей и процедуру возврата данных в корректное состояние.
- Запускайте с ограничениями и пересматривайте доступы. Начните с одного сценария или группы пользователей, определите метрики ошибок и инцидентов, проверяйте права после изменений процесса.
Безопасность не заканчивается разовым тестом перед релизом. Новый источник данных, модель, коннектор или инструмент меняет границы доверия и должен запускать повторную проверку затронутого пути.
Вывод
Надёжность AI-бота для бизнеса зависит от контролируемого доступа к данным, узких прав инструментов, проверки вывода и понятного человеческого контроля. Начните с карты одного реального сценария, а затем проверьте каждый переход между пользователем, моделью, источниками и бизнес-системами. OWASP помогает увидеть классы рисков; конкретная защита должна соответствовать вашей архитектуре и цене ошибки.
Часто задаваемые вопросы
Да, атаки могут пытаться изменить поведение модели через прямой запрос или содержимое источника, который она читает. Защита не должна опираться только на системный промпт: разделяйте инструкции и данные, ограничивайте права, проверяйте вывод и требуйте подтверждение для критических действий.
Нет одной настройки, которая гарантирует устранение риска. Снижайте возможный ущерб с помощью изоляции недоверенного контента, контроля инструментов, серверной авторизации, ограничения данных и повторных тестов после изменений.
Передавайте модели только необходимые сведения, проверяйте права пользователя до поиска, ограничивайте поля и документы и отдельно управляйте журналами и сроками хранения. Не поручайте модели самостоятельно решать, кому доступна запись.
Только необходимые для конкретного сценария. Начинайте с минимального чтения или подготовки черновика; запись, массовые изменения и удаление отделяйте и защищайте подтверждением и журналом.
Это редакция OWASP, опубликованная 3 августа 2026 года, которая обновляет карту рисков приложений на базе LLM. Используйте её как основу анализа, а не как сертификацию или замену проверке конкретной системы.
Нет. Список помогает структурировать угрозы, но не знает ваши роли, источники данных, интеграции и цену ошибки. Превратите релевантные риски в конкретные контроли и проверьте их в вашей архитектуре.
Источники
- OWASP GenAI Security Project: OWASP Top 10 for LLM Applications 2026 — опубликовано 3 августа 2026 года.
- OWASP: презентация Top 10 2026 и Agent Control Standard — 1 сентября 2026 года.
- OWASP GenAI: Prompt Injection — описание угрозы и мер снижения риска.
- OWASP GenAI: Agent Control Standard — стандарт контроля и наблюдаемости агентов.
Обсудите безопасность вашего AI-бота со специалистом
За 15 минут уточним, к каким данным и системам имеет доступ ваш бот и с чего начать проверку.
Проверим доступы
вашего AI-бота.
Обсудим данные, системы и действия.
Определим, с чего начать проверку.
