Quando as skills de IA se tornam dependências da cadeia de suprimentos

Escrito por: Nubank Editorial, Lucas Palma e Paulo Martins

O desenvolvimento assistido por IA está mudando mais rápido do que os modelos de segurança construídos ao seu redor. A primeira onda foi relativamente simples: desenvolvedores usavam grandes modelos de linguagem para gerar código, explicar funções desconhecidas ou sugerir testes. Mas o fluxo de trabalho do desenvolvedor está se tornando mais combinável, já que modelos e agentes agora podem ser equipados com skills reutilizáveis, plugins, servidores MCP, regras de agentes, manifestos de ferramentas, instruções de prompt e scripts de automação local.

Esses componentes podem não se parecer com pacotes de software tradicionais, mas podem influenciar o que um sistema de IA faz, quais ferramentas ele chama e como ele altera o ambiente de um desenvolvedor. Em outras palavras, a cadeia de suprimentos de software está se expandindo para além do código.

Essa mudança esteve no centro de um projeto liderado por Paulo Martins, Lead Security Engineer. A experiência do time foi compartilhada por Lucas Palma, Product Security Manager no Nubank, na AI Engineer World’s Fair em São Francisco. Em vez de focar apenas na segurança do código gerado por IA, o time começou a fazer uma pergunta mais ampla: o que acontece quando as instruções e capacidades dadas à IA se tornam elas próprias dependências?

A resposta levou a um sistema de segurança que revisou mais de 2.000 skills de IA antes que elas pudessem chegar aos desenvolvedores e a uma lição mais ampla sobre como os controles de segurança precisam evoluir à medida que a IA passa a fazer parte do toolchain de desenvolvimento.

Quando instruções começam a se comportar como dependências

Uma skill de IA pode ser entendida como uma capacidade empacotada para um modelo ou agente. Ela pode reunir instruções, contexto, fluxos de trabalho e arquivos de apoio, e pode descrever quais ferramentas ou comandos devem ser usados ou como um sistema de IA deve interagir com outros sistemas.

Uma vez instalada ou disponibilizada para uma ferramenta de codificação com IA, uma skill pode influenciar como desenvolvedores escrevem, revisam ou modificam código. Isso torna as skills úteis justamente porque são reutilizáveis.

Um time pode capturar um fluxo de desenvolvimento útil uma única vez e disponibilizá-lo para muitos engenheiros. Em vez de explicar repetidamente como executar uma tarefa, a organização pode codificar esse conhecimento em algo que um assistente de IA consegue usar diretamente.

Mas a reutilização também muda a equação de risco, já que uma instrução problemática escrita para um único desenvolvedor tem alcance limitado. Uma skill problemática publicada em um marketplace interno pode se tornar descobrível por diversos times e projetos, e o mesmo mecanismo de distribuição que faz boas práticas se espalharem mais rápido também pode amplificar erros.

A exposição cresce ainda mais quando se consideram skills de terceiros ou compartilhadas pela comunidade. Essa não é apenas uma preocupação teórica—já foram observados agentes maliciosos usando plugins e skills maliciosas em campanhas reais para injetar instruções e comprometer ambientes de desenvolvimento.

É por isso que o time passou a tratar skills de IA e componentes semelhantes como parte da cadeia de suprimentos de software. Eles podem parecer configuração ou documentação, mas seu efeito operacional pode estar muito mais próximo daquele de uma dependência.

Velocidade e segurança precisam coexistir

O desafio se torna especialmente visível em um ambiente regulado. O desenvolvimento assistido por IA pode dar aos engenheiros mais velocidade na codificação, melhor contexto, menos trabalho repetitivo e fluxos reutilizáveis. Ao mesmo tempo, o sistema ao redor ainda precisa proteger clientes e credenciais, preservar a auditabilidade, evitar mudanças não intencionais em produção e deixar clara a responsabilidade.

Uma resposta possível seria criar mais um processo de aprovação em torno da IA: os desenvolvedores usam as ferramentas e, depois, Segurança revisa o que aconteceu. Mas esse modelo introduz atrito depois do fato e deixa o momento de maior risco — a distribuição — relativamente aberto.

Em vez disso, o objetivo foi fazer os controles operarem dentro do fluxo de trabalho que os engenheiros já usam. A segurança deve estar presente quando uma skill é criada e compartilhada, em vez de se tornar um checkpoint externo que os desenvolvedores encontram mais tarde.

