Права AI-агентов: RBAC, доступ через MCP и делегирование

AI-агенту нужно давать права так же, как новому сотруднику на испытательном сроке, только строже. Агент получает отдельную учётную запись с ролью (RBAC), доступ только к нужным проектам и действиям, подтверждение человеком для всего, что трудно отменить, и полный журнал. Подключение через MCP не меняет этих правил: токен MCP-сервера должен давать ровно столько прав, сколько нужно сценарию.

Статья для руководителей IT, тимлидов и специалистов по ИБ, которые подключают AI-агентов к таск-трекеру, CRM или репозиторию. Разбираем модель прав, таблицу «действие → риск → контроль», MCP, делегирование, локальные модели и чек-лист перед запуском.

Почему права агента — это архитектура, а не галочка

Пока AI только отвечал на вопросы в чате, вопрос прав почти не стоял. В 2026 году агенты работают внутри рабочих систем: создают задачи, меняют статусы, пишут комментарии, обновляют карточки клиентов. В Plane появились AI-агенты внутри рабочего пространства и MCP-коннекторы, у Atlassian есть Rovo и Jira Automation. Агент стал участником процесса с доступом к данным.

У агента три свойства, которые делают ошибку в правах дороже, чем у человека:

• Скорость. Человек ошибается в одной задаче, агент за минуту повторяет ошибку в сотне.
• Буквальность. Агент выполняет инструкцию, даже если она пришла из текста задачи или письма клиента, а не от владельца.
• Невидимость. Если агент работает под чужой учётной записью, его действия неотличимы от действий человека.

Есть и организационная причина. Служба ИБ и юристы согласуют агента быстрее, если им показать понятную модель: какая роль, какие проекты, какие действия запрещены, где журнал. Без такой модели обсуждение сводится к общему «AI небезопасен», и пилот откладывается.

Поэтому права агента проектируют до запуска. Мы разбирали уровни автоматизации в статье правила, скрипты или AI-агенты, а здесь сосредоточимся на доступе.

Агент — это пользователь с ролью

Базовый принцип: у каждого агента своя учётная запись или сервисный аккаунт, и права выдаются через роль. Не через личный токен администратора и не через учётку сотрудника, который «настроил и забыл».

Что это даёт:

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

Типовые роли, с которых мы начинаем:

Роль агента	Что может	Чего не может	Пример сценария
Читатель	Читать задачи, документы, комментарии в выбранных проектах	Создавать и менять что-либо	Резюме проекта, поиск, ответы на вопросы
Автор черновиков	Создавать черновики задач и комментарии	Менять статусы, исполнителей, сроки	Задачи из писем и протоколов встреч
Триажёр	Ставить метки, тип, приоритет во входящих	Закрывать и удалять задачи	Разбор Intake и баг-репортов
Исполнитель с подтверждением	Менять поля и статусы после одобрения человеком	Менять права, удалять, писать клиентам напрямую	Обновление статусов по итогам ревью

Роль администратора агенту не даётся. Если сценарий требует прав администратора, это сигнал, что сценарий нужно разделить.

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

Минимальные права: действие, риск, контроль

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

Действие агента	Риск	Контроль
Чтение задач и документов	Утечка данных в ответах или во внешнюю модель	Доступ только к нужным проектам, проверка, куда уходят данные
Создание задачи	Шум и дубли в бэклоге	Метка «создано агентом», лимит на число задач в сутки
Комментарий в задаче	Неточная информация выглядит как позиция команды	Пометка автора, запрет упоминаний клиентов
Смена статуса или исполнителя	Срыв процесса, ложная картина прогресса	Подтверждение человеком
Массовое изменение	Сотни испорченных задач за минуту	Запрет или подтверждение с предпросмотром
Удаление	Потеря данных	Запрет
Изменение прав и ролей	Эскалация привилегий	Запрет
Сообщение клиенту	Репутационный и юридический риск	Только черновик, отправляет человек
Изменение сделки в CRM	Неверные суммы и прогнозы	Подтверждение владельцем сделки

В Plane детальные права (Granular Access Control), LDAP и группы из IdP доступны в старших тарифах. В Jira права задаются схемами разрешений проекта. В обоих случаях проверяйте, какие механизмы есть в вашей версии и тарифе, до того как обещать службе ИБ конкретную модель доступа.

Подтверждение человеком и журнал

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

Чтобы подтверждение не превратилось в формальность:

• Подтверждает человек, который отвечает за результат, а не любой участник.
• Перед подтверждением видно, что изменится: поля до и после, список задач.
• Массовые операции подтверждаются целиком, а не по одной задаче.
• Если подтверждения нет в течение заданного времени, действие отменяется, а не выполняется.

Что записывать в журнал

Журнал действий агента отвечает на пять вопросов: какой агент, от чьего имени, по какому запросу, что изменил, кто подтвердил. На практике это набор полей:

• идентификатор агента и версия его инструкции;
• инициатор: человек, правило или расписание;
• исходный запрос или событие, которое запустило агента;
• список вызванных инструментов и затронутых объектов;
• значения полей до и после изменения;
• кто и когда подтвердил действие или почему оно отклонено.

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

