O novo whitepaper 'Lethal by Design' da Noma Security traça uma linha arquitetural mais nítida entre dois mecanismos de extensão de agentes IA que devs vinham tratando como aproximadamente equivalentes: servidores MCP e Skills (o padrão Claude Skills, que se espalhou pra outras superfícies de agentes). O número manchete — cerca de um a cada quatro servidores MCP analisados expõe risco de execução de código através de oito categorias de capacidades — é a parte que se cita. A metodologia não está totalmente divulgada no resumo público (tamanho de amostra, cobertura de registro, e definição exata de "risco de execução de código" através das categorias estão todos pouco claros), então trate o percentual como sinal direcional, não como resultado de auditoria peer-reviewed. A observação arquitetural substantiva embaixo importa mais.
Essa observação: ferramentas MCP e Skills parecem similares da perspectiva do autor do agente mas vivem em lados opostos de uma fronteira de observabilidade. Quando um agente chama uma ferramenta MCP, defensores veem os parâmetros saindo e as respostas voltando — estruturados, logáveis, enumeráveis como código-fonte. Skills são diferentes. O agente carrega um conjunto de instruções textuais no seu contexto de raciocínio, e o que acontece depois se desenrola dentro do raciocínio do modelo, onde ferramentas de observabilidade não conseguem seguir. Você pode auditar o arquivo que entrega o Skill; não pode auditar as decisões runtime que um modelo toma uma vez que esse Skill esteja carregado em contexto. Isso não é gap de tooling que melhor cobertura de SIEM fecha; é estrutural a como Skills funcionam.
O whitepaper nomeia cinco padrões de incidentes reais pra ancorar a abstração. **ContextCrush**: documentação envenenada leva a exfiltração de arquivos locais. **ForcedLeak**: dados CRM maliciosos disparam consultas a registros sensíveis. **DockerDash**: metadados de imagem Docker envenenados disparam execução de comando. Os **incidentes Replit e Amazon Q** que já aconteceram — alucinações de agentes resultando em deleção de produção. **Manipulação de memória** pra transferências financeiras fraudulentas recorrentes. Essas não são especulativas; mapeiam pra exposições arquiteturais específicas que existem *hoje* em deployments de agentes em produção. Cada uma é uma forma diferente de "o agente foi autorizado a fazer algo que não deveria, e o stack de segurança em volta não pegou porque a decisão relevante aconteceu numa camada que não emite sinais observáveis".
O framework defensivo da Noma é "No Excessive CAP" — **Capacidades** (allowlist ferramentas estreitas, pin de versões MCP), **Autonomia** (gates de aprovação pra ações irreversíveis), **Permissões** (credenciais com escopo de usuário e expiração, não contas de serviço estáticas). Pra devs, a leitura prática é que o stack de segurança de agentes está bifurcando ao longo das mesmas linhas do problema de observabilidade. Ferramentas que funcionam pra MCP — firewalls fora-de-processo como Pipelock, enforcement estilo gateway — não ajudam com Skills, porque Skills não fazem chamadas externas que um proxy possa interceptar; eles moldam o comportamento do modelo de dentro. Se seu deployment de agente usa MCP *e* Skills, você precisa de duas posturas de segurança separadas: uma camada de enforcement pra MCP na fronteira de rede, e uma disciplina de *revisão de conteúdo* pra Skills antes que entrem no contexto do modelo. O whitepaper está em go.noma.security/lethal-by-design.