Модель угроз MCP

L39 · MCP 2026-07-28 · открытая бета · редакция 2026.10-beta1

Я строю модель угроз вокруг переходов доверия, а не списка страшных слов. Пользователь, host, client, MCP server, AS и внешний API имеют разные данные и полномочия. На каждом переходе спрашиваю: кто может подменить вход и какой побочный эффект станет возможен?

Предварительно: L09 · L19 · L26

Как я это использую

Основные сценарии — prompt injection из ресурсов, confused deputy, token passthrough, SSRF discovery, утечка cross-tenant кэша и повтор записи. Для каждого задайте актив, атакующего, предусловие, контроль и негативный тест. Человек должен понимать, какую операцию подтверждает; общее согласие на подключение сервера не оправдывает любую будущую запись.

Разбираем конкретный контракт

Это учебный fixture: поля с доменом .example и идентификаторы вымышлены. Если показан фрагмент, его нужно поместить в соответствующий envelope выбранного профиля.

{
  "asset": "private project tasks",
  "attacker": "untrusted resource content",
  "attack": "request cross-tenant export",
  "controls": [
    "principal-bound authorization",
    "host consent",
    "no token passthrough",
    "cache isolation"
  ]
}

Что легко сломать

Я не считаю annotations инструмента доказательством безопасности. readOnlyHint или название safe_tool — заявления источника, который может быть недоверенным. Серверные полномочия и реальный код операции важнее описания.

Практика и самопроверка

Разметить угрозы в tool descriptions, ресурсах и ответах внешней системы. Выбрать проверяемую границу защиты.

Я советую сначала предсказать результат, затем изменить один параметр в лаборатории и объяснить разницу. Сохраните небольшой fixture с нормальным и ошибочным случаем для своего проекта. Тренажёр открыт без регистрации; для сохранения ответов на тесты и завершения урока войдите в аккаунт.

В конце страницы — три вопроса. После правильных ответов можно завершить урок; ошибка в следующей тренировке не стирает уже полученное подтверждение этой редакции теста.

На что я опирался

• architecture: первичный источник
• auth-security: первичный источник

Профиль и ссылки проверены 15 октября 2026. Core, deprecated compatibility и extensions в этом курсе помечены отдельно. Примеры объясняют выбранные сценарии; для реализации сверяйте нормативные MUST/SHOULD и schema соответствующей версии.