A Microsoft, através da sua organização One Engineering System (1ES), tem redefinido como grandes corporações gerenciam a segurança e o compliance em ambientes complexos. O desafio é antigo: o eterno ciclo de alertas de CVEs, configurações desatualizadas e a necessidade de manter a produtividade de milhares de engenheiros sem interromper o shipping de novas funcionalidades.
O problema: a esteira de CVE e compliance
O cenário era o padrão de mercado: um alerta de vulnerabilidade ou (Dependabot ou CVE) chegava, um engenheiro tentava uma atualização simples ou uma pequena alteração na config, o CI passava, o PR era fundido, mas a falha persistia em produção ou exigia um refactoring mais profundo. Essa "esteira" gera um custo proibitivo de tempo de engenharia em tarefas que, puramente, não entregam valor ao cliente.
E quando você multiplica isso por centenas ou milhares de repositories, o problema deixa de ser pontual e vira um gargalo operacional. O que a 1ES identificou é que a IA, nesta escala, deve ser usada não como um substituto, mas como um motor de julgamento assistido por humanos.
Por que agora?
A convergência de três fatores tornou essa estratégia viável:
- Frontier models: Modelos capazes de raciocinar sobre intenção e tradeoffs.
- Runtimes de agentes: Ferramentas como o GitHub Copilot CLI que conseguem ler, testar e interagir com pipelines de CI/CD.
- Habilidades codificadas: A transformação da expertise humana em skills portáteis, evitando que a IA precise "redescobrir" como resolver um problema conhecido.
Colaborar, não apenas automatizar
O modelo adotado pela 1ES baseia-se em guardrails claros. A IA propõe, e o humano retém a propriedade final. O uso de skills em vez de prompts genéricos resolve o problema da alucinação: a skill contém o passo a passo, o contexto técnico e a lógica de decisão de um especialista, carregada apenas quando necessária.
Um exemplo prático citado é o CVE do XStream. A simples atualização da dependência não era suficiente pois o modelo de segurança mudou de default-allow para default-deny. Aqui, a automação ingênua falharia; a estratégia de agentes, que executa testes e propõe mudanças no código de tipo de permissão, prova-se essencial. O fluxo de execução inclui um mecanismo de Agent Signals, onde a ferramenta reporta o sucesso, a dificuldade ou a incerteza de cada etapa para que a própria base de conhecimento da IA evolua.
Integração Dev e Ops
O fechamento do laço ocorre na conexão entre o dev-side e o ops-side. Os sinais emitidos pelos agentes durante a remediação de um código são analisados pelo Azure SRE Agent em escala. Este, por sua vez, pode abrir PRs para corrigir as suas próprias skills quando detecta uma degradação. É o conceito de "agentes melhorando agentes", mantendo o human-in-the-loop em decisões críticas.
Resultados práticos e lições
Os ganhos de eficiência são claros: tarefas que consumiam de 15 a 18 horas de trabalho manual foram reduzidas para cerca de 9 horas — um ganho de produtividade de aproximadamente 50-60%. O importante, no entanto, é o que os engenheiros pontuaram: a carga de trabalho de "descoberta" diminuiu, mas o "last-mile" (validação e implantação) continua humano. A IA não elimina o trabalho; ela muda o foco do engenheiro para as etapas que realmente importam.
Como começar a jornada
Para times brasileiros de engenharia, a lição é clara: não tentem implementar mandatos de IA abrangentes. Comece pequeno:
- Escolha uma vulnerabilidade ou tarefa trivial que se repete em vários repos.
- Documente a resolução (o primeiro skill file em Markdown).
- Teste em um ambiente controlado.
- Deixe o agente escalar conforme a confiança aumenta.
O sucesso na transformação de SecOps passa pela governança e pela capacidade de codificar as melhores práticas, permitindo que a IA lide com o volume enquanto os times focam na arquitetura e na resiliência estratégica da infraestrutura.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
