# Нулевые постоянные привилегии защищают доступ ИИ-агентов

> Нулевые постоянные привилегии ограничивают ИИ-агентов с помощью JIT-доступа, точных согласований и связного журнала действий.

В начале каждой задачи у ИИ-агента не должно быть доступа к продакшену, данным клиентов, репозиториям, платежам и внутреннему администрированию. Когда доступ нужен, сервис политик должен выдать узкие учетные данные для одного ограниченного действия, а затем дождаться окончания их срока. Так нулевые постоянные привилегии работают на практике. Это рабочая модель, а не новое название для регулярной смены постоянного API-ключа.

Сложнее всего не задать срок действия токена. Безопасная схема должна определить, что разрешено агенту, чьи полномочия он использует, когда действие должен подтвердить человек, что меняется между согласованием и выполнением и какие свидетельства сохранятся после. Я видел, как команды сосредотачивались на брокере учетных данных, оставляя эти решения неявными. В итоге у них появлялись краткосрочные учетные данные с правами на весь аккаунт, согласования в виде пустого чека и журналы, которые подтверждали существование токена, но не объясняли, что он изменил.

## Постоянный доступ превращает каждый промпт в решение о полномочиях

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

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

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

В NIST SP 800-207 сказано, что модель нулевого доверия не должна неявно доверять субъекту из-за сетевого расположения или принадлежности ресурса, а аутентификация и авторизация должны предшествовать сеансу работы с ресурсом. Этот принцип полезен, но агент требует более точного толкования: аутентификация подтверждает, какой процесс отправил запрос, а авторизация должна описывать, к какому результату может привести именно этот запуск. Если известный идентификатор агента считать достаточным основанием для доверия, вокруг сервисного аккаунта вновь возникнет статический периметр.

Вывод прямой. Если агент может проснуться в три часа ночи и без новых полномочий развернуть, удалить, перевести, пригласить или экспортировать что-либо, у него все еще есть постоянная привилегия. Ежечасная смена токена ничего не меняет, когда продление происходит автоматически и политика не задает нового вопроса.

## Определите единицу доступа до выбора брокера

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

Опишите разрешение в виде данных до обсуждения поставщиков. Этот упрощенный запрос достаточно конкретен для проверки политики:

```yaml
request_id: req_7f31
agent_id: release-agent-prod
task_id: change_1842
requested_action: deployment.promote
resources:
  service: checkout-api
  environment: production
constraints:
  artifact_digest: sha256:91c2...
  source_environment: staging
  max_executions: 1
requested_ttl_seconds: 600
```

Каждое поле перекрывает отдельный путь обхода. `agent_id` идентифицирует процесс, а `task_id` связывает доступ с бизнес-запросом. Поле действия не дает агенту общую роль для деплоя. Поля ресурсов закрывают доступ к другому сервису или окружению. Дайджест связывает полномочия с проверенным кодом, а `max_executions` запрещает повторно использовать разрешение после нужного развертывания.

Здесь важна разница между ролью и возможностью. Роль описывает длительное отношение, например оператора продакшена. Возможность разрешает одну операцию над одной целью при заданных условиях. Ее можно реализовать через облачную сессию, токен базы данных, подписанный запрос или API-вызов через брокера. Безопасность дают границы, а не формат токена.

Не пытайтесь с первого дня внедрить идеальную авторизацию на уровне каждой строки или команды во всех системах. Если это быстрее и проще проверить, поставьте узкий прокси перед грубым API. Например, агент вызывает `promote(artifact_digest, service)`, а более широкие учетные данные для деплоя остаются у прокси. Прокси проверяет согласованные дайджест и сервис, выполняет фиксированную последовательность и запрещает произвольные команды. Такая схема часто снижает риск сильнее, чем временная версия тех же учетных данных администратора.

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

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

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

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

## JIT-учетные данные должны быть узкими, короткими и одноразовыми

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

Обычный путь выпуска содержит шесть решений, даже если пользователь видит одну кнопку. Агент аутентифицируется с помощью идентификатора процесса. Он отправляет структурированный запрос на доступ. Политика проверяет агента, задачу, ресурс, действие, окружение и уровень риска. Сервис согласований получает решение человека, когда того требует политика. Брокер обменивает одобренный запрос на учетные данные целевой системы. Целевая система применяет ограничения и возвращает результат, который можно сопоставить с запросом.

OAuth 2.0 Token Exchange, RFC 8693, задает протокол HTTP и JSON для обмена одного токена безопасности на другой и поддерживает делегирование через токен исполнителя и утверждение JWT `act`. Так команды получают стандартные понятия субъекта и текущего исполнителя. Семантика RFC также предупреждает, что выдача себя за другого и делегирование различаются: если токен делает агента неотличимым от пользователя, расследование теряет границу между ними. Сохраняйте обе личности, если это позволяет целевая система.

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

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

Считайте продление новым решением об авторизации. Брокер должен подтвердить, что задача еще открыта, согласование не отозвано, ресурс и артефакт не изменились, а предыдущее разрешение не исчерпало лимит выполнений. Если при продлении проверяется только refresh-токен, JIT-выпуск превращается в постоянный доступ с дополнительными сетевыми вызовами.

