Назад в блог

DLP для AI-агентов: как не дать промпту унести данные

Почему обычный DLP не видит утечки через AI и как AI DLP инспектирует промпты и ответы на HTTP-границе: allow, redact, route, block с аудитом по identity.

Иллюстрация к материалу: DLP для AI-агентов: как не дать промпту унести данные

Файловый DLP ловит утечки через файлы, почту и сетевые шары. AI создал новый канал — промпт. Сотрудник пастит клиентскую базу в чат-бота, агент пастит её же в вызов модели — и ни одного файла не появляется. По данным LayerX, 77% сотрудников, использующих AI, пастят данные в промпты, причём 82% — через личные неуправляемые аккаунты. Файловый DLP этого канала просто не видит.

Нужен AI DLP — инспекция промпта и ответа на границе, с привязкой к identity.

Промпт как новый канал утечки

Раньше утечка — это файл на флешке или письмо наружу. Теперь — текст в JSON-поле prompt внутри TLS-соединения к api.openai.com. Данные не лежат в файле, не идут как email, а летят как обычный API-вызов в легитимный SaaS. Традиционные слои — сеть, эндпоинт, почтовый шлюз — видят метаданные соединения (SNI, IP), но не тело промпта без MITM, а с MITM — ценой высокой операционной сложности.

При этом объём канала растёт быстрее контролей: промпты, вложения в чат, retrieval-контекст, ответы модели, tool-вызовы агентов — всё это несёт одни и те же регулируемые данные (PII, PHI, PCI, секреты), но в неструктурированном виде.

Почему файловый и сетевой DLP слеп к промпту

Две механические причины:

  • Тело промпта внутри TLS. Браузер открывает TLS к LLM-провайдеру, DLP на egress видит шифрованный поток, а не поле prompt. Без терминации TLS на инспектирующем слое содержимое невидимо.
  • Нет identity в запросе к модели. Запрос к LLM идёт с сервисным ключом приложения, а не с identity человека. Даже расшифровав тело, DLP не поймёт, кто за ним — без внешнего контекста IdP.

Поэтому инспекция должна сидеть не на файлах, а на HTTP-границе между аутентифицированным вызывающим (человек или агент) и LLM.

AI DLP: инспекция на HTTP-границе с identity

Правильное размещение — inline-слой, который терминирует TLS от вызывающего, аутентифицирует его через корпоративный IdP, классифицирует содержимое промпта детерминированными категориями (PII, PHI, секреты, клиентские поля) и принимает решение до того, как модель увидит промпт.

Типичный поток:

  1. Вызывающий шлёт промпт через шлюз;
  2. Шлюз аутентифицирует identity и классифицирует промпт;
  3. Политика (классификация + роль/группа/тенант) даёт решение;
  4. Шлюз логирует решение с identity, классификацией, версией политики, временем и подписью целостности — до ответа модели;
  5. Ответ модели инспектируется на обратном пути тем же набором правил.

Это единственное место, где в один момент есть и промпт, и верифицированная identity — то, что требуют EU AI Act ст. 12/19 (логи с identification of natural persons) и HIPAA audit controls.

Действия: allow, redact, route, block

AI DLP — не только «разрешить/запретить»:

  • Allow — низкорисковые обращения проходят без трений;
  • Redact / tokenize — чувствительные куски вырезаются или токенизируются (SSN → placeholder), санитизированный промпт идёт дальше, сотрудник продолжает работу;
  • Route — запрос с чувствительными данными уходит не в consumer-чат, а в управляемый Azure OpenAI / внутренний деплой;
  • Block — высокорисковые промпты отклоняются до модели.

Лучшая практика — начинать с monitor (detect-only), потом включать block на узкие категории. Сразу резать всё — получите обход через личные аккаунты.

Что логировать для EU AI Act и аудита

Каждое решение — запись с полями, которые попросит аудитор:

  • identity вызывающего (человек или агент + lineage);
  • классификация (какие категории сработали);
  • версия политики и решение;
  • timestamp и подпись целостности.

Без такой записи политика «запрещаем пастить клиентские данные в публичные боты» остаётся на бумаге. С записью — это evidence для ISO 42001 и AI RMF.

Где Codenik: AI DLP на пути к модели

Codenik — та самая HTTP-граница: терминирует вызов к модели, биндит identity через IdP, классифицирует промпт, применяет политику (allow/redact/route/block) и пишет identity-bound аудит до ответа модели.

Так DLP работает и для людей, и для агентов: агент наследует identity пользователя, его tool-вызовы инспектируются тем же слоем, а каждый промпт получает запись, пригодную для EU AI Act. Подробнее про классификацию данных — в статье «Какие данные отдавать агенту».

Короткий вывод

Файловый DLP не видит промпт-канал — утечка через AI идёт как обычный TLS-вызов без файла. AI DLP закрывает дыру инспекцией на HTTP-границе с identity: классифицирует промпт и ответ, применяет allow/redact/route/block и пишет аудит с identity.

Начните с monitor, потом включайте block — и держите inspection там, где есть и промпт, и кто его отправил.

Источники и дальнейшее чтение