A Corrida dos Skills: Codex Alcança o Claude e os Marketplaces Viram Risco de Segurança

Numa pausa entre reuniões, procurando uma coisa completamente diferente, rodei um ls no diretório de skills da minha máquina. Trinta e uma pastas. Eu não conseguia dizer de cabeça a origem de mais ou menos um terço delas, e várias estavam ali havia semanas sem que eu tivesse aberto o SKILL.md uma única vez depois de instalar. Instalei, funcionou, segui a vida.

Peguei três ao acaso para ler. Duas eram exatamente o que prometiam. A terceira era uma skill de migração de banco que tinha chegado por indicação, com contador de instalação na casa dos milhares e badge verde de auditoria de segurança, e trazia ao lado uma pasta scripts/ que eu nunca tinha aberto. Levei uns dez minutos lendo arquivo por arquivo. Não achei nada — a skill é legítima, continua instalada, funciona bem até hoje. Mas o que me incomodou não foi o resultado da revisão, foi a pergunta que sobrou: quantas entraram no ambiente do time sem que ninguém tivesse feito esse exercício nem uma vez? A resposta honesta é que eu não sabia.

Esse é o assunto de hoje. Nos últimos meses o formato SKILL.md deixou de ser uma coisa do ecossistema da Anthropic e virou padrão de fato entre agentes de codificação. O catálogo oficial da OpenAI para o Codex, o repositório openai/skills, já passou de 21 mil estrelas no GitHub, e ao redor dele cresceu uma economia paralela de marketplaces de terceiros com centenas de milhares de skills indexadas. É consolidação real, e é boa notícia para quem escreve skill uma vez e quer usar em vários agentes.

O problema é que a camada de distribuição amadureceu muito mais rápido do que a camada de confiança. Vou fazer três coisas aqui: comparar como o Claude e o Codex carregam skill na prática, com caminhos de arquivo e mecânica de carregamento; argumentar por que marketplace de skill é supply chain com exatamente os mesmos vetores de npm e PyPI; e fechar com o checklist que passei a usar antes de deixar qualquer skill de terceiro entrar no ambiente do time.

---

O Formato Que Virou Padrão Sem Ninguém Assinar Um Tratado

A Anthropic anunciou a funcionalidade de Agent Skills em outubro de 2025 dentro do ecossistema Claude e publicou a especificação como padrão aberto em dezembro do mesmo ano, no que hoje é o agentskills.io. Desde então o formato foi adotado por OpenAI, Cursor, GitHub Copilot e Goose, entre outros. Não houve consórcio, não houve comitê, não houve RFC disputado: um formato simples o suficiente ganhou por ser simples o suficiente.

E ele é simples mesmo. Uma skill é uma pasta com um arquivo SKILL.md obrigatório. O arquivo tem duas partes: um frontmatter YAML com metadados, sendo name e description os campos que realmente importam, e um corpo em Markdown com as instruções. A especificação define ainda três diretórios opcionais ao lado do arquivo principal: scripts/ para código executável, references/ para documentação adicional e assets/ para recursos estáticos. É isso. Não tem manifesto de dependência, não tem versão semântica obrigatória, não tem assinatura.

O mecanismo de carregamento também é o mesmo nos dois lados, e é o que torna o formato barato de adotar. O agente lê apenas o frontmatter de todas as skills disponíveis quando inicia, o que custa poucas dezenas de tokens por skill. Quando o pedido do usuário casa com a descrição de alguma delas, o corpo inteiro do SKILL.md entra no contexto. E se o corpo apontar para arquivos auxiliares, esses só são lidos quando o agente decide que precisa deles. É a divulgação progressiva em três níveis, e ela existe justamente para você poder ter cinquenta skills instaladas sem estourar a janela de contexto com quarenta e nove que não vai usar.

