Безопасны ли MCP и AI Agent Skills? 10 рисков безопасности, которые нужно проверить перед использованием сторонних AI-инструментов в 2026 году

В руководстве по безопасности MCP выделен отдельный раздел 0x10-C10, посвящённый контролям безопасности этого протокола (раздел о контролях MCP). Это конкретный повод не считать название инструмента доказательством его безопасности. MCP и AI Agent Skills не являются автоматически ни безопасными, ни опасными: решение зависит от источника, объёма разрешений, направления передачи данных, выполняемого кода и изоляции. На этой неделе проверьте каждый компонент до выдачи доступа; если его происхождение или поведение невозможно проверить, отложите подключение.

Эта проверка предназначена разработчикам, которые подключают MCP-сервисы и оценивают их права и потоки данных. Она также пригодится тем, кто устанавливает сторонние AI Agent Skills, и техническим или безопасностным командам, утверждающим запуск AI-агентов.

Последнее обновление: 6 июля 2026 года. Сверка границ рекомендаций выполнена по документации MCP, спецификации Skills и материалам по безопасности, указанным в статье. Это руководство не утверждает, что описанные риски уже реализованы в конкретном продукте.

Начните с критериев безопасности

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

В спецификации расширений Skills определены требования к формату и поведению навыков; их стоит сопоставить с фактическим содержимым устанавливаемого компонента, а не принимать одно название за подтверждение безопасности (спецификация Skills). Руководство по созданию навыков также помогает понять, какие инструкции и файлы могут входить в Skill, но не заменяет проверку конкретной версии (описание создания Skill).

Практически решение можно разбить на три уровня:

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

Какие признаки помогают оценить доверие к стороннему источнику? Ищите ясного издателя, историю изменений, поддерживаемый репозиторий, объяснение зависимостей и возможность сверить установленное содержимое с опубликованным. Наличие страницы или документации само по себе не доказывает добросовестность. Проверьте, совпадает ли фактически устанавливаемая версия с заявленной, кто имеет право её менять и есть ли понятный способ сообщить о проблеме.

Проверьте права MCP и обработку ответов

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

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

Риск 1 — избыточные права. Он возникает, если инструменту для узкой задачи выданы широкие права чтения, записи или выполнения. Проверьте перечень разрешённых операций и ресурсов. В тесте задайте задачу, требующую только чтения, и убедитесь, что инструмент не способен менять данные за её пределами. Уменьшите разрешения, разделите учётные записи или не подключайте сервис, если ограничить его нельзя.

Риск 2 — инъекция через результат инструмента. Содержимое страницы, файла или ответа внешнего сервиса может включать инструкции, которые агент ошибочно воспримет как команду. Опасность зависит от того, обрабатывает ли агент внешний текст как доверенное указание и может ли он вслед за этим вызвать другой инструмент. Проверьте, отделяются ли данные от системных инструкций, и проследите за поведением на специально подготовленном безопасном тестовом содержимом. Руководство по защите от prompt injection рекомендует рассматривать внешние данные как недоверенный ввод и применять несколько уровней контроля (рекомендации по защите от инъекций).

Риск 3 — передача данных не тому получателю. Вызов может отправить наружу параметры, фрагмент контекста, содержимое файла или результат работы с данными. Проверьте сетевые направления, журналы и состав параметров запроса. Отдельно отметьте персональные данные, исходный код, внутренние документы и секреты. Если нельзя объяснить, какие сведения покидают вашу среду и для чего, не передавайте туда конфиденциальные данные. Сам факт передачи не означает утечку: существенны получатель, разрешение на такую передачу и чувствительность данных.

Проследите цепочку поставки и исполнения

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