MCP: доступ к системам через стандартный протокол

MCP (Model Context Protocol) — открытый протокол, через который AI-клиент подключается к внешним системам. MCP-сервер описывает набор инструментов: «найти задачи», «создать задачу», «обновить поле». Модель решает, какой инструмент вызвать. В 2026 году MCP-коннекторы есть у Plane, и через них трекер подключают к AI-ассистентам и средам разработки.

Удобство MCP в стандартизации. Риск в том, что подключение часто делают с широким токеном, и агент получает всё, что может этот токен. Правила для MCP:

1. Отдельный токен на каждое подключение. Не общий ключ администратора.
2. Токен от сервисного аккаунта с ролью. Права MCP-сервера ограничены правами этого аккаунта.
3. Белый список инструментов. Если сценарию нужно только чтение, инструменты записи не подключаются.
4. Осторожность со сторонними MCP-серверами. Сервер из открытого каталога — это код с доступом к вашим данным. Проверяйте источник и ставьте его в своём контуре.
5. Защита от инструкций в данных. Текст задачи или письма может содержать указания для модели. Агент с правами только на чтение такой атаке почти не страшен, агент с правами на запись опасен.

Делегирование: агент действует от имени человека

Иногда агент должен действовать от имени конкретного человека: разработчик просит ассистента в IDE закрыть задачу после мержа, менеджер просит подготовить комментарий клиенту. Это делегирование, и у него свои правила.

• Права делегированного агента не шире прав человека, который его запустил, и обычно уже.
• В журнале видно и агента, и человека: «агент X по запросу Y».
• Делегирование ограничено по времени и по сценарию, а не выдаётся навсегда.
• Человек может отозвать делегирование в любой момент, и это не требует администратора.

Если система не умеет различать «человек» и «агент от имени человека», выбирайте отдельный сервисный аккаунт. Чистый журнал важнее удобства.

Локальные модели и данные в контуре

Контекст Казахстана. Когда агент читает задачи и карточки клиентов и отправляет их во внешнюю модель, данные покидают контур и часто уходят за пределы Казахстана. Схему обработки данных агентом стоит согласовать со службой ИБ. Если компании важно, чтобы данные не покидали страну, есть вариант без внешних вызовов: Plane Airgapped работает полностью без интернета и поддерживает локальную AI-модель. Jira Cloud хранит данные в регионах Atlassian, среди которых Казахстана нет.

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

Локальная модель не отменяет RBAC. Она убирает риск передачи данных провайдеру, но агент с широкими правами внутри контура остаётся агентом с широкими правами.

Чек-лист перед запуском агента

1. Сценарий описан одной фразой, у него есть владелец.
2. Создан отдельный сервисный аккаунт с ролью под этот сценарий.
3. Доступ ограничен нужными проектами или объектами CRM.
4. Удаление, изменение прав и массовые операции запрещены или требуют подтверждения.
5. Сообщения клиентам агент готовит только как черновики.
6. Для MCP выдан отдельный токен и подключены только нужные инструменты.
7. Понятно, какая модель обрабатывает данные и где она работает.
8. Журнал фиксирует агента, инициатора, изменение и подтверждение.
9. Есть способ отключить агента за минуту без участия разработчика.
10. Назначена дата разбора пилота и критерии расширения прав.

Как мы это делаем

Мы начинаем с диагностики: какие сценарии хочется отдать агентам, какие данные они затрагивают, что скажет служба ИБ. Затем запускаем пилот с одной командой и одним агентом в роли «читатель» или «автор черновиков», смотрим журнал и только после этого расширяем права и подключаем следующие команды. Если данные должны оставаться в Казахстане, проектируем контур с self-hosted трекером и локальной моделью. Как выглядят сами сценарии, мы разобрали в статье об AI-агентах в управлении задачами.

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

---

Источники. Тарифы и возможности Plane: plane.so/pricing. Репозиторий Plane: github.com/makeplane/plane. Регионы хранения данных Atlassian Cloud: документация Atlassian. Данные на октябрь 2026 года.

Термины простыми словами

RBAC (Role-Based Access Control)

Управление доступом через роли: права выдаются роли, а не конкретному человеку или агенту. Чтобы расширить или урезать доступ агента, достаточно поменять его роль.

MCP (Model Context Protocol)

Открытый стандарт, через который AI-клиент подключается к трекеру, CRM или хранилищу кода и вызывает их функции. Опасен, если подключение сделано с ключом, у которого слишком широкие права.

Сервисный аккаунт

Учётная запись не для человека, а для программы или агента. Его действия видны в журнале отдельно, а отключить его можно, не затрагивая сотрудников.

Токен

Цифровой ключ, по которому агент или MCP-сервер входит в систему и получает все его права. Поэтому на каждое подключение выдают отдельный токен с узкими правами.

Принцип минимальных привилегий

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

Эскалация привилегий

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

Делегирование

Режим, в котором агент действует от имени конкретного человека и не получает больше прав, чем у него. В журнале видно и агента, и того, кто его запустил.

Локальная модель

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