Essa distinção importa. Velocidade de desenvolvimento e segurança não precisam se tornar objetivos concorrentes se os controles forem colocados no ponto certo do sistema.

Instruções aparentemente inofensivas podem impactar a produção

Uma das razões pelas quais as skills de IA exigem uma mentalidade de segurança diferente é que comportamentos de risco podem estar escondidos dentro de instruções que parecem razoáveis à primeira vista.

Considere as credenciais. Uma skill pode instruir um agente a recuperar um token local para acessar um serviço. Tecnicamente, a tarefa pode funcionar como esperado, mas recuperar o token pode fazer com que a credencial entre no contexto do modelo, potencialmente expondo-a por meio de logs ou de outra infraestrutura envolvida no processamento da requisição.

Outra skill pode conter um comando de shell capaz de modificar dados relacionados à produção. Suas instruções poderiam dizer que o agente deve perguntar ao desenvolvedor antes de executar o comando.

Isso parece uma salvaguarda, mas a aprovação existe apenas dentro do prompt. O modelo pode interpretar o contexto anterior como consentimento, ignorar a pausa esperada ou, na prática, aprovar sua própria ação.

As permissões criam outra classe de risco. Uma skill capaz de manipular tabelas, grants ou entradas de registro pode ter motivos legítimos para fazê-lo. Mas um acesso excessivamente amplo significa que algo tão simples como uma informação desatualizada ou um erro de digitação pode ter consequências reais.

Nesses casos, designs mais seguros colocam a operação sensível atrás de uma ferramenta controlada pelo host ou de um servidor MCP, em vez de dar ao modelo autoridade irrestrita.

Nenhum desses exemplos exige um autor de skill mal-intencionado. Um componente pode criar exposição de segurança enquanto faz exatamente o que seu autor pretendia.

Revisão antes da distribuição

À medida que o marketplace interno do Nubank tornou as skills mais fáceis de descobrir pelos engenheiros, o time identificou o próprio marketplace como um ponto de controle crítico.

A descobribilidade gera escala. E escala significa que um pequeno erro pode se tornar um comportamento repetido em toda a organização. Em vez de revisar skills depois que os desenvolvedores já tinham começado a usá-las, a segurança precisava se mover para mais cedo no processo. O fluxo resultante é:

Criador da skill → Pull request → Skill Vetter → Marketplace → Desenvolvedores

O desenvolvedor que cria ou modifica uma skill a submete pelo processo normal de pull request. Antes de o componente ficar disponível no marketplace, um sistema automatizado chamado Skill Vetter o avalia e classifica riscos potenciais.

Somente depois desse gate a skill pode ir para o diretório descobrível usado pelos desenvolvedores. Arquiteturalmente, isso muda o papel do marketplace, que passa a funcionar como parte do modelo de segurança.

Como o Skill Vetter funciona

O sistema combina diferentes formas de análise porque nenhuma técnica isolada é suficiente para esse problema. Os engenheiros podem rodar o scanner localmente enquanto criam uma skill, obtendo feedback antes da submissão. Depois que uma skill é adicionada ou modificada, o CI executa as verificações automaticamente como parte do pull request.

A primeira camada usa detecção determinística para padrões que podem ser identificados com confiança relativamente alta. Isso inclui sinais como comandos de shell destrutivos, solicitações de credenciais, caminhos de arquivos sensíveis, uso de CLI com impacto em produção e outras construções de risco conhecidas.

Outros problemas são mais difíceis de identificar sem contexto. Para esses, o sistema também usa análise baseada em LLM para avaliar o comportamento da skill de forma mais holística.

Um scanner determinístico é bem adequado para identificar algo explícito: um caminho sensível conhecido, por exemplo, ou uma classe específica de comando perigoso. Mas ele pode ter dificuldade em determinar se uma sequência de instruções aparentemente comum se torna arriscada por causa do sistema que ela alcança ou das permissões que assume.

Um LLM pode ajudar com essa segunda categoria porque consegue interpretar as relações entre instruções, ferramentas e comportamento pretendido.

Os resultados aparecem diretamente no pull request. Os achados também são convertidos para SARIF — o formato padronizado usado por sistemas de code scanning — para que os desenvolvedores possam ver o feedback de segurança por meio de ferramentas familiares. Dependendo da severidade e da política, a skill pode exigir remediação ou ser bloqueada antes de chegar ao marketplace.

A ideia é combinar regras previsíveis com análise contextual e entregar ambas por meio de um fluxo de trabalho que os engenheiros já entendem.

