Когда ИИ-агенты начинают не просто отвечать на вопросы, а реально что-то делать – вызывать инструменты, обращаться к внешним сервисам, читать данные, – возникает вполне логичный вопрос: а кто решает, что им можно, а что нет? Протокол MCP (Model Context Protocol) как раз и появился для того, чтобы стандартизировать способ взаимодействия языковых моделей с инструментами и источниками данных. Но стандартизация общения – это лишь часть задачи. Вторая, не менее важная часть – безопасность этого общения.
MCP: коротко о том, что это и зачем
Проще говоря, MCP – это нечто вроде универсального переходника между ИИ-моделью и всем остальным миром: базами данных, API, файлами, корпоративными системами. Модель не обращается ко всему этому напрямую – она делает запросы через MCP-клиент, который общается с MCP-сервером, а тот уже знает, к каким ресурсам можно получить доступ и как.
В этой схеме есть три ключевых участника:
- MCP-хост – приложение, внутри которого функционирует модель (например, чат-интерфейс или IDE с ИИ-ассистентом);
- MCP-клиент – компонент, который от имени модели отправляет запросы;
- MCP-сервер – тот, кто эти запросы принимает и выполняет, предоставляя доступ к инструментам или данным.
Всё это выглядит аккуратно на бумаге. Но когда таких серверов становится несколько, когда они обслуживают разных пользователей и разные задачи – вопрос «а кто имеет право это запрашивать?» становится очень практическим.
Аутентификация и авторизация – в чём разница и зачем она важна
Эти два слова часто путают, поэтому сразу обозначим разницу.
Аутентификация – это «ты кто?». Подтверждение того, что запрос пришёл именно от того клиента, за кого он себя выдаёт.
Авторизация – это «а что тебе можно?». Проверка того, есть ли у этого клиента право на конкретное действие.
В агентных системах оба механизма работают в связке, и если один из них настроен небрежно – это открывает уязвимости. Например, если MCP-сервер не проверяет, от чьего имени пришёл запрос, любой агент в системе потенциально может получить доступ к чужим данным или выполнить действие, которое ему не предназначалось.
Три разных мира – три разных подхода
Не существует одного универсального способа настроить безопасность MCP. Всё зависит от того, в каком контексте разворачивается система. Выделяют три основных сценария, и у каждого – своя логика.
Открытые экосистемы
Это ситуация, когда MCP-сервер доступен широкому кругу клиентов – возможно, сторонних, возможно, публичных. Здесь важно использовать стандартизированные механизмы делегирования доступа. Спецификация MCP рекомендует подход на основе OAuth 2.1 – это протокол, который позволяет выдавать ограниченные права доступа без передачи паролей. Клиент получает токен (нечто вроде временного пропуска), и именно этот токен предъявляет серверу.
Важная деталь: сервер при этом не должен становиться полноценным менеджером учётных записей. Его задача – делегировать проверку подлинности внешнему провайдеру авторизации, а самому лишь убедиться, что токен действителен и выдан для нужного ресурса.
Корпоративные среды – Kubernetes и OpenShift
Здесь картина другая. Если система развёрнута внутри корпоративной инфраструктуры на базе Kubernetes или Red Hat OpenShift, то уже есть готовые механизмы управления доступом, которые грех не использовать.
В частности, сервисные аккаунты Kubernetes могут выдавать токены, которые MCP-клиент передаёт серверу как доказательство своей идентичности. Сервер проверяет этот токен через API платформы – и либо разрешает запрос, либо отказывает. Никаких отдельных паролей или самодельных схем авторизации.
Дополнительно в таких средах можно применять RBAC (ролевую модель контроля доступа) – когда права раздаются не конкретным пользователям, а ролям. Один агент получает роль «только чтение», другой – «может запускать инструменты», третий – «полный доступ к определённому набору ресурсов». Это делает систему более управляемой и прозрачной.
Внутренние и межсервисные взаимодействия
Третий сценарий – когда MCP-сервер и клиент работают внутри одной доверенной среды и общаются между собой, а не с внешним миром. Здесь велик соблазн: раз всё «внутри», можно не заморачиваться с безопасностью. Это распространённая и опасная ошибка.
Даже во внутренних системах стоит чётко разграничивать, какой именно сервис к чему обращается. Для этого используются механизмы взаимной аутентификации (mTLS) и токены с ограниченными правами. Проще говоря, каждый сервис должен уметь доказать, что он – это именно он, и не иметь доступа к тому, что ему не нужно для работы.
Принцип минимальных прав и почему он всё время всплывает
Если вы уже читали что-то о безопасности систем – этот принцип наверняка встречался. Он прост: каждый компонент системы должен иметь ровно столько прав, сколько необходимо для выполнения своей задачи. Не больше.
В контексте MCP это означает следующее: если агент занимается только поиском по базе знаний, ему незачем иметь доступ к инструментам записи или удаления. Если один MCP-сервер обслуживает несколько разных клиентов – каждый клиент должен видеть только свои данные, а не общий пул.
Это звучит очевидно, но на практике этим нередко пренебрегают: проще выдать широкие права и не думать об ограничениях. В результате получается система, где одна скомпрометированная точка открывает доступ к гораздо большему, чем должна была бы.
Что ещё стоит держать в голове
Токены – не вечны, и это хорошо
Любой токен доступа должен иметь срок действия. Это не бюрократия, а здравый смысл: если токен утёк или был скомпрометирован, его ценность быстро обнуляется. Долгоживущие токены – это риск, который легко снизить.
Проверка – на стороне сервера
MCP-сервер не должен слепо доверять тому, что указано в запросе. Даже если клиент утверждает, что у него есть права – сервер обязан проверить это самостоятельно, обратившись к системе авторизации. Доверие, не подкреплённое проверкой, – это уязвимость.
Логирование запросов
Кто, когда и что запрашивал – эта информация бесценна при анализе инцидентов. Агентные системы делают много автоматических запросов, и без нормального журнала действий разобраться в произошедшем будет очень сложно. Хорошая практика – логировать не только факт запроса, но и контекст: от имени кого, с каким токеном, к какому ресурсу.
Проверка происхождения запроса
В MCP-системах иногда возникает ситуация, когда запрос технически «легален» – токен валиден, права есть – но сам запрос сформирован не пользователем, а, например, данными из внешнего источника, которые агент обработал и «превратил» в команду. Это называют инъекцией подсказок (prompt injection). Защита от этого требует не только технических мер, но и аккуратного проектирования: агент не должен автоматически исполнять инструкции, пришедшие из потенциально недоверенных данных.
Почему сейчас это особенно актуально
MCP как протокол ещё относительно молод, и экосистема вокруг него активно формируется. Всё больше компаний начинают строить агентные системы, где ИИ не просто консультирует, а действует: читает письма, создаёт задачи, обновляет записи в базах данных. Цена ошибки в такой системе заметно выше, чем в обычном чат-боте.
При этом многие команды, впервые сталкивающиеся с MCP, воспринимают его прежде всего как удобный способ подключить модель к инструментам – и упускают из виду вопросы безопасности. Между тем именно сейчас, пока архитектуры ещё проектируются, а не переделываются, закладывать правильные практики и проще, и дешевле.
Аутентификация и авторизация в агентных системах – это не опциональная надстройка. Это часть базовой архитектуры. И чем раньше об этом думают при проектировании, тем меньше проблем возникает потом.
