6️⃣ MCP становится stateless. Как по мне, так это плохо для безопасности, так как теперь каждый запрос должен быть полноценно аутентифицирован, авторизован и проверен.
clientInfo и serverInfo из протокола - самодекларативны и никак не верифицируемы, а значит в полный рост необходимо опираться на проверенную идентичность из OAuth, mTLS или service mesh.2️⃣ Теперь шлюзы, WAF или service mesh могут понимать, какой MCP-метод и какой инструмент вызывается, не разбирая JSON-RPC-тело. Таким образом, можно строить более гибкие политики, например, "агенту разрешен
search, но запрещен execute_sql", "delete_project требует отдельного подтверждения", обращение к административным инструментам направляется на дополнительную проверку, а события можно нормально передавать в API Security Gateway, NDR/NAD, SIEM и observability-платформы.3️⃣ Параметры инструментов тоже можно выносить в заголовки, что позволяет строить более точные политики – разрешить работу только с определенным регионом, запретить прод, отделить тенанты, применять DLP или тарифные ограничения к определенным операциям.
4️⃣ Исправляется реальная проблема OAuth mix-up, когда креды должны храниться с привязкой к конкретному issuer и не могут автоматически переиспользоваться с другим сервером авторизации.
5️⃣ Dynamic Client Registration постепенно выводится из употребления в пользу Client ID Metadata Documents, что позволяет вести белый список доверенных приложений, применять корпоративные политики, проверять перенаправление URI и т.п.
6️⃣ MRTR улучшает подтверждение действий, но создает новый канал социальной инженерии.
7️⃣ Кэширование каталогов инструментов создает риск "устаревших полномочий", когда отозванные инструменты все еще остаются в клиентском кэше, изменившаяся схема параметров еще не обновилась, инструмент стал опасным, а старое описание говорит, что он безопасный, и т.п.
8️⃣ Явные handles вместо скрытой сессии хороши для аудита, но опасны при утечке. Если одного знания handle достаточно для продолжения операции, его утечка в логах, промптах, трассах, истории диалога и т.п. может позволить перехватить чужой workflow или задачу.
9️⃣ Tasks вынесены в официальное расширение: появляются durable handles, polling через
tasks/get и обновление через tasks/update. MCP-вызов перестает быть только мгновенной операцией – агент может запустить длительную задачу, вернуться к ней позже, продолжать действия после завершения пользовательской сессии и т.п. А значит нужно мониторить не только вызываемые инструменты, но и весь жизненный цикл задач.Этот релиз не решает ключевую проблему MCP: протокол по-прежнему соединяет вероятностную модель с инструментами, которые способны читать данные и совершать реальные действия (но это общая проблема любой безопасности ИИ, о чем я уже писал). Сама спецификация честно говорит, что MCP открывает пути к произвольному доступу к данным и выполнению кода, а многие требования к согласию и безопасности не могут быть принудительно обеспечены самим протоколом. Но теперь вокруг него стало чуть легче строить ИБ - API Gateway, Zero Trust, централизованную авторизацию, RBAC/ABAC для инструментов, WAF, журналирование, SIEM-мониторинг и т.п.
То есть MCP стал более защищаемым, но не стал безопасным по умолчанию.
#ии #архитектура