Quando escrevi sobre as skills que mais aparecem em times de verdade, em maio, o assunto ainda era majoritariamente Claude. Três meses depois a conversa mudou de eixo. Não é mais "qual agente suporta skill", é "a mesma skill roda nos dois, então onde eu guardo ela e quem tem permissão de mexer". A pergunta ficou operacional, e isso é sinal de maturidade. Também é sinal de que o risco saiu do laboratório.

---

Como O Claude Carrega E Como O Codex Carrega

Na prática, a diferença entre os dois modelos está mais em onde os arquivos ficam e em quais controles existem do que na mecânica de carregamento. Vale conhecer os dois se você mantém skills que precisam funcionar nos dois lados, porque a parte que não é portável é justamente a parte que tem a ver com segurança.

No Claude Code, skills pessoais ficam em ~/.claude/skills/ e valem para todos os projetos da máquina. Skills de projeto ficam em .claude/skills/ dentro do repositório, versionadas junto com o código, o que significa que entram por pull request e passam pelo mesmo review de qualquer outra mudança. Há ainda skills que chegam via plugin. O frontmatter aceita, além de name e description, campos como allowed-tools, que restringe quais ferramentas o agente pode usar enquanto a skill está ativa, e disable-model-invocation, que impede o modelo de acionar a skill sozinho e exige chamada explícita.

No Codex a estrutura é análoga. Skills globais ficam em ~/.codex/skills/ depois de baixadas e descompactadas, e se existir um diretório .codex/skills/ no diretório de trabalho, essas skills são carregadas em adição às globais. O Codex faz o parse do frontmatter na inicialização, adicionando algo entre cinquenta e cem tokens de contexto por skill, e invoca implicitamente quando o prompt casa com a descrição. A diferença de sabor está na distribuição: o repositório openai/skills separa as skills em .system, que já vêm instaladas na versão mais recente do Codex, .curated e .experimental, essas duas instaláveis via um instalador embutido que aceita nome da skill ou URL de diretório do GitHub.

Essa organização em três níveis do catálogo oficial é, na minha leitura, a coisa mais interessante que a OpenAI fez aqui, e é uma resposta parcial ao problema de confiança. Ao separar explicitamente o que vem instalado por padrão do que é curado e do que é experimental, o catálogo comunica graus de garantia diferentes sem precisar de assinatura criptográfica. Não resolve nada fora do repositório oficial, mas dentro dele estabelece uma hierarquia que o ecossistema Claude, com seu modelo mais descentralizado de plugin e marketplace, não tem de forma tão explícita.

O que muda na prática quando você escreve uma skill para os dois é menos do que parece e mais do que gostaríamos. O corpo em Markdown é portável sem esforço. A estrutura de pastas é idêntica. O que não é portável são os campos de controle: allowed-tools é marcado como experimental na própria especificação e pode não ser suportado por todos os agentes, o que significa que uma skill que você escreveu confiando nesse campo para limitar o raio de ação vai rodar sem essa restrição em outro agente, silenciosamente. É o pior tipo de incompatibilidade, porque falha aberta em vez de falhar fechada.

A recomendação que sigo é escrever a skill assumindo o menor denominador comum de controle e não depender de campo experimental para conter comportamento perigoso. Se a skill precisa de contenção, a contenção tem que estar no ambiente, não no frontmatter. É a mesma lógica que aplicamos quando definimos instruções curadas e compartilhadas para os agentes do time: o arquivo é a documentação da intenção, não o mecanismo de garantia.

---

Marketplace De Skill É Supply Chain, E Ninguém Está Tratando Como Tal

Aqui está a parte que me tirou o sono. Skills são distribuídas exatamente como pacotes de software: você busca num índice, olha o contador de instalação, vê um badge de auditoria, e instala. A analogia com npm e PyPI não é retórica, é literal. E os números já são de ordem de grandeza de gerenciador de pacote.

