Como construí avaliações de segurança baseadas em agentes no Databricks

Nós já tínhamos automação em partes do nosso processo de revisão de segurança. Ela era útil, mas não reduzia o trabalho manual o suficiente.

Eu continuava vendo o mesmo padrão na fila: uma integração rotineira usando um design familiar podia ficar ao lado de uma arquitetura genuinamente nova e de alto risco, ambas aguardando o mesmo recurso escasso, um revisor experiente.

O problema não era que nossa automação existente tivesse falhado. Ela simplesmente tinha atingido seus limites. Ainda estávamos gastando o tempo de especialistas em trabalho previsível, deixando menos espaço para as decisões que realmente exigiam julgamento especializado.

Então, criei uma camada baseada em agentes para estender o que já tínhamos. O objetivo não era substituir o processo ou as pessoas por trás dele. Era ajudar o sistema a entender uma solicitação, aplicar nossos padrões, solicitar informações ausentes e reconhecer quando uma pessoa precisava intervir.

A primeira versão baseada em agentes focava em um único caminho de revisão. Minha equipe percebeu o padrão mais amplo e o expandiu para um conjunto de agentes que agora oferecem suporte a partes adicionais do nosso processo de triagem e revisão de segurança. Criei essa primeira versão inteiramente no Databricks, a mesma plataforma que nossos clientes usam.

Por que a plataforma era importante

Pude agir rapidamente porque as peças fundamentais já estavam disponíveis em um único ambiente.

O Unity Catalog forneceu um espaço governado para nossos padrões de segurança, dados de solicitação, evidências de suporte, decisões e saídas do sistema. Os modelos de fundação hospedados no Databricks forneceram a camada de modelo para classificação e raciocínio. O Lakeflow Jobs orquestrou os fluxos de trabalho baseados em notebooks em computação serverless. O Databricks Apps entregou a experiência de triagem e o painel executivo.

Como as peças se encaixam

Em alto nível, uma solicitação flui pela plataforma em um único caminho contínuo, com cada etapa lendo e gravando nas mesmas tabelas governadas:

1. Triagem - Um aplicativo conversacional baseado no Databricks Apps transforma uma descrição em linguagem simples em uma solicitação estruturada e anexa quaisquer documentos de design de suporte.
2. Raciocínio - Modelos de fundação hospedados no Databricks (Claude Haiku, Sonnet e Opus) classificam a solicitação, avaliam o risco e elaboram os requisitos, sempre embasados em nossos padrões de segurança. O Haiku lida com classificações leves, o Sonnet lida com a maior parte do trabalho de revisão e o Opus é reservado para o raciocínio mais complexo.
3. Orquestração - O Lakeflow Jobs executa os agentes de revisão em computação serverless, movendo cada solicitação por suas etapas de acordo com um cronograma.
4. Sistema de registro - O Unity Catalog mantém os padrões, dados de solicitação, evidências, saídas do modelo e decisões como tabelas governadas, com um único modelo de permissão e linhagem para tudo isso.
5. Observabilidade - Um segundo Databricks App lê essas mesmas tabelas para gerar relatórios sobre volume, mix de risco, taxa de automação e tempo economizado.

Isso nos deu um modelo operacional e de governança consistente em todos os dados, modelos, fluxos de trabalho e aplicativos. Em vez de montar serviços separados com diferentes permissões, logs e caminhos de dados, eu pude focar na lógica de revisão e na experiência do usuário.

A diferença prática foi a velocidade. Eu tinha um sistema funcionando em menos de duas horas. Fazer a mesma coisa interligando serviços separados teria levado semanas.

Nem toda revisão precisa do mesmo caminho

A maioria das filas de segurança contém tanto solicitações previsíveis quanto exceções genuínas.

Uma integração que usa um padrão de autenticação aprovado e não lida com dados confidenciais não exige a mesma decisão que um serviço voltado para a internet que processa informações confidenciais com amplo acesso administrativo. No entanto, uma fila tradicional pode enviar ambos pelo mesmo caminho manual.

