Segurança MCP em 2026: a lacuna human-in-the-loop na especificação

A própria especificação do Model Context Protocol admite, em linguagem clara, que não pode impor aprovação humana antes de uma ferramenta de IA agir — essa garantia é uma recomendação para a aplicação construída sobre MCP, não uma regra que o MCP verifica. Para qualquer agência que conecta a sua própria IA, ou a de um cliente, a sistemas de negócio reais via MCP, essa única frase é todo o modelo de risco. O protocolo diz à sua IA que ferramentas existem e o que elas afirmam fazer. Se um humano realmente vê e aprova o que está prestes a acontecer fica inteiramente ao critério de quem construiu o cliente.

O que a especificação MCP realmente diz sobre consentimento?

A própria secção “Key Principles” da especificação é direta sobre os limites do que o protocolo garante:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

E depois, imediatamente:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

Aí está a lacuna num parágrafo. Os princípios estão escritos com “must” minúsculo, que sob a convenção que a especificação MCP segue significa recomendação, não requisito ao nível do protocolo. A especificação Tools separada repete a mesma estrutura no seu “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations”, juntamente com orientação de que as aplicações “SHOULD… present confirmation prompts to the user for operations.” Recomendado. Não imposto. Não algo que um servidor MCP possa verificar que um cliente realmente faz.

Isto não é uma falha única do MCP — nenhum protocolo pode forçar uma aplicação construída sobre ele a comportar-se de determinada forma. Mas significa que “a nossa IA está conectada via MCP” não diz nada sobre se um humano está realmente no loop. É uma afirmação sobre a aplicação específica, e tem de ser verificada aí, não assumida pelo nome do protocolo.

O que acontece quando essa lacuna é explorada

Três incidentes documentados mostram o que a lacuna custa na prática, em três pontos diferentes da cadeia.

Asana, junho de 2025 — a falha de isolamento. A Asana lançou a sua integração MCP a 1 de maio de 2025. Um bug de isolamento de tenants foi identificado a 4 de junho, e a integração foi retirada durante cerca de duas semanas enquanto era corrigida. A falha permitiu que dados de uma organização — tarefas, metadados de projetos, detalhes de equipa, comentários e ficheiros carregados — ficassem visíveis através de fronteiras organizacionais. Cerca de 1.000 clientes foram afetados, e a vulnerabilidade existia desde o primeiro dia da funcionalidade. Isto não foi especificamente uma falha de human-in-the-loop — é um lembrete de que a fronteira de isolamento em torno do que uma integração MCP pode alcançar importa tanto quanto quem aprova a chamada.

GitHub, maio de 2025 — o “toxic agent flow”. Investigadores de segurança da Invariant Labs demonstraram um ataque onde um developer pediu a um agente de IA, conectado via servidor MCP do GitHub, para rever issues abertas num repositório público. Uma issue plantada continha instruções escondidas. O agente leu-as e depois usou o seu próprio acesso já autorizado aos repositórios privados do developer para extrair informação sensível e publicá-la num pull request visível no repo público. Cada chamada individual de ferramenta que o agente fez foi uma que o utilizador tinha genuinamente autorizado. O que não estava autorizado — e o que nenhum prompt de aprovação individual teria apanhado — foi a combinação: ler uma issue pública, agir sobre dados privados, publicar externamente. A própria conclusão da Invariant foi direta: “This vulnerability cannot be resolved through server-side patches.” É um problema arquitetural em como as permissões se compõem entre chamadas de ferramentas, não um bug no código do GitHub.

Microsoft, 30 de junho de 2026 — a lacuna de reaprovação. A equipa de segurança da Microsoft publicou um alerta direto sobre uma mecânica incorporada no próprio modelo de confiança: a descrição de uma ferramenta — o texto que um utilizador lê e aprova antes de deixar uma IA usá-la — pode mudar após essa aprovação, e nada no protocolo exige que o cliente pergunte novamente. As próprias palavras da Microsoft: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Uma ferramenta que parecia segura no dia um pode ser silenciosamente redefinida no dia trinta, e um utilizador que a aprovou uma vez não tem razão para saber que aconteceu. A Microsoft descreveu o MCP como “the fastest-growing part of the agentic AI supply chain” — que é exatamente por que esta lacuna específica importa mais a cada mês que passa sem ser endereçada.

Junto com estes, dois CVEs concretos valem a pena conhecer se está a avaliar ferramentas MCP: CVE-2025-49596, uma falha crítica (CVSS 9,4) de execução remota de código na própria ferramenta MCP Inspector da Anthropic, e CVE-2025-6514, uma vulnerabilidade crítica (CVSS 9,6) de injeção de comandos no pacote amplamente usado mcp-remote, desencadeada por um URL de autorização malicioso do servidor. Ambos estão corrigidos, mas ambos ilustram que as ferramentas em torno do MCP tiveram a mesma classe de lacuna que o modelo de confiança do protocolo: coisas que um utilizador razoavelmente assumia serem inertes revelaram-se não ser.

O que “human-in-the-loop” precisa de significar, na prática

Dado que o protocolo não vai impor isto, as perguntas que valem a pena fazer sobre qualquer ferramenta conectada a IA — incluindo a do sSystm — são as que transformam “human-in-the-loop” de slogan em algo verificável:

1. Uma escrita espera realmente por uma pessoa, sempre, ou apenas no primeiro uso? Uma única aprovação no momento da conexão não é a mesma garantia que aprovação por ação.
2. Se a descrição ou comportamento de uma ferramenta muda, isso desencadeia reaprovação, ou entra em vigor silenciosamente? Esta é precisamente a lacuna que a Microsoft assinalou em junho de 2026.
3. O token ou credencial está limitado aos dados de uma organização, ou uma sessão comprometida poderia alcançar entre tenants? Isto é o que falhou na Asana — não o passo de aprovação, mas a fronteira de isolamento por trás dele.
4. Existe um registo de auditoria do que a IA realmente fez, separado do que lhe foi pedido para fazer? Ataques compostos como o caso do GitHub só aparecem em retrospectiva se os passos individuais foram registados.
5. Quem governa a especificação, e quão ativamente o modelo de segurança está a evoluir? O MCP foi doado à Agentic AI Foundation sob a Linux Foundation a 9 de dezembro de 2025, com Anthropic, Block, OpenAI, Google, Microsoft, AWS e Cloudflare todos nomeados como envolvidos — um sinal de que o ecossistema está a consolidar-se em torno de governança partilhada em vez de cada fornecedor corrigir independentemente.

O endpoint MCP do sSystm emite um token por utilizador limitado à organização desse utilizador, e cada escrita que uma IA propõe — através da Build AI integrada ou de um cliente externo conectado — fica como ação pendente até uma pessoa aprovar. Isto não é uma afirmação de que o MCP impõe isto; é o ponto oposto. Como o protocolo não o faz, tem de ser construído deliberadamente na aplicação, e vale a pena verificar explicitamente em vez de assumir a partir de “usa MCP.” Leia mais sobre como funciona a fronteira de aprovação em como IA e humanos partilham o workspace do sSystm, como é o modelo de isolamento na nossa arquitetura de segurança, e a mecânica de conectar IA externa via MCP em como conectar a sua IA à sua agência com MCP.