Безопасность

Утечка чувствительной информации — мифы и реальные риски

Вопросы участников:

Утечка бизнес чувствительной информации при использовании ai какие мифы и реальные риски

Разложим страхи на две стопки: народные мифы и то, что действительно ломается.

Миф про обучение на ваших данных. Самый частый страх — мои промпты дообучат модель, и она выдаст мои секреты постороннему. Для коммерческого доступа это в общем случае неверно. OpenAI прямо пишет, что по умолчанию входы и выходы из API и корпоративных планов не используются для обучения моделей. У Anthropic та же позиция для коммерческих продуктов и API: по умолчанию ваши данные не идут в обучение. То есть сам по себе вызов API не кормит следующую версию модели вашим кодом.

Реальный рычаг — не обучение, а хранение. Провайдер какое-то время держит запросы для мониторинга злоупотреблений. У OpenAI это по умолчанию до 30 дней для большинства эндпоинтов, а для квалифицированных организаций есть режимы Zero Data Retention и Modified Abuse Monitoring плюс шифрование своими ключами (EKM). У Anthropic есть отдельное соглашение о нулевом хранении (ZDR) и HIPAA-режим с подписанным BAA. Практический вывод: не спорьте о мифах, а прочитайте в своём тарифе три вещи — используются ли данные для обучения, сколько живут абьюз-логи и доступен ли вам ZDR.

Что действительно течёт. OWASP в Top 10 для LLM-приложений 2025 выносит утечку чувствительных данных (LLM02) отдельным пунктом: модель может отдать в ответе персональные данные, финансовую информацию, секреты и куски проприетарного кода — не через обучение, а прямо в рамках сессии, через свой контекст и подключённые источники. Рядом стоит инъекция промпта (LLM01), и это главный реальный канал утечки. Классическая работа Грешейка и коллег про непрямую инъекцию промпта показала: когда в контекст попадает внешний недоверенный текст (страница, письмо, тикет), граница между данными и инструкциями стирается, и злоумышленник может удалённо заставить модель воровать данные. Для агентов это уже измеримо: в исследовании про утечку персональных данных tool-агентами простые инъекции дают среднюю долю успешных атак около 15–20%, и ни один встроенный защитный механизм бенчмарка AgentDojo не блокирует утечку полностью.

Что делать на практике:

Разделяйте контуры данных. Секреты, PII и коммерческую тайну не кладите в промпт и в system prompt. OWASP отдельным пунктом (LLM07) напоминает: system prompt — не место для ключей и паролей, его легко вытащить инъекцией.
Ограничивайте, что видит модель. Принцип наименьших привилегий на источники: агент дотягивается только до тех документов и систем, которые нужны задаче, а не до всего хранилища.
Редактируйте на входе и выходе. Маскирование и токенизация PII до отправки в модель и валидация ответа перед тем, как он уйдёт в другую систему.
Считайте недоверенным любой внешний текст. Письмо, веб-страница, тикет, содержимое репозитория — это данные, а не команды, и модель нельзя пускать по ним в действия без проверки.

Что пойдёт не так: если верить, что раз данные не идут в обучение, то утечки нет, вы пропустите настоящий вектор — инъекцию и переизбыток доступов у агента. Течёт не через обучение, а через контекст и инструменты.

Ссылки

Изолированная безопасная среда для разработки с ИИ

Вопросы участников:

Как создать изолированную и безопасную среду для AI, которая позволит комфортно заниматься разработкой и не переживать о последствиях

Ключ к спокойствию — развести две вещи, которые часто путают: права (разрешить ли действие) и изоляцию (что действие сможет достать, если уже запустилось). Комфортная автономная работа получается, когда вы ослабляете первое, но жёстко держите второе. Тогда даже если агент что-то натворит или наткнётся на враждебный контент, радиус поражения ограничен коробкой.

Слои изоляции — от лёгкого к тяжёлому. На примере Claude Code, где эти уровни описаны явно:

Sandbox для Bash на уровне ОС. Встроенный механизм ограничивает файловую систему и сеть каждой shell-команды средствами ОС — Seatbelt на macOS, bubblewrap на Linux и WSL2. По умолчанию запись разрешена только в рабочую директорию, а на новый сетевой домен спрашивается подтверждение. Хорош, чтобы меньше кликать по подтверждениям на своей машине, но ограничивает только Bash, не файловые инструменты и MCP-серверы.
Sandbox runtime на весь процесс. Пакет @anthropic-ai/sandbox-runtime заворачивает в ту же изоляцию весь процесс, включая файловые инструменты, хуки и MCP-серверы. По умолчанию запрещает всю запись и сеть — домены и пути открываются явным списком.
Dev container (Docker). Полноценная среда разработки в контейнере: команды исполняются внутри, а правки файлов проекта видны в вашем локальном репозитории. Референсный контейнер идёт со скриптом init-firewall.sh, который по умолчанию блокирует весь исходящий трафик, кроме нужных доменов.
Виртуальная машина или облачная песочница — для совсем недоверенного кода, когда нужна изоляция всей ОС.