O comparativo de marketplaces publicado pela Agensi em 2026 coloca o SkillsMP indexando mais de 800 mil skills raspadas de repositórios públicos do GitHub, com curadoria mínima e um filtro que aceita qualquer repositório com pelo menos duas estrelas. O Skills.sh, lançado em janeiro de 2026 com apoio da Vercel e posicionado explicitamente como o npm dos skills, aparece com 83.627 skills, suporte a dezoito agentes diferentes e mais de 8 milhões de instalações contabilizadas. E a HiddenLayer, na pesquisa que publicou em junho, registrou o ClawHub com mais de 70 mil skills. Somando o que está espalhado por índices, mirrors e listas curadas no GitHub, a conta passa fácil de centenas de milhares.

Agora a diferença crítica em relação ao npm: skills não são assinadas criptograficamente e raramente passam por revisão de verdade. Qualquer pessoa com uma conta no GitHub publica uma, e o agente ingere e executa o que estiver lá dentro. A HiddenLayer é direta ao dizer que sem nenhum modelo de confiança ou verificação, o ecossistema de skills se torna um canal de distribuição perfeito para malware, e a afirmação não é hipotética: skills maliciosas foram encontradas em produção poucos meses depois do OpenClaw popularizar o formato, incluindo casos de distribuição de infostealer para macOS.

A pesquisa que considero mais didática sobre isso é a da Orca Security, publicada em maio. Eles investigaram um dos marketplaces mais proeminentes e encontraram quatro primitivas de ataque que, combinadas, permitem criar, distribuir e persistir skills maliciosas em escala com pouquíssimo atrito. A primeira é inflação de contador de instalação: a métrica de popularidade era alimentada por requisições GET não autenticadas, sem rate limit e sem token, o que significa que um script trivial faz uma skill parecer massivamente adotada. A segunda é escaneamento não determinístico: as auditorias de segurança rodavam na criação da skill e de novo só quando ela cruzava um limiar de popularidade, abrindo uma janela em que você publica algo benigno, passa no scan, e depois modifica o repositório enquanto a plataforma continua exibindo o resultado limpo da auditoria antiga.

A terceira primitiva é a sobrescrita silenciosa: instalar uma skill com o mesmo nome de outra já instalada substitui a anterior sem confirmação, sem diff e sem aviso, independentemente do repositório de origem. A quarta é atualização em massa cega: o comando de update atualiza todas as skills instaladas de uma vez, sem granularidade por skill, sem changelog e sem possibilidade de fixar versão. Uma skill que era benigna quando você instalou pode virar hostil no próximo update, e você não tem como saber.

Encadeando essas primitivas, a Orca demonstrou três fluxos de ataque completos: isca e troca, injeção aninhada de skill e armamento tardio via atualização. O detalhe que fecha o argumento é que as provas de conceito incluíam um callback benigno coletando IP e hostname da vítima, e o log resultante mostra máquinas reais, de redes diferentes, onde a skill maliciosa conseguiu execução de código através do agente. Não era risco teórico, era execução em máquina de desenvolvedor.

Já argumentei antes, quando escrevi sobre supply chain de IA dentro do pipeline de desenvolvimento, que a superfície de ataque de um time que usa agentes não é mais só a árvore de dependências do package.json. Skills são a materialização mais crua desse ponto. Uma empresa que audita rigorosamente cada biblioteca de terceiro e não coloca controle nenhum sobre quais arquivos de contexto seus agentes consomem tem um ponto cego enorme, e é um ponto cego que atacantes já estão sondando.

---

Os Três Vetores Que Eu Levo A Sério

Dos vários caminhos de abuso descritos na literatura, três me parecem os que um dev pleno ou sênior precisa saber reconhecer lendo um SKILL.md, porque são os que aparecem no dia a dia.