## Согласование нужно проводить перед рискованным действием

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

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

Карточка согласования должна содержать исполнителя, задачу, цель, операцию, значимые аргументы, ожидаемый результат, срок окончания и стабильный дайджест предлагаемой нагрузки. Для конфигурации и кода покажите отличие от текущего состояния. Если изменился исходный артефакт, назначение, сумма, получатель или команда, отмените согласование. Интерфейс не должен спрашивать только `Разрешить агенту продолжить?`

Согласование и выполнение нужно связать криптографически или транзакционно. Практичная запись может содержать `approval_id`, `request_digest`, `approver_id`, `decision`, `decided_at` и `expires_at`. Брокер принимает ее только для совпадающего дайджеста запроса и записывает идентификатор согласования в выпущенное разрешение. Агент не сможет получить одобрение безопасного предварительного просмотра, а затем подменить нагрузку более рискованной.

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

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

## Полезный журнал аудита связывает намерение с результатом

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

Записывайте структурированные события на каждой границе. Следующий формат JSON Lines достаточно прост, чтобы внедрить его без покупки новой платформы журналирования:

```json
{"event":"access.decision","request_id":"req_7f31","task_id":"change_1842","agent_id":"release-agent-prod","action":"deployment.promote","resource":"checkout-api/production","request_digest":"sha256:4ab1...","decision":"allow","policy_version":"prod-agent-v12","approval_id":"apr_2901","occurred_at":"2026-08-09T14:03:11Z"}
{"event":"access.effect","request_id":"req_7f31","grant_id":"grt_8820","target_event_id":"deploy_6627","result":"succeeded","effect_digest":"sha256:9dd0...","occurred_at":"2026-08-09T14:06:42Z"}
```

`request_id` сопровождает попытку доступа, а `task_id` группирует более широкую задачу. `grant_id` идентифицирует выпущенные полномочия, не раскрывая секрет. `request_digest` подтверждает, что именно проверили политика и человек. По `target_event_id` расследующий находит авторитетное событие приложения. `effect_digest` фиксирует нормализованный результат, когда цель не предоставляет стабильный идентификатор события.

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

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

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

## Сбои накапливаются на стыках

Самый показательный сбой начинается с корректного запроса и заканчивается результатом, который никто не одобрял. Представьте, что агент релизов готовит версию A, вычисляет дайджест и получает согласование на деплой. До выполнения сборочный хук обновляет артефакт под тем же изменяемым тегом до версии B. Брокер выпускает десятиминутные учетные данные для деплоя в указанные сервис и окружение, но целевая система принимает любой артефакт. Агент развертывает B. Каждый компонент выполнил свои локальные правила, хотя система нарушила решение человека.

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

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

Повторное воспроизведение создает еще один стык. В интерфейсе согласование может быть одноразовым, но брокер будет многократно принимать ту же подписанную запись до истечения срока. Пусть брокер атомарно поглощает nonce при выпуске разрешения, а цель отклоняет второе выполнение, если операция поддерживает ключи идемпотентности. `max_executions: 1` выражает политику, но применять ее должен общий счетчик или гарантия целевой системы.

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

Повторы агента создают еще одну пограничную ошибку. Вызов инструмента может завершиться тайм-аутом после фиксации изменения целью, но до получения ответа агентом. Агент решит, что ничего не произошло, и запросит новое разрешение. Для подходящих операций требуйте ключ идемпотентности, полученный из задачи и предполагаемого результата. Если цель не умеет гарантировать идемпотентность, перед повтором инструмент должен запросить авторитетное состояние, а неоднозначные результаты с серьезными последствиями политика должна отправлять человеку. Слепой повтор здесь недопустим.

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

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

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

## Отзыв должен опередить следующий шаг агента

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

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

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

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

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

## Внедряйте систему, сокращая привилегии

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

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

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

Измеряйте то, что показывает остаточный риск: долю чувствительных действий с постоянными учетными данными, максимальный срок разрешения, наличие границ ресурса и действия, отмену согласований после изменения нагрузки, результаты без связанного запроса и время локализации при отзыве. Сам объем запросов ничего не говорит о безопасности. Снижение числа согласований полезно, если политика взяла на себя обычное чтение, и опасно, если широкая роль обошла брокера.

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

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

Во время Team & AI Audit я проверяю этот путь контроля вместе с производительностью разработки, поскольку добавление агентов без изменения схемы доступа позволяет небольшой команде быстрее проводить как правильные, так и ошибочные изменения. Практическая цель состоит в том, чтобы команда могла использовать Claude Code, Codex, MCP tools или многоагентные конвейеры, сохраняя полномочия в продакшене явными и проверяемыми.

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

## Нулевые постоянные привилегии меняют владельцев доступа

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

Интерфейс приложения должен выражать бизнес-смысл. `refund_order(order_id, amount, reason)` поддерживает более точную политику и согласование, чем `POST arbitrary URL`. `promote_artifact(digest, service, environment)` безопаснее учетных данных для командной оболочки. Специализированные действия требуют времени инженеров, но уменьшают неоднозначность промптов и упрощают локализацию сбоев.

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

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