Model Context Protocol, или MCP, представляет собой открытый стандарт, первоначально предложенный компанией Anthropic. Он связывает ИИ-ассистентов и агентов с внешними инструментами, актуальными данными и рабочими системами. Через MCP агент способен получить запись из базы данных, открыть файл, вызвать API, прочитать внутреннюю документацию или обратиться к облачной инфраструктуре. Между моделью и целевой системой находится MCP-сервер: небольшая программа, которая предоставляет агенту разрешённые операции и обычно хранит необходимые для них учётные данные.
После такого подключения ИИ-агент фактически получает собственную рабочую идентичность. В качестве Non-Human Identity, или NHI, используются API-ключи, токены доступа, ключи сервисных аккаунтов и другие секреты. Агент уже не ограничивается подготовкой ответа: он выбирает инструменты, извлекает закрытые сведения и совершает действия в корпоративных системах. Поэтому утечка токена грозит не одним лишь чтением данных. Злоумышленник может действовать от имени скомпрометированной NHI, если её разрешения допускают запись, удаление или изменение настроек.
Обычный источник утечки выглядит почти буднично: разработчик вставляет токен прямо в строку конфигурации MCP-сервера. Ключ остаётся в открытом виде на диске, переносится вместе с настройками на другой компьютер или случайно попадает в репозиторий Git. При захвате сервера атакующий получает все доступные для чтения секреты разом. Хуже, когда служба безопасности ещё не знает о существовании этого MCP-сервера и не проверяет ни его конфигурацию, ни журналы доступа.
Без централизованного хранилища начинается расползание учётных данных. Один API-ключ оседает в конфигурационных файлах, переменных окружения, средах разработки, тестовых контурах и production. Копии трудно посчитать, поэтому секреты редко меняют; некоторые токены сохраняют силу годами. Увольнение сотрудника или закрытие проекта тут не всегда помогает: забытая NHI продолжает работать, а её ключ лежит на машине, давно выпавшей из регулярных проверок.
Прямой взлом MCP-сервера даже не обязателен. При prompt injection вредоносные инструкции прячут в документе, заявке службы поддержки или веб-странице, которую читает агент. Модель может принять этот текст за команду, неправильно воспользоваться доступным инструментом, раскрыть секрет либо выполнить запрещённую операцию. Особенно опасны такие сценарии при избыточных правах. Разработчики нередко выдают широкий доступ, чтобы не тратить время на ошибки авторизации, а затем переносят те же разрешения в production. В итоге агенту для чтения одной таблицы достаётся возможность обращаться к целой базе или менять её содержимое.
Открытая экосистема MCP несёт и риск цепочки поставок: опубликовать сервер может кто угодно. Показательный случай связан с уязвимостью CVE-2025-6514 в mcp-remote, OAuth-прокси, работающем на клиентской машине и загруженном более 400 000 раз. Вредоносный сервер мог вызвать инъекцию команд операционной системы. Последствием становилось удалённое выполнение кода, RCE, а затем кража учётных данных, доступных на компьютере с прокси. Проверять приходится не один сервер и его автора, но также зависимости, обновления и поведение клиентских компонентов.
Секреты следует убрать из исходного кода, переменных окружения и локальных конфигураций в единое управляемое хранилище. Агенту лучше получать учётные данные только во время выполнения конкретной операции. Постоянные ключи стоит заменить короткоживущими: они выпускаются по запросу, автоматически истекают и меняются без ручной процедуры. Украденный токен тогда имеет ограниченный срок пригодности, а ротация закрывает доступ после его замены.
Принцип наименьших привилегий нужно применять отдельно к каждому агенту: разрешать лишь необходимые системы, данные и действия. Получение незамаскированного секрета, удаление записи и работа в production требуют явного подтверждения человека. Такая контрольная точка способна остановить последствия prompt injection до выполнения команды. Разрешения также надо регулярно пересматривать, поскольку временный доступ, выданный для отладки, имеет неприятную привычку становиться постоянным.
Для хранения подходят модели zero trust и zero knowledge. Секреты передаются с сквозным шифрованием, извлекаются в момент использования и остаются нечитаемыми для самой платформы-хранилища. При zero knowledge компрометация сейфа не должна отдавать атакующему значения ключей в открытом виде. Параллельно фиксируются все обращения агента: что он прочитал, какое действие выполнил и когда это произошло. Такие журналы нужны для мониторинга, соблюдения нормативных требований, расследования инцидента и восстановления точной последовательности событий.
Отдельная задача — полный реестр MCP-серверов и связанных с ними NHI. Неучтённые или забытые серверы, которые тихо держат активные токены и не попадают в проверки, образуют shadow AI. Для этого слоя нужны те же правила, что и для production-систем с ценными учётными данными. В качестве специализированного решения для MCP-сред предлагается Keeper Secrets Manager: согласно заявленным возможностям, он маскирует секреты по умолчанию, требует подтверждения перед раскрытием значения и позволяет агентам применять учётные данные, не оставляя их открытыми. При выборе такого средства всё равно проверяются модель шифрования, разграничение прав, ротация, аудит и возможность обнаруживать неизвестные MCP-серверы.
Изображение носит иллюстративный характер
После такого подключения ИИ-агент фактически получает собственную рабочую идентичность. В качестве Non-Human Identity, или NHI, используются API-ключи, токены доступа, ключи сервисных аккаунтов и другие секреты. Агент уже не ограничивается подготовкой ответа: он выбирает инструменты, извлекает закрытые сведения и совершает действия в корпоративных системах. Поэтому утечка токена грозит не одним лишь чтением данных. Злоумышленник может действовать от имени скомпрометированной NHI, если её разрешения допускают запись, удаление или изменение настроек.
Обычный источник утечки выглядит почти буднично: разработчик вставляет токен прямо в строку конфигурации MCP-сервера. Ключ остаётся в открытом виде на диске, переносится вместе с настройками на другой компьютер или случайно попадает в репозиторий Git. При захвате сервера атакующий получает все доступные для чтения секреты разом. Хуже, когда служба безопасности ещё не знает о существовании этого MCP-сервера и не проверяет ни его конфигурацию, ни журналы доступа.
Без централизованного хранилища начинается расползание учётных данных. Один API-ключ оседает в конфигурационных файлах, переменных окружения, средах разработки, тестовых контурах и production. Копии трудно посчитать, поэтому секреты редко меняют; некоторые токены сохраняют силу годами. Увольнение сотрудника или закрытие проекта тут не всегда помогает: забытая NHI продолжает работать, а её ключ лежит на машине, давно выпавшей из регулярных проверок.
Прямой взлом MCP-сервера даже не обязателен. При prompt injection вредоносные инструкции прячут в документе, заявке службы поддержки или веб-странице, которую читает агент. Модель может принять этот текст за команду, неправильно воспользоваться доступным инструментом, раскрыть секрет либо выполнить запрещённую операцию. Особенно опасны такие сценарии при избыточных правах. Разработчики нередко выдают широкий доступ, чтобы не тратить время на ошибки авторизации, а затем переносят те же разрешения в production. В итоге агенту для чтения одной таблицы достаётся возможность обращаться к целой базе или менять её содержимое.
Открытая экосистема MCP несёт и риск цепочки поставок: опубликовать сервер может кто угодно. Показательный случай связан с уязвимостью CVE-2025-6514 в mcp-remote, OAuth-прокси, работающем на клиентской машине и загруженном более 400 000 раз. Вредоносный сервер мог вызвать инъекцию команд операционной системы. Последствием становилось удалённое выполнение кода, RCE, а затем кража учётных данных, доступных на компьютере с прокси. Проверять приходится не один сервер и его автора, но также зависимости, обновления и поведение клиентских компонентов.
Секреты следует убрать из исходного кода, переменных окружения и локальных конфигураций в единое управляемое хранилище. Агенту лучше получать учётные данные только во время выполнения конкретной операции. Постоянные ключи стоит заменить короткоживущими: они выпускаются по запросу, автоматически истекают и меняются без ручной процедуры. Украденный токен тогда имеет ограниченный срок пригодности, а ротация закрывает доступ после его замены.
Принцип наименьших привилегий нужно применять отдельно к каждому агенту: разрешать лишь необходимые системы, данные и действия. Получение незамаскированного секрета, удаление записи и работа в production требуют явного подтверждения человека. Такая контрольная точка способна остановить последствия prompt injection до выполнения команды. Разрешения также надо регулярно пересматривать, поскольку временный доступ, выданный для отладки, имеет неприятную привычку становиться постоянным.
Для хранения подходят модели zero trust и zero knowledge. Секреты передаются с сквозным шифрованием, извлекаются в момент использования и остаются нечитаемыми для самой платформы-хранилища. При zero knowledge компрометация сейфа не должна отдавать атакующему значения ключей в открытом виде. Параллельно фиксируются все обращения агента: что он прочитал, какое действие выполнил и когда это произошло. Такие журналы нужны для мониторинга, соблюдения нормативных требований, расследования инцидента и восстановления точной последовательности событий.
Отдельная задача — полный реестр MCP-серверов и связанных с ними NHI. Неучтённые или забытые серверы, которые тихо держат активные токены и не попадают в проверки, образуют shadow AI. Для этого слоя нужны те же правила, что и для production-систем с ценными учётными данными. В качестве специализированного решения для MCP-сред предлагается Keeper Secrets Manager: согласно заявленным возможностям, он маскирует секреты по умолчанию, требует подтверждения перед раскрытием значения и позволяет агентам применять учётные данные, не оставляя их открытыми. При выборе такого средства всё равно проверяются модель шифрования, разграничение прав, ротация, аудит и возможность обнаруживать неизвестные MCP-серверы.
