Глава 12 — Закаливание протокола и защиты
Двенадцатый пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. В котором каждая угроза предыдущей главы получает защиту, ни одна из защит не серебряная пуля, и только их композиция даёт позицию, которую реально можно развернуть.
Почему существует эта глава
Протокол не становится безопасным от факта развёртывания. Он становится безопасным, когда развёрнут внутри стека, компенсирующего предпосылки, которые делает голый протокол. Глава 11 каталогизировала угрозы; эта глава проходит защиты на инженерной глубине. Криптографическая аттестация возможностей закрывает классы обнаружения и capability escalation. Дисциплина OAuth 2.1-скоупов с делегированными пользователем токенами закрывает классы Deputy и Passthrough. Ограниченные времена жизни сессий закрывают класс session hijack. Песочница сдерживает компрометации, которые превентивные меры пропустили. Human-in-the-loop ловит разрушительные операции, которые остальной стек должен был бы автоматизировать, чтобы быть полезным. Каждая защита оставляет остаточный риск; именно композиция делает остатки достаточно малыми, чтобы их можно было оборонять на практике.
12.1 AttestMCP: криптографическая аттестация возможностей
Первая защита адресует проблему, проходящую почти через каждую угрозу: у хоста нет способа верифицировать, что сервер, с которым он говорит, — то, чем он себя называет. AttestMCP — также называемая MCPSec или signed capability manifests — добавляет слой криптографической аттестации над структурой сообщений протокола. У издателя есть долгоживущий подписной ключ, зарегистрированный в директории или transparency-логе. Полный манифест возможностей хешируется и подписывается в момент релиза. Хост проверяет подпись на initialize против ключа издателя в файле и либо допускает сервер, либо помещает на карантин, либо отказывает в соединении.
Выгоды реальны. Typosquat-ы не могут произвести валидную подпись от легитимного издателя. Capability escalation через уведомления list_changed становится детектируемой, потому что новый манифест требует новой подписи. Тонкая политика — «доверять серверам, опубликованным GitHub, для репозиториев, но не для почты» — становится обеспечиваемой, потому что идентичность издателя теперь проверяема, а не заявлена. Цены тоже реальны: издатели должны держать инфраструктуру подписи, transparency-логам нужен доверенный оператор, а слой политики хоста должен понимать отзыв. Честный фрейм — AttestMCP это серьёзная инженерия, а не галочка. И у неё есть пробел, который стоит назвать: манифест подписывает то, что сервер говорит о себе, а не то, что он делает в рантайме. Подписанное объявление безобидного инструмента всё ещё может отгрузить эксфильтрирующую реализацию. Аттестация необходима, но недостаточна, — поэтому существует остаток главы.
12.2 OAuth 2.1-скоупы и ограниченные времена жизни сессий
Второй кластер ужесточает модель учётных данных и сессий. Flow OAuth 2.1 зрелы; инженерия в том, чтобы использовать их правильно. Первая дисциплина — узкие скоупы: запрашивайте только то, что нужно объявленной поверхности инструментов. Чем у́же скоуп, тем меньше радиус взрыва. Дисциплина труднее, чем звучит, потому что upstream-сервисы часто определяют скоупы грубо, а узкий путь утомителен; широкие скоупы работают с первого раза и ощущаются как прогресс. Цена узких скоупов оплачивается инженером; цена широких — пользователем, когда что-то идёт не так.
Защита от Confused Deputy, которую одна дисциплина скоупов не даёт, — делегированные пользователю токены. Где upstream это поддерживает, каждый пользователь проходит собственный OAuth-flow, и сервер действует токеном пользователя, а не собственной сервисной идентичности. Заместитель исчезает, потому что сервер больше не действует своим авторитетом. У Token Passthrough другое лекарство: не пересылайте токены. Сервер держит собственные учётные данные, установленные в момент регистрации, и граница между хостом и сервером никогда не несёт токен. Ограниченные времена жизни сессий адресуют hijack: минуты для высокорисковых операций, часы для рутинных, с устойчивой идентичностью workflow поверх, чтобы многочасовая задача могла обновлять транспортные сессии без переспроса пользователя каждые пятнадцать минут. Привязка возможностей к сессии и пере-подтверждение возможностей при продлении сессии завершают дисциплину — оба являются работой управления состоянием, которую хост должен делать явно, и многие реализации этого не делают.
12.3 Песочница и runtime-изоляция
Третий кластер признаёт, что не каждую угрозу можно предотвратить, и что обороноспособная позиция обязана сдерживать ущерб, когда превенция не сработала. Песочница процессов для локальных серверов — seccomp в Linux, App Sandbox в macOS, AppContainer в Windows, gVisor для более сильной изоляции — отказывает в доступе к файловой системе, сети и процессам по умолчанию и выдаёт только конкретные доступы, нужные серверу. Скомпрометированный сервер, пытающийся прочесть файл паролей или эксфильтровать на endpoint атакующего, обнаруживает операцию отказанной на уровне ОС — не потому, что код сервера воздержался, а потому, что песочница. Сетевая политика для удалённых серверов — mutual TLS, allowlist endpoint-ов, фильтрация egress — сужает поверхность, до которой может дотянуться скомпрометированный удалённый сервер. Изоляция содержимого внутри хоста обращается с возвращённым содержимым с соответствующей подозрительностью до того, как оно попадёт в контекст модели: маркеры недоверенности, санитизация HTML, отказ следовать встроенным URL. Песочница вызовов инструментов через capability-aware-политики позволяет хосту изучать аргументы вызова и решать, разрешить ли, отказать или эскалировать на одобрение пользователя. Конкретный риск, который стоит назвать, — побочно-канальная эксфильтрация через легитимные инструменты — злонамеренная модель, кодирующая учётные данные в поисковом запросе, — которую слой политики ловит, инспектируя аргументы, а не endpoint-ы. Изоляция цепочки поставки замыкает контур: хеш бинарника проверяется при установке и обновлении против подписанного значения в transparency-логе, чтобы поддельный бинарник не мог запуститься, даже если манифест проходит.
12.4 Human-in-the-loop: ворота одобрения
Четвёртый кластер признаёт, что некоторые операции никогда не должны автоматизироваться. Разрушительные, необратимые или высокого воздействия вызовы — отправка денег, удаление файлов, модификация production — заслуживают явного человеческого решения в момент, когда они происходят. Механизм — HITL-ворота, и инженерия — в том, чтобы сделать их эффективными без того, чтобы система стала неюзабельной. Категоризируйте по обратимости: операции только для чтения проходят автоматически; меняющие состояние ворота. Презентуйте осмысленно: модальное окно «Разрешить выполнение инструмента?» — это резиновый штамп; полезные ворота показывают инструмент, полные аргументы, последствие на ясном языке и провенанс. Избегайте усталости одобрения батчевым контекстным одобрением, где пользователь, инициировавший «отправь счета клиентам прошлого квартала», одобряет батч один раз, а не каждое письмо двадцать раз. Маршрутизируйте операции с высокими ставками вне диапазона — аппаратный токен, второе устройство, step-up-аутентификация, заимствованная из финансовой индустрии. Держите операции видимыми, аудируемыми и отменяемыми. Sampling-инициированные вызовы проходят через те же ворота, что и агент-инициированные; боковой канал серверно-инициированного инференса не получает права завершиться в побочное действие незаметно для пользователя.
Что подготавливает глава 12
Безопасностная половина инженерной картины теперь завершена. Другая половина — фреймворки, паттерны развёртывания, характеристики производительности и тестирование, подтверждающее, что система работает в продакшене, — это то, чем берутся остальные главы. Глава 13 открывает эту дугу, проходя фреймворки и облачные интеграции, приземлившиеся в 2025–2026 годах: Strands с Amazon Bedrock, AWS state-layer-паттерны, Microsoft Agent Framework, LangChain и Semantic Kernel. Фреймворки важны, потому что никто не строит продакшен MCP из голого протокола, и выбор между ними формирует инженерную и security-позицию способами, которые слой протокола в одиночку не определяет.
Дальше — Глава 13: Фреймворки и облачная интеграция. Strands с Bedrock, AWS state layer, Microsoft Agent Framework, LangChain, Semantic Kernel — и три продакшен-паттерна интеграции, к которым команды приходят независимо.