Риск 4 — подмена или непрозрачное происхождение компонента. Он появляется, когда издатель неизвестен, зависимости не перечислены или нельзя установить, кто и когда менял содержимое. Проверьте историю поддержки, контроль версий, опубликованные предупреждения и соответствие загруженного кода исходнику. Проектная политика безопасности MCP помогает определить, какие вопросы стоит задать при оценке сервера, но не является подтверждением безопасности стороннего экземпляра (документ о политике безопасности MCP). Если версию нельзя надёжно сопоставить с проверенным исходником, не запускайте её с рабочими данными.

Риск 5 — инструкции Skill пытаются обойти намерение пользователя. Например, текст навыка может просить агента скрыть действия, игнорировать ограничение или выполнять операцию, не связанную с заданием. Риск зависит от того, какие инструкции агент принимает и как он разграничивает доверенные правила и сторонний контент. Прочитайте все файлы Skills, сравните заявленное назначение с указаниями и ищите команды, требующие скрытности либо неограниченного доступа. Если обнаружены такие требования, приостановите установку и запросите объяснение у поддерживающей стороны.

Риск 6 — нежелательные действия скрипта или зависимости. Скрипт может выполнять больше, чем следует из описания навыка. Просмотрите команды, установочные инструкции и зависимости; проверьте, обращаются ли они к сети, файловой системе или оболочке. Сначала запускайте компонент без рабочих секретов и данных, в изолированной среде с ограниченными правами. Описание Skill не гарантирует, что каждый зависимый компонент ведёт себя так же, как заявлено; сопоставляйте документацию со скриптами и наблюдаемыми действиями.

Ограничьте раскрытие секретов и цепочки инструментов

Один инструмент может выглядеть безобидно, но безопасность зависит и от того, что происходит до и после его вызова. Проследите путь данных через всю цепочку: от запроса пользователя и контекста до ответа инструмента, журналов и следующего вызова. Установите, где находятся учётные данные и кто может их прочитать. Если секрет доступен в обычном тексте диалога или записывается в журнал, его защита зависит от всех компонентов, имеющих доступ к этому содержимому.

Риск 7 — секреты в конфигурации, контексте или журналах. Это может произойти при неаккуратном хранении токена, передаче ключа в параметрах или записи чувствительного значения в диагностические данные. Проверьте конфигурационные файлы, переменные среды и журналы тестового запуска. Убедитесь, что учётные данные не включаются в содержимое, доступное агенту без необходимости, и что у каждого токена ограничены назначение и срок действия. Материал о построении идентификационной основы для агентного AI подчёркивает важность управления идентичностью и полномочиями при работе агентов (разбор идентичности и учётных данных).

Риск 8 — обход ограничений через сочетание инструментов. Инструменты могут по отдельности иметь допустимые функции, но вместе позволить агенту прочитать данные одним способом и изменить их другим, минуя ожидаемое подтверждение. Проверьте, какие результаты одного вызова могут стать входом следующего, и какие действия требуют явного согласия пользователя. Ограничьте взаимодействие инструментов и добавьте подтверждение для операций с существенными последствиями. Оценка чрезмерной автономности рассматривает ситуацию, когда агент получает возможности действовать шире необходимого (описание риска избыточной агентной автономности). Это не доказывает, что любая связка инструментов опасна: оценивать нужно конкретный маршрут данных и полномочий.

Если вы не можете восстановить цепочку «входные данные — вызов — результат — следующий вызов», считайте поведение непроверенным. Не выдавайте такую связку доступ к рабочим данным до устранения пробела.

Настройте идентификацию и возможность отката

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

Способ аутентификации и полномочия зависят от конкретной реализации. Поэтому не переносите описание одной платформы на все MCP-сервисы. Используйте актуальную документацию той версии и конфигурации, которую собираетесь запускать; рекомендации по авторизации MCP помогают сформировать вопросы, но не заменяют проверку конкретного механизма (документ по безопасности авторизации).

