CNCF: граница автономности агента — задача платформы, а не промпта

Что произошло

29 октября в блоге CNCF вышел пост двух field CTO — Уильяма Риццо и Франческо Бельтрамини — о «проблеме границы» в агентном ИИ. Их тезис: набор возможностей агента почти никогда не выбирают сознательно — инструмент из одного сценария остаётся доступным во всех, креденшел из демо доживает до прода. Инструкции это не чинят: вывод агента — распределение вероятностей, а не гарантия, и при конфликте между намерением (инструкцией) и возможностью (реальными правами инструментов) побеждает возможность, потому что исполняется именно она.

Авторы предлагают «безопасную операционную модель» — концентрические кольца наименьших привилегий. В центре — верифицируемая идентичность: каждому агенту и серверу инструментов выдаются короткоживущие аттестованные креденшелы вместо переносимых токенов. Кольцо 1, охват: service mesh разрешает подключения по этой идентичности, а новая связь появляется только через видимое и ревьюируемое изменение декларации. Кольцо 2, возможности: множество инструментов агента — декларативный объект: admission-политика проверяет попытку привязки, шлюз — каждый вызов; несанкционированный инструмент агент даже не видит. Краеугольный камень: идентичность агента лишена права менять объекты, определяющие его полномочия, — двигать границу можно только ревью изменений в версионируемой конфигурации. Кольцо 3, данные: слой данных авторизует доступ по той же идентичности.

Поверх колец — «детерминированный хребет»: регулируемый процесс, состояние, одобрения и журнал принадлежат детерминированной инфраструктуре, а агент выполняет осмысленную работу внутри и выдаёт предложение — черновик или PR, — которое проверяет человек и применяет конвейер. Пример авторов — выдача кредита: агент готовит рекомендацию, но не одобряет кредит и не двигает деньги. По оценке авторов, изобретать почти ничего не нужно: весь стек в cloud native уже есть, а новый слой тонкий — агентская идентичность и допустимые возможности как декларативные объекты плюс авторизация каждого вызова.

Почему это важно

Это программная позиция для этапа релиза: платформенная команда перестраивает конвейер под то, что агент — ещё один workload с неточным контуром управления. Выпуск через детерминированный хребет (агент предлагает, конвейер применяет, всё записано) даёт аудируемость как побочный продукт работы — прямой ответ на вопрос служб безопасности и регуляторов, в том числе в банках. И трезвый вывод: «подкрутить промпт» — не мера безопасности: граница, которая держится на инструкции агента, в критический момент как раз не удержит.

Что с этим делать

• Проверьте главный вопрос поста на себе: может ли сервисная учётка агента изменить собственные права или policy-объекты, которые её ограничивают.
• Переведите множество инструментов агента в декларативный объект и запретите привязку неотревьюенных инструментов на admission-уровне.
• Для чувствительных процессов оставьте агенту роль «предложить»: PR или черновик решения применяет конвейер после проверки человеком.