Агент комментирует merge request в GitLab, двигает задачи в ClickUp, ищет данные в CRM. Каждый из этих вызовов кто-то авторизует - и здесь команды обычно выбирают один из двух неудачных вариантов: дать агенту общий сервисный аккаунт или пустить его под учёткой сотрудника. Первый делает невозможным аудит, второй смешивает действия человека и машины.
Проблема не нова - с ней десятилетиями живут сервисные аккаунты. Новое в масштабе: non-human identities на предприятии уже outnumber людей примерно пятьдесят к одному, а агент - это NHI, которая сама принимает решения о том, какие вызовы делать. Неудивительно, что identity и авторизация агентов стали центральной темой инициативы NIST по стандартам AI-агентов, запущенной в 2026 году.
Разберём, почему привычные схемы не работают для агентов и как строить права доступа, которые переживут рост с одного пилота до десятков агентных сценариев.
Почему нельзя просто дать агенту аккаунт
Общий сервисный аккаунт. Все агенты ходят в системы под одним токеном. Пока всё работает - удобно. Когда происходит инцидент, ответить на вопрос «какой именно агент и по чьей задаче удалил записи» невозможно: в логах системы виден один субъект. Отзыв скомпрометированного токена означает остановку всех агентов сразу.
Наследование прав сотрудника. Агент разработчика получает его же доступ ко всем репозиториям, стендам и продакшен-логам. Разница в том, что человек применяет права осмотрительно, а агент действует вероятностно: достаточно одной ошибки в контексте - например, prompt injection через прочитанный issue, - и весь доступ сотрудника работает против компании.
«Вечный» персональный токен в конфиге. Токен живёт месяцами, лежит рядом с runtime агента и никогда не истекает по завершении задачи. Это классическая проблема credential sprawl из OWASP Top 10 по non-human identities - только теперь у каждого утечётшего токена есть собственный LLM, который может его использовать.
Все три схемы объединяет одно: права выдаются статично и целиком, а используются - фрагментарно и ситуативно.
Три модели субъекта доступа
| Модель | Как выглядит | Когда допустима |
|---|---|---|
| Общий сервисный токен | Один аккаунт на всех агентов | Только для чтения публичных данных; для остального - нет аудита |
| Наследование прав человека | Агент работает под учёткой владельца | Локальный персональный ассистент без доступа к общим системам |
| Отдельная identity + delegation | У агента свой субъект; в сценариях «от имени» - делегированный токен конкретного пользователя с ограниченным scope | Рабочая модель для корпоративных агентов |
Третья модель требует больше настройки, но даёт то, чего нет у первых двух: каждый вызов отвечает на вопросы «который агент», «от чьего имени» и «в рамках какой задачи». Это ровно те вопросы, которые NIST формулирует в концепт-бумаге: как агент доказывает полномочия на конкретное действие и как связывать agent identity с human identity для подтверждений и аудита.
Least privilege для недетерминированного исполнителя
Классический least privilege исходит из того, что программе нужны определённые операции. С агентом сложнее: заранее неизвестно, какие инструменты он выберет для достижения цели. Практический вывод - ограничивать не «системы», а операции:
- чтение / изменение / экспорт / массовые операции / администрирование - раздельные уровни, а не единый флаг «доступ к CRM»;
- узкие инструменты вместо универсальных:
get_issueвместоexecute_sql; - права вычисляются на момент задачи, а не зашиты при деплое: задача «разобрать входящие заявки» не должна уметь менять цены;
- истечение по завершении: task-scoped токен исчезает вместе с задачей, а не ждёт следующего запуска.
Хорошая проверка дизайна: перечислите операции агента и спросите для каждой - что произойдёт, если эту операцию выполнит злоумышленник, получивший контроль над контекстом? Если ответ «что угодно в системе X» - права слишком широкие.
От чьего имени: delegation вместо олицетворения
Большинство корпоративных сценариев устроены так: менеджер просит агента подготовить отчёт, и агент читает те данные, к которым имеет доступ менеджер. Технически это on-behalf-of - и здесь важно различать две вещи.
Олицетворение - агент входит под паролем пользователя. Плохо: система видит одного субъекта, разделить ответственность нельзя.
Делегирование - агент предъявляет короткоживущий токен, выданный в контексте этого пользователя и ограниченный нужными операциями. OAuth-механика для такого делегирования давно существует, а спецификация MCP определяет authorization flow для HTTP transport, который позволяет строить такие схемы поверх корпоративного IAM. Система при этом видит пару «агент + пользователь»: аудит восстанавливается, отзыв затрагивает только конкретную связку.
Для операционных сценариев, не привязанных к человеку (например, ночной triage issue), заводится отдельная identity агента со своим владельцем, назначением и правами. Правило простое: есть конкретный человек, от имени которого действует агент, - делегирование; сценарий системный - отдельная identity.
Жизненный цикл: выдать, ограничить, отозвать
Права агента - это не разовая настройка, а жизненный цикл:
- Регистрация. Каждому агенту - имя, владелец, назначение, список инструментов, уровень автономии. Незарегистрированный агент в корпоративной среде - инцидент по определению.
- Выдача. Минимальный набор операций под конкретный сценарий; для on-behalf-of - делегированные токены с scope и сроком.
- Наблюдение. Журнал вызовов, привязанный к паре «агент + человек». Он же - источник данных для пересмотра прав: операции, которыми не пользуются, закрываются.
- Отзыв. Уход сотрудника отключает его делегированные связки; вывод агента из эксплуатации - его identity. Обе операции должны занимать минуты, а не «когда-нибудь в квартале».
Где здесь место Codenik
Собрать всё это поверх каждого агента отдельно - проект на месяцы. Codenik реализует модель целиком на уровне слоя доступа: у каждого агента и каждого пользователя свои права, инструменты выдаются узкими наборами под сценарий, вызовы выполняются через делегированный контекст пользователя, секреты систем остаются на серверной стороне, а журнал фиксирует, кто и что сделал. Владелец агента видит и может изменить его полномочия в одном месте - без правок конфигов на машинах команды.
Подробнее про смежные части модели - в статьях «Зачем ИИ-агентам слой доступа» и «MCP без локальных секретов».
С чего начать
- Инвентаризация: сколько агентов сейчас ходит в ваши системы и под какими субъектами.
- Для каждого - определить модель: делегирование под человека или отдельная identity.
- Пересчитать права по операциям: закрыть массовые и административные операции там, где хватает чтения.
- Заменить постоянные токены короткоживущими, привязанными к задаче.
- Включить журнал «агент + человек» хотя бы для пишущих операций.
Короткий вывод
Права доступа для AI-агентов ломаются, когда агенту выдают субъект «на всю жизнь»: общий токен стирает аудит, наследование сотрудника умножает цену ошибки, вечный персональный ключ превращается в долг перед безопасностью. Рабочая модель - отдельная identity, делегирование для сценариев «от имени» и права, вычисляемые под задачу и истекающие вместе с ней.
Направление зафиксировано и на уровне стандартов: NIST в 2026 году открыл программу именно по identity и авторизации агентов. Команды, которые выстроят эти механизмы сейчас, потом просто приведут их к стандарту - вместо того чтобы перестраивать всё после первого серьёзного инцидента.