Проще говоря, sensitive data disclosure - это ситуация, когда AI-агент, чат-бот, лог, интеграция или человек раскрывает лишнее. Например, агент показывает клиенту данные другого клиента, отправляет в модель секретный ключ, выводит внутренний системный промпт или сохраняет персональные данные в открытый лог.
В AI-системах риск выше, потому что данные проходят через промпты, контекст, память, tool calling, логи, трассировки, RAG, документы и внешние API. Ошибка может появиться не только в ответе пользователю, но и в промежуточном вызове инструмента, сохраненном trace или файле для отладки.
Чувствительные данные бывают разными: PII, платежные данные, документы, коммерческие условия, пароли, токены, ключи API, внутренние регламенты, персональные оценки сотрудников, медицинские данные, юридические материалы и любые сведения, которые нельзя раскрывать без права доступа.
AI-агент должен работать по принципу минимально нужного доступа. Ему не нужно видеть всю CRM, все документы или все поля профиля, если для ответа достаточно статуса заказа или короткой выжимки. Чем меньше лишних данных попадает в контекст, тем ниже риск раскрытия.
Защита обычно строится слоями: ACL и роли, маскирование данных, redaction перед отправкой в модель, allowlist действий, guardrails, запрет на вывод секретов, изоляция сессий, безопасные логи, audit log и ручное подтверждение для рискованных действий.
Типичная ошибка - считать, что проблема только в финальном ответе модели. На практике sensitive data disclosure часто происходит в логах, debug-трассировках, вложениях, экспортированных CSV, webhook payload, скриншотах или памяти агента.
В production важно заранее определить классы данных, правила доступа, где данные можно использовать, что нужно маскировать, что запрещено отправлять во внешние API и кто отвечает за инцидент. Для спорных случаев полезны source verification, approval workflow и отдельный threat model.
Примеры
- AI-агент поддержки по ошибке показывает одному клиенту номер заказа и адрес другого клиента.
- Системный промпт с внутренними правилами попадает в ответ пользователю после prompt injection.
- API key сохраняется в trace и становится доступен сотрудникам, которым он не нужен.
- RAG-поиск возвращает договор с коммерческими условиями клиенту без права доступа.
- В логах чат-бота остаются телефоны, email и паспортные данные без маскирования.
Где используется
- проектирование безопасных AI-агентов
- проверка промптов на утечки
- маскирование персональных данных
- защита системных промптов и API-ключей
- контроль доступа к CRM и документам
- безопасное логирование и tracing
- guardrails для ответов модели
- аудит RAG и поиска по документам
- обработка инцидентов безопасности данных
Связанные термины
Частые вопросы
Что такое sensitive data disclosure простыми словами?
Это раскрытие данных, которые нельзя показывать: персональных сведений, секретов, документов, токенов, коммерческой информации или внутренних инструкций.
Почему это особенно важно для AI-агентов?
Агенты работают с контекстом, памятью, инструментами, логами и внешними API. Данные могут утечь не только в ответе, но и на промежуточных шагах.
Какие данные считаются чувствительными?
PII, телефоны, email, адреса, платежные данные, договоры, коммерческие условия, API-ключи, пароли, системные промпты, медицинские и юридические сведения.
Как снизить риск sensitive data disclosure?
Ограничить доступ, маскировать данные, отправлять модели только нужный минимум, проверять права, включить guardrails, безопасные логи и approval для рискованных действий.
Что логировать при риске раскрытия данных?
Кто запросил данные, какой объект затронут, какие поля использовались, куда они отправлялись, какие правила сработали, решение системы и ссылку на audit log.
