Два агента — ещё не контроль двух лиц

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

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

Автономным организациям следует считать независимость согласований свойством среды исполнения, которое проверяется для точного бизнес-эффекта. Важен не вопрос «одобрили ли действие два поименованных агента?», а вопрос «получил ли этот эффект необходимые согласования от принципалов, достаточно разделённых для данного класса риска?». Так знакомый контроль становится архитектурным примитивом: кворумом согласования с учётом независимости.

Разделение обязанностей шире идентичности

NIST SP 800-53 AC-5 требует определить обязанности, нуждающиеся в разделении, и задать авторизации доступа, которые это разделение обеспечивают. В обсуждении контроля есть важный архитектурный тезис: нарушения разделения обязанностей могут охватывать разные системы и прикладные домены. Контроль нельзя оценить, рассматривая только изолированные идентичности в одном приложении.

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

Контроль двойной авторизации NIST AU-9(5) описывает одобрение двумя уполномоченными людьми определённых операций с аудитом и предлагает ротацию обязанностей для снижения риска сговора. Это полезный паттерн, но не действующее требование, по которому два ИИ-агента выполняют контроль двух лиц. Применение паттерна к смешанным человеческо-агентным организациям — архитектурное расширение. В нём нужно явно определить, что именно разделяется и зачем.

Согласование должно быть привязано к эффекту, а не к намерению

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

Такая привязка предотвращает повторное использование внешне действительного согласования после изменения самого действия. Если меняются получатель, сумма, охват, доказательства или управляющая политика, согласование должно устаревать. Защищённые ветки GitHub дают полезный прецедент: рецензии могут сбрасываться при изменении проверенного diff, а для последнего доступного для проверки push можно потребовать одобрение не от автора. Автономной среде нужна та же дисциплина для бизнес-эффектов, а не только для изменений исходного кода.

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

Согласование должно нести доказательства независимости

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

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

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

Кворум — это предикат, а не число голов

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

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

Это полезнее, чем присваивать каждому агенту абстрактный рейтинг независимости. Независимость зависит от контекста. Общий провайдер модели может быть допустим для обычного изменения расписания и недопустим для регулируемого перевода средств. И наоборот, разные провайдеры не доказывают независимость. Большое эмпирическое исследование более чем 350 языковых моделей выявило существенную корреляцию ошибок; вклад в неё вносили общие архитектуры и провайдеры, но разные провайдеры или архитектуры не гарантировали некоррелированные ошибки. Разнообразие моделей способно снизить часть общих отказов, но не устранить их.

Проектируйте против общих отказов — и поддерживайте это в работе

NIST SP 800-53 SC-29 формулирует ту же взвешенную мысль о технологическом разнообразии: оно может снижать общие отказы, но добавляет сложность и накладные расходы управления. Поэтому кворум с учётом независимости должен применяться избирательно. Требовать разные модели, команды, хранилища и инфраструктуру для каждого действия с низким риском — значит создавать стоимость и хрупкость без соразмерной пользы контроля. Классификация риска должна определять, какие коррелированные пути недопустимы.

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

Владение важно не меньше технологий. Руководства AWS по архитектуре безопасности рекомендуют распределять независимые контроли между централизованными командами, которые взаимно рецензируют политики друг друга. Вывод не в том, что конкретная оргсхема гарантирует безопасность. Организационные границы — часть дизайна контроля. Технически разнообразный парк агентов, администрируемый, направляемый промптами и корректируемый одной группой операторов, всё ещё даёт слабое разделение обязанностей.

Что должна решать управляемая среда исполнения

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

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