Segurança de WebMCP no Angular: o agente que chama suas tools pode ser sequestrado

O modelo de ameaça em uma frase#

Uma WebMCP tool é uma capacidade que você entregou pro agente de IA que o usuário estiver rodando, e esse agente lê páginas. O risco todo sai daí. O agente pode estar carregando instruções que pegou em algum lugar que o usuário nunca checou, uma review, um comentário, uma thread de suporte, um PDF, e essas instruções podem mandar ele chamar a sua tool findOrder ou cancelSubscription. Isso é prompt injection chegando numa função de verdade do seu app, e a tool não distingue um pedido que o usuário quis de um que uma página hostil plantou.

Agora some a parte que deixa isso afiado. O seu execute roda no browser do usuário, dentro da sessão do usuário, com os cookies e tokens do usuário. Um agente sequestrado chamando a sua tool age com a autoridade do usuário, com instruções que o usuário nunca deu. É essa a régua de toda decisão daqui pra frente: trate cada tool exposta como um endpoint público e autenticado cujo chamador é hostil, porque, na prática, é isso que ela é.

A mecânica de registrar tools, bootstrap, rota, service ou um Signal Form, está no guia de setup do WebMCP. Isto aqui é a camada de segurança que fica em cima, e é a parte que eu não publicaria sem.

O schema é documentação, não fronteira de confiança#

O primeiro instinto é se apoiar no inputSchema. Não se apoie. O Angular é explícito: ele não valida que as entradas que o agente passa de fato batem com o JSON schema declarado. O schema diz ao agente como chamar a tool; ele não barra nada. Um agente sequestrado, ou só confuso, pode entregar ao seu execute uma string onde você declarou número, um id de um registro que este usuário não pode ver, ou um payload três campos maior do que você esperava.

Então a validação é trabalho seu, no topo de todo execute, antes das entradas tocarem em qualquer coisa. Faça o parse, não assuma. Recuse o que você não declarou. Confira que o id pertence a algo que este usuário tem permissão de ler. É a mesma postura que você teria com um corpo de request de um cliente não confiável, porque o agente é exatamente isso.

execute: (raw) => {
  // O Angular não impõe o inputSchema. Valide antes de tudo.
  const orderId = String(raw?.orderId ?? '');
  if (!/^[A-Z0-9-]{6,20}$/.test(orderId)) {
    return { content: [{ type: 'text', text: 'Id de pedido inválido.' }] };
  }

  const orders = inject(Orders);
  // Autorize para ESTE usuário no servidor, não só aqui no browser.
  return { content: [{ type: 'text', text: orders.summaryForCurrentUser(orderId) }] };
},

Menor privilégio: leia antes de escrever, confirme antes do estrago#

O controle de segurança mais barato é não expor a tool. Um agente que consulta um pedido é um risco diferente de um que cancela o pedido. Comece só-leitura. Uma tool que lê e devolve dado tem um raio de impacto limitado; uma tool que altera, cobra, apaga ou concede acesso entrega a um chamador automatizado, e talvez sequestrado, uma alavanca no seu negócio.

Quando uma tool precisa alterar dado, ponha um humano no meio. O agente pode preparar a ação, preencher o formulário, dizer qual pedido cancelar, mas uma pessoa confirma antes de efetivar. Expor um Signal Form como tool encaixa direitinho aqui: o agente preenche os campos e o usuário revisa e envia, em vez de o agente chamar um execute que dispara e esquece.

Mantenha enxuto também o que você devolve. Uma tool que responde findUser e devolve o registro inteiro acabou de deixar todo campo, email, telefone, flags internas, ao alcance do agente e de quem está conduzindo ele. Devolva o mínimo que a tarefa precisa, não a linha toda.

Autorize no servidor, dê escopo no cliente#

Dois controles, dois lugares, e eles não se substituem. No cliente, o exposedTo limita quais origens podem chamar uma tool, a mesma lógica do CORS, e um AbortSignal derruba a tool quando o contexto dela acaba. Ponha o exposedTo no conjunto mais estreito que você consiga justificar. Mas é uma cerca do lado do cliente, e cerca do lado do cliente não autoriza.

A autorização que vale está no servidor. O seu execute roda com a sessão do usuário, então a chamada chega no seu backend já autenticada como o usuário. É justamente por isso que você revê, no servidor, se este usuário pode fazer esta coisa neste registro, a cada chamada, igual a qualquer outro request. O browser não é fronteira de confiança, e um agente dentro do browser é menos ainda.

Aproveite e fique de olho no ciclo de vida. Uma tool que sobrevive à própria rota é superfície exposta que você esqueceu que tinha. O cleanup com escopo de rota é o mecanismo pra isso, e o bug aberto de tool duplicada em volta dele é um bom lembrete de testar de verdade se as tools se desregistram quando você navega pra fora, em vez de supor que sim.

O que eu ainda não publicaria#

Tudo isso está em cima de uma API experimental sobre uma spec em rascunho. O ponto de entrada já saiu de navigator para document.modelContext no meio do ciclo, e a doc avisa que as APIs podem mudar fora de major. Pra segurança isso dobra a cautela: você está endurecendo uma superfície cujo formato pode mudar debaixo de você, então o que você expõe é o que você re-audita a cada minor do Angular, não só nos majors.

Onde eu fico: faço spike de tools só-leitura atrás de uma flag, em rotas internas ou de baixo risco, e trato o trabalho de segurança como a entrega de verdade, a validação de entrada, a autorização no servidor, o padrão de humano no meio pra qualquer coisa que escreve. Isso sobrevive aos renames da API. O que eu não colocaria no app público é uma tool que mexe em dinheiro, muda identidade ou faz algo destrutivo, enquanto o chamador é um agente que pode ser convencido de qualquer coisa e a spec por baixo ainda é rascunho. A ideia é boa. O chamador é que ainda não é confiável.