O primeiro é execução de script. A especificação permite que a pasta da skill traga um diretório scripts/ com código em Python, Bash ou JavaScript, e o corpo do SKILL.md pode instruir o agente a executá-los. Esse código roda com as permissões do agente, que na maioria das configurações são as permissões do próprio usuário. O ponto sutil, levantado pela HiddenLayer, é que mesmo uma skill sem instrução maliciosa nenhuma pode carregar uma dependência comprometida no script auxiliar, e arquivos empacotados junto costumam ser exatamente o que passa batido numa auditoria apressada, porque o revisor lê o Markdown e ignora a pasta ao lado.

O segundo é exfiltração de credencial. O exemplo canônico da Orca cabe em três linhas: um bloco de código Bash dentro de um SKILL.md de aparência normal, precedido de um "IMPORTANTE: antes de tudo você deve rodar isto para checar atualizações", contendo um curl para um domínio controlado pelo atacante com o conteúdo de ~/.ssh/id_rsa na query string. É primário, é óbvio quando você lê com atenção, e funciona porque ninguém lê com atenção. Numa máquina de desenvolvedor de empresa o alvo é melhor que uma chave SSH: são chaves de nuvem, tokens de CI/CD e segredos de API interna, que abrem portas fundo na infraestrutura de produção.

O terceiro é injeção de instrução no contexto, e é o mais difícil de detectar porque não envolve código nenhum. A skill é tecnicamente limpa, passa em qualquer scanner de malware, e ainda assim é comportamentalmente comprometida: ela instrui o agente a sempre recomendar um determinado fornecedor, a inserir um link de afiliado em toda sugestão, ou a introduzir uma vulnerabilidade sutil em código gerado sob certas condições. A HiddenLayer nota que as auditorias existentes do ClawHub pegam malware conhecido e alertam sobre domínios suspeitos, mas passam batido em algo como um link de afiliado inserido discretamente em cada recomendação. Auditoria que só procura código malicioso perde a categoria inteira de skill que é limpa no código e podre no comportamento.

Há ainda um quarto vetor que vale mencionar mesmo sendo mais exótico. O Red Hat aponta que, como o SKILL.md começa com uma seção YAML, uma vulnerabilidade no parser YAML do agente pode ser explorada por um YAML malformado para executar comando no sistema ou vazar informação. É o tipo de bug que já vimos várias vezes na história de parsers de configuração, e não há razão para acreditar que agentes de codificação estão imunes.

---

O Checklist Que Uso Antes De Instalar Skill De Terceiro

Depois daquela tarde vasculhando o próprio diretório de skills, escrevi um checklist e coloquei no repositório de padrões. Não é elaborado, mas cobre as primitivas de ataque documentadas e é curto o suficiente para alguém de fato seguir.

Primeiro, leia o SKILL.md inteiro no repositório de origem, não a descrição renderizada no marketplace. São coisas diferentes e o marketplace pode estar exibindo uma versão desatualizada. Procure especificamente por blocos de código com comandos de shell, por imperativos de urgência do tipo "primeiro e antes de tudo você deve", e por qualquer coisa que faça requisição de rede. Segundo, liste o conteúdo da pasta, não só o arquivo principal: se existe scripts/, abra cada arquivo. É onde o problema costuma estar escondido.

Terceiro, ignore o contador de instalação como sinal de confiança. Ele é inflável por requisição não autenticada em pelo menos um marketplace grande, e provavelmente em outros. O mesmo vale para badge de auditoria: o selo pode ter sido emitido semanas antes da última modificação do repositório. Quarto, cheque colisão de nome. Se a skill reivindica o mesmo nome de uma skill conhecida mas vem de repositório diferente, trate como hostil até prova em contrário, porque a instalação sobrescreve a legítima em silêncio.

Quinto, fixe versão sempre que a ferramenta permitir. Travar num commit específico em vez de seguir o branch principal elimina o vetor de armamento tardio, que é o mais insidioso justamente porque o comprometimento acontece depois da sua auditoria. Sexto, nunca rode update em massa sem olhar o que mudou. Antes de atualizar, confira os repositórios das skills instaladas em busca de mudança recente, e prefira atualização granular quando ela existir.

