Система MCP-first требует точной архитектуры безопасности. Не каждый клиент вправе видеть каждый инструмент. Не каждый агент вправе вызывать каждый инструмент. Не каждое действие вправе выполняться автономно. Не каждая информация вправе попадать в контекст ИИ.
Для этого необходимо чётко разграничить различные типы идентичностей и определить для каждого подходящий механизм аутентификации.
Пять идентичностей
Human User
Реальный пользователь системы — с личной идентичностью и правами, привязанными к роли. Типичные варианты: администратор, сотрудник, клиент, менеджер проекта, специалист поддержки, руководитель.
Human User — базовая идентичность. Все делегированные контексты в конечном счёте ссылаются на него.
MCP Client
Приложение, подключённое к MCP-серверу. MCP Client — не пользователь, а технический актор с собственным уровнем доверия.
Примеры: Claude Desktop, внутреннее AI-приложение, собственное мобильное приложение, собственный агентный воркер, внешний интеграционный клиент.
Клиент видит только те инструменты, которые соответствуют его уровню доверия и настроенным скоупам.
Agent Identity
Конкретный агент или рабочий процесс, который действует. Агент не идентичен клиенту, который его выполняет — у него есть собственная, описанная идентичность с ограниченными возможностями.
Примеры: Sales Assistant, Payroll Assistant, Support Agent, DevOps Agent, Reporting Agent, Personal Assistant.
Delegated User Context
Delegated User Context гарантирует, что агент вправе делать ровно столько, сколько пользователь, от имени которого он действует. Руководитель может видеть данные о зарплатах — агент Sales Assistant всё равно не должен получать эти данные в свой контекст.
Service Identity
Для процессов backend-to-backend без прямого пользовательского контекста. Service Identities — технические акторы с чётко определёнными, узкими скоупами.
Примеры: Import Worker, Scheduled Job, Sync Worker, Monitoring Agent, Billing Worker.
Аутентификация для людей
Пользователи-люди аутентифицируются через устоявшиеся методы. Выбор метода зависит от требований к безопасности и контекста:
- Email + Пароль — базовый доступ, всегда в сочетании с 2FA
- Passkeys — устойчивая к фишингу альтернатива паролям, предпочтительный вариант
- TOTP / 2FA — второй фактор для всех чувствительных областей
- SSO — для корпоративных сред с централизованным управлением идентичностью
- OAuth / OpenID Connect — для входа через сторонние сервисы и делегированного доступа
Аутентификация для MCP-клиентов
MCP-клиенты аутентифицируются через OAuth 2.1 с Authorization Code Flow и PKCE.
Это предотвращает атаки внедрения кода и подходит для публичных клиентов (без защищённого Client Secret).
Дополнительные требования:
- Короткие сроки действия Access Token — минимизирует ущерб при утечке токенов
- Refresh Token Rotation — каждое использование Refresh Token создаёт новый; старый немедленно становится недействительным
- Client Allowlist — для чувствительных систем допускаются только явно зарегистрированные клиенты; Dynamic Client Registration ограничен или отключён
- Валидация Redirect URI — принимаются только заранее зарегистрированные URI; открытые перенаправления — распространённый вектор атаки
- Token Binding — там где технически возможно, токен привязывается к клиенту
MCP-клиент при обнаружении инструментов видит только те, которые соответствуют его скоупам — не все инструменты с последующим отказом при вызове.
-
contacts:readЧитать и искать контакты -
projects:readЧитать проекты -
emails:draftСоздавать черновики электронных писем -
calendar:createСоздавать события -
reminders:write
Аутентификация для внутренних сервисов
Коммуникация backend-to-backend предъявляет иные требования, чем аутентификация пользователей или клиентов. Здесь применяются технические механизмы без интерактивного шага аутентификации:
mTLS— взаимная TLS-аутентификация; обе стороны удостоверяются сертификатами- Подписанные Service Tokens — краткосрочные, криптографически подписанные токены с узко определёнными скоупами; никаких долгосрочных общих секретов
- Secret Manager — учётные данные, сертификаты и ключи никогда не хранятся в конфигурационных файлах, а управляются и ротируются через центральный Secret Manager
- Приватные сетевые зоны — внутренние сервисы коммуникируют в изолированных сетевых сегментах; никакой прямой доступности из публичной сети
- IP Allowlist — для критических систем доступ дополнительно ограничивается известными IP-диапазонами
- Token Rotation — сервисные токены тоже имеют короткий срок действия и регулярно обновляются