Риск 10 — недостаточный аудит и отсутствие плана остановки. Если нет записей о вызовах, изменения трудно обнаружить и разобрать. Если нельзя быстро отключить компонент или отозвать его права, последствия инцидента сложнее ограничить. До запуска проверьте, какие события журналируются, кто может просматривать записи, как выявляется изменение версии и кто имеет право остановить интеграцию. Убедитесь, что после отключения можно отозвать токены, удалить доступы и восстановить затронутые данные.

Как проверить настройки полномочий и изоляцию? Создайте отдельную тестовую учётную запись с минимальным доступом, не подключайте к ней рабочие секреты и запустите компонент в среде, где его действия можно наблюдать и остановить. Проверьте чтение и запись на заранее выбранных тестовых данных. Попробуйте отозвать доступ и убедитесь, что следующий вызов действительно блокируется. Если изоляция лишь заявлена, но не ограничивает файловую систему, сеть или полномочия, не полагайтесь на неё как на защиту.

Пройдите проверку перед подключением

Используйте последовательность ниже как рабочий процесс, а не как формальную отметку в документе.

1. Зафиксируйте источник. Запишите издателя, адрес исходного проекта, версию и способ установки. Сверьте описание и фактическое содержимое. Если источник нельзя проверить, остановитесь.
2. Составьте карту разрешений. Для каждого инструмента укажите, что он читает, изменяет, запускает и отправляет. Сравните полномочия с задачей. Уберите ненужный доступ или откажитесь от подключения.
3. Просмотрите инструкции и зависимости. Изучите файлы Skill, код, установочные команды и список зависимостей. Отдельно проверьте сетевые обращения и доступ к файлам. Непонятное действие — основание запросить объяснение, а не предположить его безопасность.
4. Проверьте потоки данных. Перечислите входные данные, параметры вызова, ответы, журналы и получателей. Убедитесь, что чувствительная информация не уходит в незапланированное направление.
5. Проведите изолированный тест. Используйте тестовые данные и ограниченную учётную запись. Проверьте ожидаемые и запрещённые действия, а также реакцию на недоверенное содержимое.
6. Проверьте аудит, отзыв и откат. Убедитесь, что ключевые вызовы можно расследовать, доступ — отозвать, а компонент — отключить без сохранения лишних разрешений.

Когда следует отложить подключение? Если вы не знаете, куда уходят данные, видите ненужные широкие права, не можете ограничить скрипт или не способны отозвать полномочия — не выдавайте доступ к рабочей среде. Сначала запросите уточнения, сократите область доступа или подберите альтернативный компонент с проверяемым поведением.

В таблице обозначения «низкий», «средний» и «высокий» — качественная оценка по описанным условиям, а не измерение вероятности инцидента.

Предположительный пример: команда хочет подключить Skill, который помогает обрабатывать внутренние документы через MCP-сервис. При проверке выясняется, что Skill предлагает запуск команды, а назначение сетевого обращения не объяснено. Это не доказывает злонамеренность. Но пока команда не установит, что делает команда и кто получает запрос, правильное решение — не передавать сервису внутренние документы. Если объяснение подтверждено, доступ ограничен тестовой папкой, а вызовы видны в журнале, команда может перейти к контролируемому тесту.

Если ваша текущая схема — запускать сторонний компонент прямо на рабочей машине, передавать ему широкие права и разбираться с последствиями только по факту, у неё есть три очевидных недостатка: границы доступа размыты, тестовые и рабочие данные могут смешиваться, а отзыв разрешений зависит от ручных действий. Для временного эксперимента отдельная среда с контролируемым доступом может быть разумнее. Если для такого теста вам подходит аренда Mac, уточните доступные варианты у VPSSpark; сведения о компании можно проверить на странице о VPSSpark. Не считайте смену компьютера гарантией безопасности: изоляцию, разрешения и обработку секретов всё равно нужно настраивать отдельно. Если эксперимент требует постоянной нагрузки или физических интерфейсов, собственное оборудование может быть практичнее. Перед подключением ещё раз проверьте источник, права и данные — именно эти условия определяют, безопасны ли MCP и AI Agent Skills в вашем сценарии.