O que mais de 2.000 skills revelaram

Rodar o sistema em escala produziu uma visão mais clara do que era útil e do que ainda precisava de ajustes. Entre mais de 2.000 skills analisadas, o processo identificou aproximadamente 1.600 riscos potenciais. Cerca de 1.000 problemas foram remediados, enquanto aproximadamente 90 casos foram classificados como revisões prioritárias.

Os números foram apenas parte do resultado, já que a lição mais útil veio da comparação entre os sinais produzidos por diferentes abordagens.

Scanners determinísticos funcionaram bem para padrões de risco conhecidos, incluindo comandos destrutivos, manipulação de credenciais e caminhos sensíveis. A revisão baseada em LLM agregou valor onde entender o comportamento geral de uma skill exigia mais contexto. A integração com SARIF e os comentários diretamente nos pull requests ajudaram a transformar achados em feedback sobre o qual os engenheiros podiam agir.

Mas o exercício também expôs fontes de ruído: tratar todo comando como igualmente perigoso não era útil. Nem alertas que falhavam em distinguir entre operações locais inofensivas e ações capazes de afetar a produção. Sinais fracos sem contexto suficiente podiam produzir achados sem ajudar os desenvolvedores a entender o que realmente deveria mudar.

Para que uma ferramenta de segurança se torne parte de um fluxo de engenharia, a detecção sozinha não é suficiente. O sistema também precisa explicar as consequências e apontar caminhos de remediação.

Um prompt não é uma camada de autorização

Um achado foi importante o bastante para se tornar um princípio de design mais amplo: pedir ao modelo que obtenha permissão não é o mesmo que impor permissão tecnicamente.

Suponha que uma skill contenha uma instrução como pergunte antes de rodar este comando. Se o mesmo modelo é responsável por decidir se a permissão existe e depois executar a operação, ele é, na prática, ao mesmo tempo executor e aprovador. Essa não é uma fronteira de segurança confiável.

Um design mais robusto move a operação perigosa para fora do loop de raciocínio do modelo. O agente pode solicitar a ação, mas um gate de aprovação controlado pelo host determina se a ferramenta realmente pode ser executada.

A apresentação aponta para padrões como MCP ou outras ferramentas controladas pelo host, hooks no estilo PreToolUse e aprovação humana explícita para operações sensíveis.

A diferença é arquitetural, não linguística: um prompt pode sugerir comportamento, mas um controle fora do modelo pode impô-lo.

Faça do caminho seguro o caminho mais fácil

A lição mais ampla do Skill Vetter não é que todo componente de IA precisa de mais uma revisão manual de segurança. É quase o oposto.

Componentes de IA reutilizáveis devem ser tratados como parte da cadeia de suprimentos. Os desenvolvedores devem poder rodar verificações localmente. Os mesmos controles devem ser aplicados automaticamente no CI. A análise determinística deve lidar com padrões bem compreendidos, enquanto a revisão contextual deve ser reservada para comportamentos que realmente exigem interpretação. E operações com impacto relevante em produção devem ser protegidas por controles técnicos fora do próprio prompt. Os próximos problemas decorrem naturalmente dessa base.

O time está olhando além das skills, para a cadeia de suprimentos de agentes de forma mais ampla, incluindo plugins, servidores MCP, regras, hooks, comandos, agentes e manifestos. O roadmap também aponta para gates mais fortes respaldados por políticas, mais aplicação no nível das ferramentas por meio de aprovações, permissões escopadas, gateways confiáveis e logs de auditoria, e marketplaces em que componentes de IA compartilhados tenham dono, versionamento e revisão antes do consumo.

À medida que a IA se torna mais profundamente incorporada ao desenvolvimento de software, proteger apenas o código que uma IA produz não será suficiente. Os fluxos de trabalho, as ferramentas, as permissões e os componentes reutilizáveis ao redor do modelo também importam. Isso muda onde a segurança precisa atuar.

Em vez de adicionar mais uma camada de aprovação após a adoção, o objetivo é colocar salvaguardas nos pontos em que capacidades de IA são criadas, revisadas e distribuídas, e expor essas salvaguardas por meio dos mesmos sistemas de engenharia que os desenvolvedores já usam.

O princípio é fazer do caminho seguro o caminho mais fácil. A adoção de IA escala de forma mais sustentável quando a segurança faz parte do fluxo de trabalho do desenvolvedor desde o início, em vez de ser algo acrescentado ao redor dele depois.