Десять принципов · принцип 07 из 10

Полномочия и безопасность

Принципы безопасности прошиты на уровне ДНК компании. Агентный цикл — двигатель, полномочия и границы — тормоза.

обновлено 8 августа 20268 мин чтения

P6 закрыл вопрос актуальности правил. P7 отвечает на следующий: какие именно действия агент совершает сам — и где нужен контроль?

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

Двигатель и тормоза

Полномочия и безопасность — это тормоза. Двигатель — агентный цикл (agentic loop): цикл проб и проверок, в котором агент автономно доводит задачу до целевого результата. Пробует, сверяет результат с критериями успеха, исправляется и повторяет, пока цель не достигнута. В топовых ассистентах это уже реализовано как режим goal.

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

Без цикла автономии нет доведения до результата. Без границ автономия становится источником инцидентов.

Три режима автономии

Для каждого класса действий:

  • 🟢 Авто — действие обратимо, риск низкий: обновить документ, создать черновик.
  • 🟡 Подтверждение — затрагивает внешние системы или необратимо: отправить письмо, открыть PR.
  • 🔴 Только человек — необратимо, финансово или публично: провести платёж, кадровое решение.

У среднего режима есть важное свойство: он разрушается объёмом. Пока подтверждений немного, человек читает, что одобряет. Когда поток становится постоянным, подтверждение вырождается в рефлекс — по наблюдениям Сбера, до 93% одобрений даются в среднем за секунду, то есть фактически без чтения.

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

Три механизма контроля

Как именно срабатывает проверка:

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

Самоконтроль. Встроен в инструкции самого агента: «уточни перед продолжением», «отдай на ревью суб-агенту». Команда auto_improve ждёт одобрения перед коммитом — это самоконтроль по инструкции.

Gates (ворота). Процесс останавливается до прохождения проверки перед вызовом инструмента. Например, система сверяется с матрицей полномочий агента. Четыре возможных исхода: разрешить разово, выдать постоянные права, остановить с ошибкой (fail-hard), перенаправить с обратной связью для поиска другого решения (fail-soft).

Разница между вторым и третьим механизмом принципиальная, и её стоит проговорить. Самоконтроль держится на добросовестности агента: правило передано ему текстом, и проверить, применил ли он его, снаружи нельзя. Gates исполняются независимо от поведения агента. Отсюда форма, в которой они должны жить, — политики как код (Policy-as-Code): правило, которое нельзя обойти, существует как исполняемая проверка в контуре, а не как документ, который агент «должен был прочитать». Разумная настройка по умолчанию — запрещено всё, что не разрешено явно.

Три типа контролёров

Механизм контроля — одно. Кто его исполняет — другое. Это два разных измерения, и проектировать их нужно отдельно.

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

Агент-ревьюер или оркестратор. Второй агент проверяет результат первого: анализирует PR, ищет ошибки и нарушения регламентов. Оркестратор принимает результат суб-агента и выбирает следующее действие. Применяется там, где нужна скорость и важно освободить людей.

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

Человек. Финальный контролёр там, где цена ошибки высока (P1), а также там, где решаются архитектурные вопросы, выставляются цели и определяются правила игры.

Анти-паттерн. Оставлять критичные контроли на уровне инструкции агента с широкой автономией. Галлюцинация модели или целенаправленная prompt-инъекция — почти гарантия инцидента.

Практика

  • В финансовой системе агент формирует счёт через API — выставляет его человек в личном кабинете банка.
  • В PM-системе команда /close-increment обновляет всё автоматически, но запускает её человек.
  • Почтовый MCP готовит черновик письма клиенту — отправляю сам.
  • В кейсе OpenAI агент эскалировал задачи, требующие суждения, а в остальных зонах действовал автономно в заданных границах.

Readiness перед сквозными процессами

Перед тем как отдавать агентам сквозной цикл в высокозависимом процессе, проверяются шесть пунктов:

  1. Идентичность и доступы — понятно, кто и как получает доступ к системам и данным.
  2. Entitlements — права на конкретные датасеты и подсистемы явно определены.
  3. Интеграции инструментов — всё нужное подключено и проверено в боевом режиме.
  4. Логирование — каждое действие агента оставляет след: вход, выход, решения, эскалации.
  5. Обработка исключений — агент знает, что делать, когда что-то идёт не так: fail-hard или fail-soft.
  6. Владелец — есть конкретный человек, отвечающий за контур и его результаты.

Если хотя бы один пункт не готов — возвращаемся на предыдущий уровень агентного трека.

Мой текущий вызов

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

Этот тезис сейчас звучит и за пределами методологии. Сбер в AI-Disrupt PDLC утверждает, что преимущество создаётся качеством среды исполнения агента, а не качеством модели, — и приводит оценку: около 98% инженерной ценности даёт детерминированная обвязка и около 2% сама модель. Вывод они делают стратегический: контур надо строить внутри, потому что отданный наружу harness уносит с собой компетенцию.

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

Там, где человек оркестрирует агентов, результаты у меня уже есть: часы сэкономленного времени, ×3 к скорости.

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

Все стремятся к высокой автономии с низкими ошибками и дешёвыми токенами. Никто пока до конца не знает, как. Это главная гонка — и я в ней.

Со стороны ценности

В чём выгода. Снимается тормоз «страшно доверить агенту». Явные режимы и понятный контролёр превращают расплывчатое опасение в управляемую границу: можно смело автономить там, где риск низкий, и держать руку там, где высокий.

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

Что легко переоценить. Что безопасность — это «дать поменьше прав». Слишком узкие границы убивают ценность так же, как слишком широкие убивают устойчивость. Вопрос не «сколько прав», а «где и кто проверяет».

Дёшево проверить. Возьмите три типовых действия агента и ответьте: каков режим, кто контролёр, что будет при ошибке.

Что дальше

Полномочия и обвязки агентов — это архитектура. Кто её проектирует? Об этом P8 «Каждый — архитектор».