Meu objetivo não era automatizar todas as revisões. Automatizei as partes repetitivas e preservei o julgamento humano onde o risco ou a incerteza eram maiores.

Isso levou a uma regra simples: automação para casos bem compreendidos dentro de critérios explícitos; pessoas para decisões novas, de alto risco ou ambíguas.

Uma porta de entrada melhor

A qualidade da revisão depende das informações disponíveis no início.

Formulários estáticos esperam que os solicitantes saibam de qual revisão precisam, entendam a terminologia de segurança e antecipem as evidências que um revisor solicitará. Quando isso não acontece, a solicitação chega incompleta e a revisão começa com mais uma rodada de perguntas.

Criei um aplicativo de triagem conversacional com o Databricks Apps. O solicitante descreve o que está tentando fazer em linguagem simples. O aplicativo identifica o caminho de revisão provável, faz perguntas de acompanhamento dependentes do contexto e pode usar um documento de design integrado como contexto de suporte. Ele destaca informações ausentes e fornece uma indicação preliminar de risco antes que uma solicitação formal seja criada.

Assim que tiver contexto suficiente, ele cria uma solicitação estruturada para a equipe de segurança.

O aplicativo também possui um modo de consulta baseado em nossos padrões de segurança. Nem toda pergunta precisa se tornar um ticket. As equipes podem obter orientação enquanto ainda estão moldando um design e abrir uma revisão formal apenas quando for necessário.

Essa se tornou uma das partes mais úteis do sistema. Ela permite que as pessoas progridam mais rapidamente, em vez de tratar a fila como a única maneira de acionar a segurança.

Como os agentes funcionam

Por trás do aplicativo de triagem, há uma coleção de agentes focados implementados em Databricks Notebooks e orquestrados com o Lakeflow Jobs.

Eu evitei deliberadamente criar um único agente com ampla autoridade para atuar como revisor de segurança. Cada agente tem uma responsabilidade limitada: coletar contexto, avaliar riscos, mapear a solicitação para os padrões relevantes, elaborar requisitos, gerenciar acompanhamentos ou preparar a transferência para uma pessoa.

Sete agentes focados, cada um com uma função

Trata-se de um conjunto de agentes focados — não um único agente geral e não um único script —, cada um com uma função específica, orquestrados como tarefas agendadas por trás do aplicativo de triagem:

• Agente de triagem - Executa a porta de entrada conversacional: identifica o caminho de revisão, faz perguntas dependentes do contexto e monta uma solicitação estruturada.
• Agente de avaliação de risco - Atribui um nível de risco com evidências de suporte e define como padrão um nível mais alto quando as informações estão incompletas.
• Agente de requisitos - Mapeia uma solicitação para os padrões relevantes e elabora requisitos específicos de implementação para casos bem compreendidos.
• Agentes de revisão especializada - Lido com tipos de solicitação que precisam de lógica dedicada, como modelagem de ameaças de extensão de navegador e avaliação de fornecedores terceirizados.
• Agente de validação - Cria uma lista de verificação de validação item por item para solicitações de maior risco antes que qualquer processo seja encerrado.
• Agente de fluxo de trabalho - Lida com o trabalho de acompanhamento: esclarecimentos, lembretes, rastreamento de confirmações e encaminhamento para pessoas.
• Agente de aprendizado - Compara periodicamente as edições do revisor com a saída original para identificar melhorias nos prompts e padrões.

Cada agente tem uma responsabilidade limitada, de modo que seu comportamento permanece inspecionável e testável, e uma alteração em um deles não afeta silenciosamente o outro.

O sistema primeiro avalia o risco da solicitação e registra as evidências que apoiam essa avaliação. Um rótulo de risco por si só não é suficiente.

Quando as informações estão ausentes ou são contraditórias, o sistema solicita esclarecimentos ou encaminha a solicitação a um revisor. Ele não faz suposições para chegar à aprovação.