Практическая сборка devcontainer. Готовый шаблон от Trail of Bits (claude-code-devcontainer, около 900 звёзд) собран именно под запуск агента в режиме bypassPermissions без страха: он даёт файловую изоляцию, так что агент может свободно писать код, а радиус поражения ограничен /workspace. Важные детали конфигурации, которые делают среду по-настоящему безопасной:

Запускать не под root и запретить обход прав снаружи контейнера: permissions.disableBypassPermissionsMode в managed-settings, которые имеют высший приоритет и которые инженер не переопределит из репозитория.
Не монтировать хостовые секреты. Не пробрасывайте ~/.ssh, облачные креды и большие директории вроде $HOME — всё смонтированное пишется изнутри контейнера и рушит изоляцию. SSH-агент можно пробросить сокетом: приватные ключи остаются на хосте.
Резать исходящую сеть по allowlist. Это не украшение, а главная защита от кражи данных.

Почему сеть важнее всего: исследование Silent Egress показало, что скрытая инъекция может заставить агента тихо слить рабочий контекст исходящими запросами, причём 95% успешных атак не ловятся проверками на выходе, а дробление данных по нескольким запросам обходит простые DLP-фильтры. Вывод авторов прямой: сетевой egress надо считать защитной мерой первого класса, а контроль на уровне сети (allowlist доменов, анализ цепочек редиректов) работает надёжнее, чем фильтры на уровне промпта.

Что пойдёт не так: самая частая ошибка — включить --dangerously-skip-permissions на живом хосте ради удобства. Тогда единственной защитой остаётся изоляция, которой нет: агент дотянется до ваших ключей и всей сети. Второй частый провал — файловая изоляция есть, а сеть открыта настежь; тогда украсть данные всё ещё можно. Обе границы нужны вместе.

Ссылки

Встраивание ИИ в корпоративный контур безопасности

Вопросы участников:

Непонимание как его аккуратно встроить в работу учитывая контур безопасности.

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

Три режима развёртывания под разный уровень чувствительности:

Прямой API провайдера (OpenAI, Anthropic и др.) — быстро и дёшево, данные проходят через инфраструктуру вендора. Подходит для общей, не самой чувствительной работы при заключённом корпоративном договоре с отключённым обучением и настроенным хранением.
Управляемое облако (AWS Bedrock, Azure OpenAI, Google Vertex AI) — те же передовые модели, но внутри вашего облачного периметра: приватные эндпоинты, интеграция с VPC, управление доступом через корпо- ративный IAM, аудит в вашей учётке. Для команд, у которых облако уже прошло внутренний комплаенс, это обычно самый прагматичный старт.
Self-hosted open-weight-модель — когда данные по регуляторике не имеют права покидать сеть. Полный контроль над версией и данными ценой GPU, MLOps и ответственности за безопасность самой модели (включая риск вредоносных весов и отсутствие вендорских фильтров).

Где ставить управление. Ключевая мысль зрелых внедрений: неважно, снаружи модель или внутри, важно, чтобы каждый запрос проходил через ваш шлюз политик до того, как данные уйдут наружу. Практически это гибридный AI-шлюз, который классифицирует запрос и маршрутизирует его: обезличенные задачи — в дешёвый внешний API, а всё, где DLP-сканер видит PII, финансовые данные или внутренние имена проектов, — во внутреннюю модель. Тот же шлюз редактирует PII до отправки, валидирует вывод и пишет аудит-лог в ваш SIEM.

Опереться на фреймворки, а не изобретать. Здесь есть готовые опорные документы:

NIST AI RMF: профиль Generative AI (AI 600-1) — функции Govern / Map / Measure / Manage: инвентаризация ИИ-систем, отслеживание происхождения данных, планы реагирования на инциденты в том числе для стороннего ИИ, безопасный вывод систем из эксплуатации без утечки.
NIST SSDF для генеративного ИИ (SP 800-218A) — расширение практик безопасной разработки: наименьшие привилегии к моделям и весам, защищённое хранение всех элементов модели.
OWASP Top 10 для LLM — как чек-лист рисков (инъекция промпта, утечка данных, небезопасная обработка вывода) для ревью каждой ИИ-фичи.

Что пойдёт не так: главный практический риск — не хакер, а теневой ИИ: сотрудники сами подключают чувствительные данные к публичным сервисам мимо ИБ. Если запретить всё, теневой ИИ разрастётся; поэтому дайте одобренный безопасный путь (управляемое облако или внутренний шлюз) удобнее, чем обход. Второй провал — завести API напрямую из приложения в обход шлюза: тогда ни одна политика не срабатывает, аудит-лог не пишется, а данные уходят за периметр без всякого контроля.