Агенты — это «мощные пользователи» без здравого смысла
AI-агенты используют каждый инструмент, который Вы им дадите, если решат, что это поможет выполнить задачу. В этом и их сила, и их риск. Агент с правом записи в продакшен-базу абсолютно точно изменит продакшен-данные, если решит, что это лучший путь к тому, что Вы попросили. Он не остановится и не подумает: «погоди, может, стоит сначала с кем-то посоветоваться».
Это означает, что архитектура прав должна быть guardrail. Полагаться на самоограничение агента нельзя. Если он не должен что-то делать, у него не должно быть возможности это сделать.
Наименьшие привилегии, применённые к агентам
Принцип наименьших привилегий не нов, но с агентами он работает иначе. Разработчик-человек с доступом к продакшен-базе использует здравый смысл, решая, когда действительно выполнять запросы. У агента такого фильтра нет. Поэтому наименьшие привилегии для агентов должны быть строже, чем то, что Вы дали бы человеку в той же роли.
На практике это значит: учётные данные базы только-на-чтение для агентов, которым нужно лишь выбирать данные. API-токены с ограниченной областью, обращающиеся только к нужным агенту эндпоинтам. Доступ к файловой системе ограничен конкретными директориями, а не всем диском. Каждое право должно соответствовать конкретной возможности, для которой агент спроектирован.
Многоуровневые модели прав
Хороший подход — выстраивать права слоями. Первый слой — какие MCP-серверы доступны агенту. Второй слой — какие учётные данные используют эти серверы. Третий слой — что разрешает базовый сервис с этими учётными данными. Каждый слой может ограничивать независимо.
Например, Вы даёте агенту доступ к MCP-серверу базы данных (слой один), конфигурируете этот сервер с пользователем базы только-на-чтение (слой два), а у этого пользователя есть только право SELECT по конкретным таблицам (слой три). Даже если агент каким-то образом обойдёт первый слой, второй и третий по-прежнему Вас защитят.
Разделение окружений
Продакшен и разработка должны использовать совершенно разные учётные данные для агентов. Звучит очевидно, но при быстрой итерации легко допустить промах. Агент, сконфигурированный с продакшен-учётными данными во время «быстрой проверки», который так и не вернули, — распространённый и опасный паттерн.
Создайте отдельные конфигурации MCP для разработки и продакшена. Чётко их подпишите. Сделайте так, чтобы случайно запустить разработческого агента с продакшен-учётными данными было сложно. Усилия по предотвращению ошибок окупаются в первый же раз, когда они не дадут совершить ошибку.
Аудит действий агента
Права без логирования — это половина картины. Нужно знать, что Ваши агенты на самом деле сделали со своим доступом. Логируйте каждый вызов инструмента, каждый запрос API, каждый запрос к базе. Когда что-то пойдёт не так (а рано или поздно пойдёт), именно эти логи помогут понять, что случилось, и соответствующим образом ужесточить права.
Связанные материалы
- Почему качество MCP-серверов так сильно различается (и как его оценивать)
- Роль guardrails в продакшен-AI-агентах
- Как ответственно использовать AI-инструменты в продакшене
Открыть AI-агентов на Skillful.sh. Поиск по 137 000+ AI-инструментам.