Para solicitações rotineiras, os agentes geram requisitos com base na arquitetura real e nos padrões aplicáveis, em vez de retornar um modelo genérico padrão. O solicitante confirma esses requisitos e fornece as evidências necessárias. Solicitações elegíveis de baixo e médio risco podem ser concluídas pelo caminho automatizado assim que os critérios e validações definidos forem atendidos.

Um exemplo

Vejamos um caso comum: uma integração interna que usa um padrão de logon único (SSO) aprovado e não lida com dados confidenciais. Em vez de um modelo genérico padrão, o agente de requisitos produz itens específicos e verificáveis vinculados a essa arquitetura — por exemplo:

• Autenticar por meio do provedor de identidade aprovado e desativar quaisquer credenciais locais ou compartilhadas.
• Restringir a integração aos escopos de acesso mínimos necessários e documentá-los.
• Enviar logs de aplicativo e de acesso para o pipeline de logs centralizado.
• Confirmar o nível de classificação dos dados e realizar uma nova revisão antes que qualquer dado confidencial seja introduzido.

O solicitante confirma esses itens e anexa as evidências. Se tudo estiver correto e o caso atender aos critérios de elegibilidade, ele poderá ser concluído pelo caminho automatizado.

Solicitações de alto risco, críticas, incomuns ou ambíguas são direcionadas a uma pessoa. Nesse momento, o revisor recebe um resumo estruturado, evidências de apoio, padrões aplicáveis e quaisquer perguntas em aberto restantes.

Os agentes também lidam com a maior parte do trabalho administrativo de uma revisão: coletar detalhes pendentes, enviar lembretes, acompanhar confirmações e encaminhar o caso quando alguém pede ajuda. O revisor entra em ação quando uma solicitação se torna ambígua ou exige julgamento.

A automação opera dentro das regras que definimos. As pessoas mantêm o controle sobre exceções e decisões importantes.

Tornando o sistema confiável

A parte mais difícil não foi fazer com que um modelo gerasse uma resposta. Foi tornar essa resposta restrita, passível de revisão e acionável.

Os agentes são baseados em nossos padrões de segurança. As avaliações de risco devem incluir evidências de apoio. A falta de contexto aciona um acompanhamento ou encaminhamento, e não uma suposição otimista. A conclusão automatizada é limitada a classes e critérios de solicitação predefinidos. O fluxo de trabalho registra as entradas, saídas, evidências e decisões associadas a cada solicitação.

Como isso funciona na prática

Três fatores tornam uma decisão automatizada segura para a tomada de ação:

• Classes de solicitação predefinidas. Apenas categorias bem compreendidas e de menor risco são qualificadas para a conclusão automatizada — por exemplo, uma integração interna rotineira em um padrão aprovado que não manipula dados confidenciais. Qualquer coisa fora dessas classes é direcionada a uma pessoa por padrão.
• Evidências aceitáveis. Uma decisão é tão boa quanto o que a sustenta. Evidência significa artefatos concretos e verificáveis: um documento de design vinculado, um nível de classificação de dados declarado ou configurações e referências que demonstrem que um controle aprovado está em vigor. Uma afirmação sem evidências é tratada como informação ausente.
• Uma avaliação rejeitada ou incerta. Quando as evidências estão ausentes ou são contraditórias, o sistema não faz suposições. Ele adota por padrão a faixa de risco mais conservadora, publica uma solicitação de esclarecimento específica ou entrega a solicitação a um revisor com as perguntas em aberto anexadas. Ela não é aprovada de forma alguma.

O feedback dos revisores nos ajuda a identificar lacunas e melhorar o sistema ao longo do tempo. Usamos essas correções para refinar nossos padrões, prompts e a lógica do fluxo de trabalho, em vez de permitir que os agentes alterem o comportamento em produção por conta própria.

Esses controles importam mais do que o modelo em si. Um modelo forte pode melhorar o raciocínio, mas a confiança vem do sistema ao seu redor: escopo claro, evidências explícitas, encaminhamento conservador e autoridade humana que dá ao risco um peso real.

Como minha equipe expandiu o projeto

