webMCP Não é a Nova Camada de Acessibilidade—É uma Nova Superfície de Ataque

O artigo de Sylwia Laskowska sobre webMCP é inteligente, engraçado e genuinamente agradável — e ela é explícita ao afirmar que é experimental, não uma recomendação para produção. Isso não é uma refutação. É uma reinterpretação: a mesma demonstração, vista através da lente de superfícies de risco e governança. Minha preocupação não está com a intenção dela — está com a facilidade com que os novatos que constroem sistemas de cliente podem interpretar uma demonstração lúdica como um padrão a ser copiado.

I. A Demonstração Foi Engraçada Porque o Risco É Real

No artigo de Sylwia, ela escreve:

webMCP permite que sites exponham informações estruturadas sobre ações disponíveis…

Essas "ações" não são dicas descritivas. Elas são funções chamáveis conectadas diretamente à lógica da aplicação.
Na demonstração dela, essas ações incluem:

• contratar_funcionario
• demitir_funcionario
• reescreverEmRust
• pivotarParaAgentes

É hilário em um aplicativo de brinquedo. É catastrófico em um real. O humor funciona precisamente porque o risco subjacente é real.

II. A Suposição Oculta: Expor Ações É Neutro

webMCP é enquadrado como "como metadados de acessibilidade." Mas metadados de acessibilidade são descritivos. Metadados webMCP são executáveis.

Essa é a inversão conceitual que a maioria dos novatos vai perder.

III. Vulnerabilidade Estrutural #1: Superfície de Ação Ilimitada

Se uma ferramenta existe, um agente pode chamá-la. Não há:

• modelo de permissão
• escopo de capacidade
• limitação de taxa
• validação de intenção
• envelope de segurança

Sylwia brinca: "alguém definitivamente dará a um agente acesso a fireEmployee(), o agente demitirá toda a empresa…"

Isso não é uma hipótese. É o modo de falha exato.

IV. Vulnerabilidade Estrutural #2: Excesso de Poder do Agente

O simulação de CEO dela demonstra o problema perfeitamente:

o agente selecionou as ferramentas apropriadas e imediatamente começou a trabalhar.

Agentes agem com alta confiança mesmo quando seu modelo de mundo está incompleto. webMCP lhes dá alavancas diretas no estado da aplicação. Este é o mesmo problema de excesso de poder que o MCP tem — apenas movido para o navegador.

V. Vulnerabilidade Estrutural #3: Fragilidade do Protocolo

webMCP depende de descrições escritas por humanos:

html<form mcp-name="createSupportTicket"
mcp-description="Criar um novo ticket de suporte ao cliente">

Se a descrição estiver errada, incompleta ou enganosa, o agente agirá incorretamente.

Um comentarista no artigo de Sylwia capturou isso perfeitamente: "Os papéis ARIA foram a parte fácil — a parte difícil foi verificar se o fluxo realmente funciona."

webMCP está na fase ARIA. Mas, ao contrário do ARIA, as consequências não se limitam à usabilidade. Elas incluem mutação de estado, perda de dados e escalonamento de privilégios.

VI. O Navegador Torna Tudo Pior

webMCP herda os riscos do MCP e adiciona riscos específicos do navegador:

• amplificação de sequestro de sessão autenticada
• orquestração de agentes entre sites
• problemas de delegado confuso
• ativação de agentes por impulso
• sem modelo de autorização entre aplicações

Um comentarista colocou de forma direta: "Estamos construindo rodovias antes de semáforos." Eles estão certos.

VII. Uma Melhor Enquadramento: Camada de Integração de Alto Risco, Não Acessibilidade

webMCP não é acessibilidade. Não é aprimoramento progressivo. Não é uma camada de compatibilidade inofensiva.

É uma interface privilegiada para agentes autônomos, e requer:

• autorização
• auditoria
• portões de segurança
• política
• envelopes de capacidade
• validação de transição de estado

Se você não exporia uma ação em sua API pública, não deveria expô-la no webMCP.

Encerramento

O artigo de Sylwia é divertido, imaginativo e genuinamente valioso como uma exploração do que o webMCP poderia permitir. Os riscos são reais, estruturais e fáceis de perder — especialmente para novatos.

webMCP pode se tornar parte do futuro da web. Mas se isso acontecer, precisará da mesma rigor que aplicamos a qualquer interface privilegiada.

Até lá, trate-o não como uma camada de acessibilidade, mas como uma superfície de ataque.