Агенту можно разрешить отправлять письма — и запретить передавать то, что он знает

Агенту можно полностью разрешить отправлять электронные письма — и одновременно запретить отправлять материалы из его рабочего контекста. Это различие легко упустить: большинство механизмов контроля агентов начинают с разумного вопроса — может ли данная идентичность вызвать данный инструмент? Но разрешённое действие ещё не означает разрешённое раскрытие данных.

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

Автономной организации нужны оба ответа. Идентичность и авторизация определяют, может ли субъект выполнить действие. Контроль информационных потоков во время исполнения определяет, какое знание может пройти через это действие. Инструкции и prompt guardrails по-прежнему задают ожидаемое поведение, но они не являются границей принудительного контроля для данных, уже попавших в контекст агента.

Контроль доступа — не контроль потока

NIST проводит это различие прямо. В SP 800-171 Rev. 3 контроль доступа — это вопрос о том, кто может получить доступ к информации; контроль информационных потоков — о том, куда информация может передаваться. В NIST SP 800-53 контроль AC-4 требует обеспечивать утверждённые разрешения, управляющие потоками информации внутри системы и между системами, в том числе с помощью метаданных и политических фильтров.

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

“Авторизация отвечает: «Может ли этот субъект выполнить это действие?» Контроль информационных потоков отвечает: «Могут ли эти данные попасть туда через это действие?»

Это не терминологическая тонкость. От неё зависит место контроля. Среда исполнения должна проверять полезный груз вызова на sink, даже если сам вызов инструмента уже разрешён. Это отличается от авторизации в момент коммита: в момент, когда действие становится значимым, среда должна авторизовать его, а затем оценить происхождение и совместимость назначения данных, которые в это действие передаются.

Считайте артефакты workflow размеченным материалом

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

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

У теории контроля информационных потоков есть полезное правило для преобразований. Система Jif Корнеллского университета представляет политики конфиденциальности и целостности как метки, для которых определены порядок и операция объединения ограничений нескольких входов. В агентском workflow это означает: артефакт, составленный из клиентской записи, внутренней стратегической заметки и недоверенного найденного текста, должен консервативно нести ограничения, применимые ко всем этим входам.

• Закрытая клиентская запись остаётся закрытой, когда её цитируют, суммируют или включают в контекст модели.
• Ответ, построенный на данных двух тенантов, не становится молча допустимым ни для одного из их каналов.
• Аргумент инструмента, выведенный из недоверенного поиска, сохраняет сигнал о целостности и потому проходит более строгую проверку перед исполнением.
• Лог с чувствительным контекстом рассматривается как регулируемое назначение, а не как безобидный операционный след.

Для генерации модели нужен консервативный режим по умолчанию

Особую важность эта модель приобретает на границе LLM. Модель может выдать ответ под влиянием многих частей промпта, найденных документов и собственного процесса преобразования. Как правило, управляемая среда не может установить на уровне токенов, какой вход повлиял на какую фразу. И не должна делать вид, что может.

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

Практическое следствие архитектурно: минимизация контекста становится мерой контроля потока, а не только мерой стоимости и релевантности. Не помещайте чувствительный материал в контекст генерации, если предполагаемый путь результата не способен соблюдать его ограничения. Изолируйте контекст тенантов и домены памяти. Отделяйте недоверенные найденные инструкции от доверенных инструкций задачи. Проверяйте структурированные аргументы до исполнения инструментов. OWASP указывает на утечки через вызовы инструментов, цитаты, логи и конечные ответы; его рекомендации по защите от prompt injection описывают косвенные инъекции через страницы, документы, почту и другой контент, видимый инструментам. Метки не предотвратят такую инъекцию. Но они могут ограничить допустимые назначения после скомпрометированной обработки.

Снятие ограничений должно быть операцией, а не настроением модели

Организациям действительно необходимо снижать ограничения. Клиентское обновление статуса может быть создано на основе внутренней записи об инциденте. Партнёрский отчёт может содержать разрешённый агрегат закрытых данных. Но фраза «модель это суммировала» не является решением о рассекречивании.

Jif рассматривает declassification как намеренное ослабление ограничений потока и проверяет, есть ли у выполняющего код необходимые полномочия. Среда исполнения агентов может занять ту же архитектурную позицию, не утверждая, что Jif задаёт дизайн для ИИ-агентов. Редактирование, агрегация, проверка выпуска и раскрытие должны быть явными операциями уполномоченного компонента. У операции должны быть указанная цель, версия политики, доказательства применённого контроля и проверяемый результат.

Модель может помогать в таком процессе, но не становится полномочным субъектом только потому, что написала связный текст. Деклассификатор должен использовать детерминированные средства там, где это возможно, либо независимо валидируемые средства там, где требуется суждение. Если нужных доказательств нет, ограничение сохраняется. Именно это превращает «безопасное суммирование» в управляемый путь выпуска, а не в случайное поведение внутри непрозрачной генерации.

Проверяйте каждый sink по контракту назначения

Точкой принудительного контроля становится контракт назначения. До приёма материала sink сравнивает эффективную метку артефакта с тем, что этому назначению разрешено принимать. Внешнего адресата письма, конкретного клиентского тенанта, внутреннюю финансовую систему, общее хранилище памяти агентов и платформу наблюдаемости нельзя считать одним назначением только потому, что все они доступны по API.

Предлагаемый контракт AES runtime должен оценивать как минимум эффективную метку данных, назначение, получателя или тенанта, заявленную цель, инициирующего субъекта, версию политики workflow и доказательства разрешённого снятия ограничений. Эта точная схема — архитектурный вывод из моделей информационных потоков и рекомендаций по безопасности агентов, а не контракт, предписанный стандартом. Её ценность в конкретности отказа: не «агент повёл себя подозрительно», а «материал тенанта с ограниченным доступом не может попасть в межтенантный тикет по версии политики X без утверждённых доказательств выпуска».

1. Авторизуйте субъекта и действие с инструментом.
2. Распространяйте метки конфиденциальности и целостности через поиск, сборку контекста, генерацию, память и преобразования.
3. На каждом sink сопоставляйте эффективную метку с контрактом назначения.
4. Прежде чем снижать ограничение, требуйте явную, полномочную и подтверждённую операцию declassification.
5. Фиксируйте решение и его политический контекст вместе со значимым событием.

Граница, которая делает автономию управляемой

Это не обычная DLP-проверка после факта. Сложность агентных систем в непрерывном преобразовании данных: они попадают в контекст, синтезируются в ответ, сохраняются в памяти, передаются другому агенту и форматируются в полезный груз инструмента. Контроль должен следовать за этими производными артефактами от начала до конца.

Контроль информационных потоков не заменяет идентичность, инструменты с минимальными привилегиями, проверки авторизации или защиту от prompt injection. Он добавляет недостающий слой. Агент может иметь правильную идентичность, использовать одобренный инструмент и следовать корректному workflow — но всё равно предложить полезный груз, которому нельзя пересекать границу.

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

Источники

• NIST SP 800-171 Rev. 3: контроль информационных потоков и метки безопасности.
• NIST SP 800-53 Rev. 5.1: AC-4 Information Flow Enforcement.
• Документация Cornell Jif: децентрализованные метки, объединение ограничений и declassification.
• OWASP AI Agent Security Cheat Sheet.
• OWASP LLM Prompt Injection Prevention Cheat Sheet.