Утечка — это ошибка потока данных
Когда агент публикует артефакты, которые были предоставлены в качестве входных данных, сбой заключается не в том, что модель научилась допускать утечки. А в том, что в системе не было механизма отличить входные данные от выходных или потребовать явного решения об экспорте, прежде чем контент пересечёт эту границу. Модель делала то, что делают модели: генерировала текст или выбирала медиа из своего контекста. Дефект в том, что конвейер по умолчанию считал сгенерированный вывод безопасным и не отслеживал заражение данных, которые в него поступали.
Это различие важно, потому что оно меняет способ исправления. Если проблему формулировать как сбой выравнивания, команды прибегают к поведенческим вмешательствам: инструкциям в промпте, обучению отказу, классификаторам вывода. Они полезны для некоторых классов вреда, но это не тот уровень для отслеживания происхождения. Они проверяют поведение модели, а не путь данных. Модель может быть идеально выровнена и всё равно отправить изображение пользователя, если конвейер прикрепляет это изображение к исходящему сообщению, ни у кого не спрашивая.
Сообщения об агентах, публикующих изображения пользователей без ведома лаборатории, иллюстрируют этот паттерн: изображения были входными данными для рабочего процесса, и сбой в том, что они стали выходными данными без принятия решения об экспорте где-либо. Это разрешимая ошибка потока данных. Её можно исправить с помощью тегов, правил распространения и шлюзов исходящего трафика. Объяснения в стиле выравнивания затуманивают эту разрешимость.
Отслеживание заражения для агентных конвейеров
Отслеживание заражения — хорошо понятная идея из операционных систем и безопасных информационных потоков: помечайте данные при входе в систему, распространяйте метку через каждое преобразование и блокируйте операции, которые отправили бы помеченные данные в недоверенный приёмник без явного разрешения. Агентным конвейерам нужна та же дисциплина, адаптированная к тексту, изображениям, эмбеддингам и вызовам инструментов.
Тегирование при входе
Каждый артефакт, попадающий в окно контекста, должен нести как минимум два поля:
- класс чувствительности (например: публичный, внутренний, конфиденциальный, персональные данные)
- идентификатор происхождения (какой пользователь, какая загрузка, какой коннектор, какое попадание при поиске)
Эти теги должны прикрепляться на границе, где артефакт входит в запуск, а не выводиться позже из содержимого. Вывод из содержимого подвержен потерям и может быть обманут. Дескриптор файла, строка базы данных или событие загрузки знают, откуда пришли данные; суммаризатор — нет.
Распространение через преобразование
Теги должны выживать при суммаризации, эмбеддинге, повторной генерации и перефразировании. Именно здесь большинство реализаций терпят неудачу, потому что преобразования, делающие агентов полезными, — это также преобразования, которые удаляют метаданные. Конкретный механизм: представляйте контекст как список типизированных спанов, где каждый спан несёт ссылку на текст или медиа плюс набор происхождения. Когда модель создаёт резюме, происхождение резюме — это объединение происхождения спанов, на которых оно было обусловлено. Когда резюме встраивается, эмбеддинг наследует это объединение. Когда эмбеддинг извлекается и используется для генерации нового абзаца, абзац наследует его снова.
Это правило объединения консервативно: оно чрезмерно заражает. Если публичный документ и конфиденциальный документ оба находятся в контексте, сгенерированный вывод является конфиденциальным. Это правильное значение по умолчанию для безопасности, но это реальный компромисс. Чрезмерное заражение снижает полезность агента, потому что выводы, которые могли бы быть выпущены, блокируются или требуют проверки. Команды могут смягчить это с помощью промптинга с учётом происхождения (обусловливание только на спанах, необходимых для задачи) и с помощью правил рассекречивания, которые являются явными и логируемыми, а не неявными в суждении модели.
Шлюз исходящего трафика
Каждый путь, который может выдать контент за пределы запуска, должен учитывать происхождение выдаваемого контента. Пути исходящего трафика включают:
- сообщения во внешние каналы
- запись файлов в общее хранилище
- вызовы инструментов, которые отправляют данные в сторонние API
- отрендеренные страницы или вложения
- логи и трассировки, которые отправляются во внешние сервисы наблюдаемости
Если контент заражён выше допустимой чувствительности пункта назначения, исходящий трафик блокируется, если только нет решения о выпуске. Решение о выпуске должно указывать артефакт, пункт назначения, политику, которая его разрешила, и субъекта, который его авторизовал. Оно должно быть записано в хранилище, которое можно запросить позже.
Минимальную точку принуждения можно выразить как проверку политики:
def can_export(artefact, destination):
if destination.allowed_sensitivity < artefact.sensitivity:
return require_release(artefact, destination)
return True
Важное свойство в том, что эта проверка выполняется на пути исходящего трафика, а не внутри модели. Модели нельзя доверять запоминание того, какие входные данные были чувствительн
Рассмотрение поиска как только для чтения, а генерации как безопасной
Распространённая ментальная модель разделяет конвейер на фазу чтения (поиск, вызовы инструментов) и фазу записи (генерация, публикация). Фаза чтения считается безопасной, потому что она только читает. Фаза записи считается безопасной, потому что она только записывает новый контент. Эти две соединяются окном контекста, и именно в этом соединении теряется происхождение. Если поиск не тегирует, а генерация не распространяет, то фаза записи не может знать, что её вывод происходит из приватной загрузки пользователя.
Исправление — рассматривать окно контекста как структуру данных с происхождением, а не как непрозрачную строку. Это означает, что агентный фреймворк, а не только приложение, должен нести теги через свои типы сообщений.
Полагаться на фильтры вывода, которые проверяют текст, но не прикреплённые медиа
Фильтры вывода обычно сканируют сгенерированный текст на паттерны: PII, секреты, запрещённые строки. Они редко проверяют прикреплённые изображения, аудио или файлы. Агент, который прикрепляет изображение пользователя к сообщению, может пройти все текстовые фильтры, одновременно допустив утечку изображения. Фильтр видит безобидную подпись; вложение не проверяется.
Исходящий трафик медиа нуждается в тех же проверках происхождения, что и текст. Изображение, которое вошло в запуск как загрузка пользователя, должно нести тег чувствительности и идентификатор происхождения, и любая попытка прикрепить его к исходящему сообщению должна учитывать этот тег. Классификаторы медиа на основе содержимого могут дополнять это, но они не заменяют происхождение, потому что они не могут знать, согласился ли пользователь на этот конкретный экспорт.
Минимальный контракт
Работоспособный контракт для агентных запусков достаточно мал, чтобы изложить его в нескольких строках:
- Ни один артефакт не покидает запуск без записи о происхождении, указывающей его источник и политику, которая разрешила выпуск.
- Записи о происхождении можно запросить после факта, а не просто записать в приёмник логов.
Запрашиваемость — это та часть, которую команды пропускают. Запись происхождения в лог только для добавления необходима, но недостаточна. Когда происходит инцидент, вопрос не только «что произошло», но и «какие артефакты из каких источников достигли каких пунктов назначения при каких политиках». Это запрос, и на него должно быть возможно ответить без реконструкции запуска из сырых логов. Хранилище происхождения с полями для идентификатора артефакта, происхождения, чувствительности, истории преобразований, пункта назначения, политики и авторизующего субъекта делает обзор инцидента поиском, а не археологическим проектом.
Компромисс — операционные затраты и трение. Отслеживание происхождения добавляет метаданные к каждому спану контекста, что увеличивает использование токенов и инженерную сложность. Шлюзы исходящего трафика добавляют задержку и могут блокировать законные рабочие процессы. Рабочие процессы рассекречивания добавляют проверку человеком. Эти затраты реальны, и команды должны ограничить классы чувствительности и пути исходящего трафика, которые они применяют, а не пытаться установить полный контроль информационных потоков с первого дня. Узкий, применяемый контракт на важных путях ценнее широкого, но неприменяемого.
Альтернатива — продолжать рассматривать утечки как сбои выравнивания и продолжать отвечать изменениями промптов и фильтрами вывода, которые не видят историю данных. Такой подход будет продолжать упускать класс сбоев, где модель вообще не ведёт себя неправильно: она просто выдаёт то, что конвейер поставил перед ней, потому что ничто в конвейере не знало разницы между входными данными и экспортом.