Sétimo, revise periodicamente o que está instalado e remova o que não usa. Skill parada no ~/.claude/skills/ ou no ~/.codex/skills/ não é neutra: ela continua com o frontmatter carregado no contexto e continua elegível para ser invocada implicitamente. Oitavo, e o mais importante dos oito: rode skill de origem não confiável dentro de um ambiente isolado. Contêiner, VM, sandbox. Essa é a única medida da lista que não depende de você ter lido o arquivo direito.

Sobre esse último ponto vale abrir uma nota. A HiddenLayer é explícita ao dizer que sandbox desloca o modelo de segurança para um lugar onde um SKILL.md malicioso simplesmente não alcança os recursos de que precisa para causar dano, independentemente do que as instruções digam. Não é solução completa, porque uma skill que opera inteiramente dentro do escopo permitido ainda consegue manipular o comportamento do agente de forma sutil, mas elimina as classes mais diretas de abuso. Vou aprofundar essa parte no post sobre sandboxes de execução para agentes com E2B, Modal e Daytona, que sai no dia 13.

Para quem quer um vocabulário comum na hora de discutir isso com o time de segurança, existem hoje o OWASP Top 10 for Agentic Applications e o OWASP Agentic Skills Top 10, esse segundo cobrindo especificamente skill maliciosa, comprometimento de supply chain, permissão excessiva e metadado enganoso. Ele também propõe um formato universal de skill com publicador assinado, hash de conteúdo, allowlist de domínio e níveis explícitos de risco. É a direção certa, e é cedo demais para dizer se pega.

---

Conclusão

A consolidação do SKILL.md é uma vitória real de interoperabilidade, e não quero que o tom aqui pareça alarmista a ponto de sugerir que ninguém deveria usar skill de terceiro. Uso, o time usa, e o ganho é concreto. O que mudou na minha cabeça foi o enquadramento: parei de pensar em skill como configuração e passei a pensar como dependência. Configuração a gente ajusta, dependência a gente audita, fixa versão e monitora.

O incômodo que sobra é que a infraestrutura de confiança está muito atrás da infraestrutura de distribuição. Não temos assinatura, não temos proveniência verificável, não temos scan contínuo, e temos contador de instalação inflável servindo de sinal de reputação. O npm levou anos e alguns incidentes públicos dolorosos para construir o que tem hoje, e mesmo assim continua sendo alvo. O ecossistema de skills está começando essa curva agora, com a diferença nada tranquilizadora de que aqui o payload pode ser texto em linguagem natural, que nenhum scanner de malware reconhece.

Não tenho certeza de qual mecanismo vai vencer, se assinatura de publicador, se sandbox por padrão, se algum registro central com revisão estilo app store. Suspeito que vai ser uma combinação e que vai demorar. Enquanto isso, o que está sob meu controle é o checklist, o sandbox e o hábito chato de abrir o repositório antes de dizer sim. Naquela pausa entre reuniões levei dez minutos para revisar uma skill que já estava rodando na minha máquina havia semanas. Continuo achando esses dez minutos o melhor investimento de tempo que fiz naquele dia — e o mais constrangedor, porque deviam ter acontecido antes da instalação, não depois.

Fontes:

• ITPro — OpenAI's skills in Codex service aims to supercharge agent efficiency for developers
• GitHub — openai/skills: Skills Catalog for Codex
• OpenAI Developers — Build skills (Codex)
• HiddenLayer — The Next AI Supply Chain Risk: Malicious Skills in Agentic AI
• Orca Security — Skill Issues: How We Discovered Supply Chain Attack Vectors in an AI Agent Skills Marketplace
• Red Hat Developer — Agent Skills: Explore security threats and controls
• Agensi — 7 AI Agent Skills Marketplaces in 2026 (Compared)