Eu criei a primeira versão baseada em agentes para melhorar um fluxo de revisão. Minha equipe percebeu que o mesmo padrão poderia dar suporte a muito mais.

Eles expandiram a arquitetura para outros tipos de solicitação, reforçaram os fluxos de trabalho, melhoraram a forma como os agentes aplicam nossos padrões e adicionaram os controles necessários para o uso diário. O que começou como um único fluxo de trabalho baseado em agentes tornou-se um sistema compartilhado que a equipe continua desenvolvendo.

Eu dei o pontapé inicial, mas o sistema se tornou valioso porque a equipe o tornou operacional e o adotou como seu.

Como desenvolvedor, tenho orgulho de que a primeira versão tenha funcionado. Como líder, tenho ainda mais orgulho de que a equipe tenha visto ali uma base que valia a pena expandir.

Medindo os resultados

É fácil alegar eficiência, mas difícil confiar nisso sem evidências.

Desenvolvi um dashboard executivo como outro Databricks App. Ele lê os mesmos dados do Unity Catalog gerados pelos fluxos de trabalho de revisão e acompanha o volume de solicitações, a distribuição de riscos, a conclusão automatizada, o encaminhamento humano, o tempo de ciclo e o tempo estimado economizado pelos revisores.

Como as métricas vêm de registros operacionais, podemos rastreá-las de volta até as solicitações e decisões que as geraram, em vez de reconciliar manualmente exportações de sistemas separados.

Isso mudou a conversa com a liderança. Pudemos mostrar onde a automação reduziu o esforço manual, onde os revisores continuaram engajados e como essa combinação mudou ao longo do tempo.

Os números

O dashboard acompanha um conjunto consistente de métricas, todas derivadas dos mesmos registros operacionais.

O que mudou

Solicitações rotineiras qualificadas que antes esperavam dias na fila agora podem ser concluídas em minutos. As equipes podem receber orientação antes de abrir um chamado, e as solicitações que chegam a um revisor contam com um contexto muito melhor.

Nossos engenheiros de segurança podem dedicar mais tempo a novos designs, riscos significativos e decisões que exigem experiência. A primeira análise também é mais consistente, pois as solicitações são avaliadas de acordo com os mesmos padrões e requisitos de evidência. Quando o sistema está incerto, ele encaminha o caso.

Isso não significa segurança sem pessoas. É um sistema projetado para direcionar a atenção dos especialistas para onde ela tem o maior valor.

O que aprendi com essa experiência

Adicionar revisores pode aumentar a capacidade, mas não elimina o trabalho repetitivo.

O primeiro passo é separar o processo do julgamento. Automatize etapas repetitivas apenas quando os critérios forem explícitos, o sistema for baseado em padrões reais, as evidências forem obrigatórias, as incertezas forem encaminhadas e os resultados puderem ser medidos.

Não automatize uma decisão simplesmente porque um modelo pode gerar uma resposta. Automatize-a apenas quando o processo definir como deve ser uma resposta aceitável, quais evidências a sustentam e o que acontece quando o sistema não tem certeza.

Mantenha as pessoas no controle de exceções e decisões importantes.

Minha intenção não era remover os humanos da revisão de segurança. Meu objetivo era reduzir o tempo que eles gastam em tarefas que um sistema controlado pode realizar de forma consistente. Desenvolver na Databricks nos deu a base de plataforma necessária para isso. Ver minha equipe pegar a primeira versão, fortalecê-la e adotá-la como sua foi a melhor parte.

Comece com o guia multiagente da Databricks e, depois, adapte o padrão deste post — dados governados no Unity Catalog, agentes focados em Lakeflow Jobs e um Databricks App como porta de entrada — em seu próprio fluxo de trabalho de revisão repetível e baseado em evidências.

Crie um sistema multiagente no Databricks Apps

Comece com o guia multiagente da Databricks e, depois, adapte o padrão deste post — dados governados no Unity Catalog, agentes focados em Lakeflow Jobs e um Databricks App como porta de entrada — em seu próprio fluxo de trabalho de revisão repetível e baseado em evidências.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original