Toda empresa tem uma versão da mesma coisa.
Às vezes é uma wiki de segurança. Às vezes é uma página do Confluence. Às vezes é um PDF que ninguém quer atualizar. Às vezes é "pergunte à Sarah da AppSec porque ela sabe como fazemos isso aqui."
O que "isso" faz é explicar como as APIs devem ser autenticadas, como os dados sensíveis devem ser tratados, como os segredos devem ser usados, quais padrões de log são aceitáveis e quais padrões importam para o seu negócio, seus reguladores e seus clientes.
Então, um desenvolvedor abre um assistente de codificação de IA e pede para ele construir algo.
O assistente não leu nada disso.
Essa é a lacuna. E um problema realmente grande.
Por anos, as equipes de segurança tentaram resolver isso revisando o código depois de escrito. Escaneie na pipeline. Abra um chamado. Envie de volta para o desenvolvedor. Espere pela correção. Repita o processo.
Esse modelo já era doloroso quando humanos escreviam a maior parte do código.
Hoje, quase 50% do código é escrito por IA, e esse modelo falhou.
A IA não está apenas escrevendo código. Ela está escrevendo a camada de ação.
No mundo dos agentes, o código que a IA gera não é apenas mais um aplicativo interno. É frequentemente a infraestrutura que dá aos agentes "mãos" para fazer as coisas.
APIs. Servidores MCP. Ferramentas de agente. Conectores. Integrações. Fluxos de trabalho.
Esse código gerado por IA torna-se o caminho que um agente usa para interagir com o negócio.
Um desenvolvedor pede a um assistente para construir uma ferramenta de suporte que possa consultar pedidos e emitir reembolsos. O assistente gera um servidor MCP. O servidor MCP chama APIs internas. Essas APIs acessam registros de clientes, sistemas de pagamento, dados de logística e logs de auditoria.
De fora, isso parece produtividade.
Do ponto de vista da segurança, é o nascimento de um novo caminho de ação e um risco oculto.
Se esse caminho tiver autorização fraca, credenciais codificadas, limites de taxa ausentes, registro deficiente ou dados sensíveis fluindo pelo lugar errado, o problema não é teórico. Ele se torna parte das "mãos" do agente.
E uma vez que o código é escrito, revisado, mesclado, implantado e conectado a APIs reais, corrigir o padrão é muito mais difícil.
Esta é a parte que eu acho que a indústria precisa dizer mais claramente:
Se a sua política de segurança não atuar no momento em que o código é criado, ela estará sempre correndo atrás do que a IA já escreveu.
A Wiki de Segurança não consegue acompanhar o assistente de codificação.
Não é porque os desenvolvedores são descuidados. É porque o fluxo de trabalho mudou.
Um desenvolvedor costumava escrever código, pesquisar recursos internos, perguntar a outro engenheiro, ler o padrão e copiar padrões de serviços existentes. Esse processo tinha muitos problemas, mas pelo menos o humano sabia que havia uma forma da empresa de fazer as coisas.
Os assistentes de codificação de IA não conhecem naturalmente a forma da sua empresa.
Eles conhecem padrões comuns da internet. Alguns são bons. Alguns estão desatualizados. Alguns são inseguros. Alguns são completamente inadequados para o seu ambiente.
Eles não sabem que suas APIs exigem um padrão de autorização específico. Eles não sabem que sua empresa proíbe tokens na configuração de ferramentas. Eles não sabem que todo endpoint público deve ter um esquema OpenAPI, que certas classes de dados não podem ser retornadas a um agente, ou que ferramentas MCP com permissões de escrita exigem controles mais rigorosos.
A menos que você leve a política ao assistente, o assistente irá improvisar.
E “improvisar” não é uma estratégia de segurança. Tenho orgulho de dizer que nossa equipe na Salt resolveu este problema.
Hoje estamos lançando o Salt Code.
A ideia central por trás do Salt Code é simples: a política de segurança deve acompanhar o código desde o primeiro prompt.
Não depois do pull request.
Não depois da descoberta SAST.
Não depois da lacuna de postura em tempo de execução.
Mas desde o momento em que o desenvolvedor pede ao assistente de IA para criar algo.
O Salt Code conecta nosso Posture Governance Engine aos assistentes de codificação que os desenvolvedores já usam: Claude, Cursor, GitHub Copilot, Windsurf, Codex, Gemini CLI e outros fluxos de trabalho compatíveis com MCP. O Posture Governance Engine é nossa camada de política onde os padrões de segurança e conformidade são definidos uma vez e depois aplicados em todo o ciclo de vida.
Para o desenvolvedor, funciona em segundo plano dentro do fluxo de trabalho que ele já usa. Para a equipe de segurança, significa que o padrão não está mais preso em uma wiki. Torna-se parte de como o código é criado.
Um desenvolvedor pode pedir ao Cursor para construir um servidor MCP que chama uma API de faturamento interna. O Salt Code pode guiar o código gerado para seguir o padrão corporativo: sem segredos codificados, o padrão de autenticação correto, verificações de autorização necessárias, documentação OpenAPI, comportamento de registro aprovado e controles para dados sensíveis. E construir o servidor MCP de acordo com a política.
O desenvolvedor não precisa se lembrar de pedir código seguro.
O assistente o gera dessa forma por padrão.
É essa a lacuna que está a ser preenchida.
A segurança precisa passar da revisão para a criação.
Ainda há lugar para as ferramentas de segurança de código existentes. SAST, DAST, revisão de código, verificações de CI/CD e monitorização em tempo de execução não vão desaparecer.
Mas se a política de segurança só aparece depois de a IA já ter gerado o código, estamos a começar tarde demais, e a lacuna já se tornou demasiado grande para ser fechada.
É como deixar uma fábrica produzir milhares de peças o dia todo, e depois enviar alguém no final da linha para deitar fora as avariadas. Ainda é preciso inspeção no final. Mas também é preciso que a máquina esteja calibrada antes do início da produção.
O Salt Code trata-se de calibrar a máquina.
Aplica a política quando o código é gerado. Valida a mesma política no pipeline. Utiliza inteligência em tempo de execução para compreender como as APIs, as integrações MCP e os agentes realmente se comportam uma vez implementados. E, com o tempo, as descobertas em tempo de execução podem alimentar os fluxos de trabalho dos programadores para que a próxima versão seja melhor do que a anterior.
Essa última parte importa porque a segurança agêntica não é uma única barreira. É um ciclo.
O código diz-lhe o que foi construído. A configuração diz-lhe como é governado. O tempo de execução diz-lhe o que aconteceu. O mesmo padrão de segurança precisa de ligar os três.
Essa é a ideia central por trás do Salt Code: um modelo de política que segue o sistema agêntico desde o código que o cria, ao plano de controlo que o governa, até ao comportamento em tempo de execução que prova o que realmente aconteceu.
O código não é apenas código. É também comportamento futuro.
Se isto fosse apenas sobre gerar fragmentos de código mais seguros, seria útil. Mas os sistemas agênticos esbatem a linha entre o desenvolvimento e o tempo de execução.
O código que um programador gera hoje pode tornar-se uma ferramenta MCP amanhã, que será usada por outro agente em dois dias. Essa ferramenta MCP pode chamar uma API na próxima semana. Essa API pode dar a um agente acesso a dados de clientes, fluxos de pagamento, alterações de conta ou sistemas operacionais.
Por outras palavras, o código não é apenas código. É comportamento futuro.
É por isso que o Salt Code é uma parte integrante da nossa Plataforma de Segurança Agêntica e não um scanner de código autónomo. As mesmas políticas que moldam o código na criação devem governar as APIs e os sistemas agênticos em que esse código se transforma em produção.
É assim que passamos de “encontrar o problema mais tarde” para “impedir que o padrão seja criado em primeiro lugar”.
O horizonte temporal importa.
Cada semana em que um assistente de codificação de IA é executado no seu ambiente sem aplicação de política é uma semana de código agêntico que nenhuma revisão de segurança alguma vez viu.
Parte desse código será inofensivo. Parte dele tornar-se-á protótipos. Parte dele tornar-se-á silenciosamente produção. E parte dele tornar-se-á a camada de ação que os seus agentes usam para aceder a sistemas críticos.
É por isso que acredito que proteger a IA agêntica começa antes do primeiro prompt.
Não porque a segurança de prompts seja sem importância. Não porque a proteção em tempo de execução seja opcional. Mas porque o primeiro prompt que um desenvolvedor dá a um assistente de codificação de IA pode se tornar a primeira versão de uma ferramenta, API ou servidor MCP que seus agentes usarão mais tarde.
Se queremos que os agentes ajam com segurança, precisamos nos preocupar com o que eles produzem.
A IA está mudando a forma como o software é construído.
A política de segurança também precisa acompanhar essa mudança.
O Salt Code está disponível através do nosso Programa de Acesso Antecipado para as primeiras 100 organizações, com todos os quatro Pacotes de Codificação Segura incluídos. Você pode inscrever-se para sua avaliação gratuita aqui ou participar do nosso webinar em 16 de junho para ver uma demonstração do Salt Code.