Agente de IA para time de segurança da informação: triagem e relatórios

Um agente de IA para time de segurança da informação é mais útil quando faz a leitura e a escrita em torno de um alerta, e não a ação. Ele reúne contexto, compara o alerta com casos anteriores e runbooks, propõe uma prioridade e redige o ticket ou o relatório, enquanto toda alteração em um sistema continua com um analista identificado. Comece com acesso somente de leitura, registre tudo o que o agente consulta e só acrescente ações de resposta um passo estreito por vez, se é que isso vai acontecer.

Principais pontos

• Triagem, enriquecimento e rascunho de relatórios em modo somente leitura eliminam boa parte da carga repetitiva sem dar ao agente nenhum poder de alterar um sistema.
• O agente propõe e explica. Quem decide é o analista, e a decisão fica registrada ao lado do raciocínio do agente.
• O conteúdo de um alerta é entrada não confiável. Trate o texto dentro de logs, e-mails e tickets como dado, nunca como instrução.
• Ações de resposta, se algum dia forem permitidas, exigem uma lista curta e aprovada, uma etapa de aprovação humana e um jeito claro de desfazê-las.
• Avalie o agente com um conjunto fixo de alertas passados e um critério de sucesso observável antes de ampliar o papel dele.

O que um agente de IA faz, de fato, em um time de segurança da informação?

No dia a dia de um time de segurança, a parte lenta de um alerta raramente é a decisão. É a coleta: que ativo é esse, quem é o responsável, isso já disparou antes, o que mudou recentemente e o que concluímos da última vez. O analista abre várias ferramentas, copia trechos para um ticket e escreve um resumo que a próxima pessoa precisa reler.

Um agente bem delimitado assume essa coleta e essa escrita. Ele lê o alerta, consulta as fontes que recebeu permissão para acessar, confere os runbooks e os casos anteriores do próprio time e devolve uma nota estruturada: o que aconteceu, o que ele consultou, o que não conseguiu verificar, uma prioridade sugerida e um próximo passo sugerido para uma pessoa executar.

Três tarefas se encaixam bem nesse padrão:

• Triagem: classificar, eliminar duplicidades e agrupar alertas, e então propor uma prioridade com a evidência por trás dela.
• Enriquecimento: anexar ao alerta o contexto de ativo, responsável, histórico e referências antes que um analista o abra.
• Relatórios: redigir a linha do tempo do incidente, a passagem de turno e o resumo periódico para a gestão.

Nenhuma delas exige a capacidade de alterar algo. Esse é o ponto. O time ganha tempo e consistência, e o raio de impacto de um erro continua pequeno.

Por que começar com acesso somente de leitura?

Somente leitura não é um primeiro passo tímido. É a configuração que permite aprender como o agente se comporta enquanto o custo de uma resposta errada é um minuto perdido, e não uma indisponibilidade. Um resumo errado pode ser corrigido. Um servidor isolado por engano não volta ao ar com um pedido de desculpas.

O princípio vem da prática padrão de autorização: dê a cada identidade o menor acesso necessário para a tarefa e verifique esse acesso a cada requisição, e não só uma vez na configuração. O [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) descreve bem isso, incluindo negação por padrão e verificações por requisição. Aplique ao agente o que você aplicaria a um prestador de serviço: identidade própria, credenciais próprias e restritas, sem login compartilhado de analista.

Na prática, somente leitura significa:

• Uma identidade de serviço dedicada ao agente, separada de qualquer conta humana.
• Acesso de consulta à fila de alertas, ao inventário de ativos, ao sistema de tickets e à base de conhecimento, sem permissão de escrita em sistemas de produção.
• Acesso de escrita apenas ao espaço de trabalho do próprio agente: notas em rascunho, relatórios em rascunho e um registro das ações dele.
• Credenciais que podem ser revogadas em um só lugar sem quebrar outras ferramentas.

Um teste útil: se as credenciais do agente vazassem amanhã, o que alguém conseguiria fazer com elas? Com essa configuração, a resposta deve ser que a pessoa poderia ler alguns dados que o agente já lê, e nada além disso.

Como a triagem de alertas deve funcionar, passo a passo?

A triagem é um bom primeiro fluxo porque é repetitiva, costuma estar bem documentada nos times e é fácil de conferir com o que os analistas decidiram. Monte-a como uma sequência fixa, e não como uma conversa aberta. Uma sequência previsível é mais fácil de testar e de auditar.

Este é um plano que o time pode seguir para um único tipo de alerta, como alertas de login suspeito:

• Passo um: defina o tipo de alerta e escreva o que uma boa nota de analista contém para ele. Inclua as perguntas que eles sempre fazem.
• Passo dois: liste as fontes que o agente pode ler para esse tipo de alerta, e nada além disso. Cada fonte recebe uma credencial restrita, somente de leitura.
• Passo três: entregue ao agente o runbook do time para esse tipo de alerta como material de referência, não como um roteiro a executar.
• Passo quatro: exija uma saída fixa: resumo, lista de evidências com a fonte de cada item, o que não foi verificado, prioridade sugerida e próximo passo sugerido para uma pessoa.
• Passo cinco: rode o agente em modo sombra. Ele produz notas para alertas passados e atuais, mas os analistas trabalham como de costume e comparam depois.
• Passo seis: revise as divergências toda semana. Atualize o runbook, as fontes ou o formato de saída, e não apenas as instruções.
• Passo sete: deixe os analistas usarem a nota como ponto de partida, com um jeito de um clique para marcá-la como errada ou incompleta.

O campo mais valioso é o que informa o que não foi verificado. Um agente que diz que não conseguiu acessar o inventário de ativos é muito mais seguro do que um que preenche a lacuna com um palpite plausível.

Que enriquecimento é seguro e qual não é?

O enriquecimento é a força discreta do agente: anexar o responsável por um host, o último ticket de mudança, os alertas anteriores na mesma conta e a seção relevante do runbook. O enriquecimento seguro lê de sistemas em que o seu time já confia e cita cada informação de volta à sua fonte.

Há um risco para o qual você precisa projetar. Alertas carregam conteúdo escrito por terceiros: assuntos de e-mail, strings de user agent, nomes de arquivo, texto de páginas web. Se o agente lê esse texto e o trata como instrução, um atacante pode conduzi-lo. Isso é prompt injection, e a [orientação da OWASP para prevenção de prompt injection](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) apresenta as defesas: separar instruções de dados, validar as saídas e limitar o que o modelo pode fazer mesmo que seja enganado.

O último ponto é o que mais importa em segurança. Não dá para garantir que um modelo nunca será enganado, então você garante que ser enganado não tenha consequência além de um rascunho ruim. O acesso somente de leitura faz exatamente isso.

Uma lista curta para o enriquecimento:

• Marque todo conteúdo de alerta e toda consulta externa como dado não confiável no contexto do agente.
• Nunca deixe o agente seguir links ou fazer consultas que ele monte a partir do texto do alerta sem uma lista de destinos permitidos.
• Remova ou sinalize conteúdo que pareça instrução dirigida ao agente.
• Exija que cada afirmação da nota aponte para uma fonte que o analista possa abrir.
• Mantenha dados sensíveis fora do alcance do agente, a menos que o tipo de alerta realmente precise deles, e registre cada acesso.

O [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) é uma boa lista de verificação para revisar com o seu arquiteto de segurança antes de entrar em produção, pois nomeia diretamente riscos como autonomia excessiva e tratamento inseguro de saídas.

Como redigir relatórios em que as pessoas confiem?

Os relatórios são onde o agente mais economiza tempo de escrita e onde a confiança é mais fácil de perder. Um relatório que flui bem, mas contém um único detalhe inventado, ensina os leitores a desconfiar de tudo.

A solução é redigir a partir de registros, não de memória. O agente monta a linha do tempo do incidente com base em entradas de ticket, horários de alertas e notas de analistas, e cada frase remete a um desses registros. Onde os registros se contradizem ou faltam, o rascunho diz isso com clareza em vez de suavizar.

Tipos de relatório úteis:

• Passagem de turno: alertas em aberto, o que já foi tentado, o que está pendente e com quem.
• Rascunho de relatório de incidente: linha do tempo, ativos afetados, ações tomadas por pessoas, dúvidas em aberto.
• Resumo periódico para a liderança: temas, fontes recorrentes de ruído, itens aguardando decisão.
• Pacotes de evidências para revisores, que combinam com a abordagem de Agentes de IA para empresas fintech: suporte, risco e compliance.

Mantenha os papéis claros. O agente redige, um analista edita e assina, e o relatório final registra quem o aprovou. Se a sua organização também dá suporte a auditores, valem os mesmos hábitos de evidência usados em um time de auditoria interna: amostras, achados e rastreabilidade até o registro.

Um relatório é tão confiável quanto a frase mais fraca que o leitor não consegue rastrear até um registro.

Onde as ações de resposta devem parar?

A resposta é a extensão tentadora: se o agente consegue reconhecer uma conta comprometida, por que não deixá-lo desativar a conta? Porque o custo de errar é assimétrico. Um falso positivo que bloqueia um executivo sênior no meio de uma negociação, ou que isola um servidor de produção, é um incidente real criado pela sua própria ferramenta.

Trate a resposta como uma decisão separada, com portão próprio, e não como um recurso que chega junto com a triagem. O [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) é uma boa referência para estruturar essa conversa: mapear o risco, medi-lo, gerenciá-lo e definir a responsabilidade antes que a capacidade exista.

Use este guia de decisão para qualquer ação proposta:

• A ação é reversível em poucos minutos por uma pessoa com um passo documentado? Se não, o agente nunca a executa.
• A ação está em uma lista aprovada de ações estreitas, como adicionar uma nota, atribuir um ticket ou pedir informação a um usuário? Se não, ela continua humana.
• Um analista identificado aprova cada ocorrência antes de ela rodar? Se não, ela continua humana.
• A ação registra quem aprovou, o que o agente viu e o que mudou? Se não, não a habilite.
• Ela passou por um conjunto de testes com alertas passados, incluindo os enganosos, sem nenhuma proposta insegura? Se não, mantenha-a em forma de rascunho.

Mesmo assim, o agente propõe e o analista executa ou confirma. Ações como desativar contas, isolar hosts, bloquear tráfego ou apagar mensagens continuam sendo decisões humanas nesse modelo.

Cenário ilustrativo: um alerta de login dispara para uma pessoa do financeiro conectando-se de um local incomum. O agente lê o log de acesso, encontra a solicitação de viagem da pessoa no sistema de tickets, observa dois alertas semelhantes anteriores encerrados como benignos e lista um histórico de redefinição de senha ao qual não teve acesso. A nota sugere prioridade média e recomenda que o analista contate o usuário para confirmar. Ela não bloqueia a conta. O analista liga, confirma a viagem e encerra o alerta com uma linha, e a nota do agente passa a ser o registro do caso.

Como a Be Human trata esse tema?

A Be Human projeta, implementa e opera agentes de IA personalizados sob controle humano. Para um time de segurança da informação, o primeiro trabalho define um papel útil, como a triagem de alertas de um único tipo, junto com a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. O acesso começa somente de leitura, com identidade própria e permissões restritas. A operação gerenciada inclui monitoramento, avaliações recorrentes com alertas passados, manutenção de integrações, revisão de permissões e resposta a incidentes do próprio agente, com melhorias controladas. O serviço é remoto, em português e inglês.

Como saber se o agente está funcionando?

Defina como é o sucesso antes do lançamento e torne-o observável. Na triagem, isso pode ser se os analistas aceitam a prioridade sugerida, com que frequência as notas são marcadas como incompletas e quanto tempo o analista leva até a primeira decisão. Nos relatórios, pode ser quantas edições um rascunho exige antes da assinatura.

Monte um conjunto fixo de avaliação com alertas passados reais, incluindo os difíceis, os ruidosos e os deliberadamente enganosos, e rode-o de novo sempre que mudar instruções, fontes ou modelos. O [guia da Anthropic sobre avaliações para agentes de IA](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) é uma referência prática para montar esse conjunto. Adicione rastreamento para ver quais fontes o agente leu e quais passos executou em cada nota.

Se você também mantém um service desk interno, os padrões de acesso se sobrepõem aos de IA para gestão de facilities: ordens de serviço e aprovações, e o mesmo raciocínio vale para o trabalho recorrente e os relatórios de outras equipes de operações.

Perguntas frequentes

Um agente de IA pode substituir um analista de segurança? Não. O agente cuida de reunir, comparar e redigir, o que libera os analistas para o julgamento, a investigação e a comunicação. Decisões, aprovações e qualquer alteração em um sistema continuam com as pessoas.

É seguro dar a um agente acesso a logs de segurança? Pode ser, se o acesso for somente de leitura, limitado às fontes de que uma tarefa específica precisa, ligado a uma identidade própria e registrado. Trate o conteúdo dos logs como não confiável, pois atacantes podem inserir texto neles, e garanta que um agente enganado não consiga fazer nada além de escrever um rascunho.

O agente deve tomar ações de resposta automáticas? Só depois de uma revisão separada, e apenas para ações estreitas e reversíveis de uma lista aprovada, com uma pessoa identificada aprovando cada uma. Muitos times decidirão que o agente nunca deve agir, e é uma escolha sensata. O valor da triagem e dos relatórios não depende de poderes de resposta.

Por onde o time deve começar? Escolha um tipo de alerta com runbook claro e volume constante. Rode o agente em modo sombra ao lado dos analistas, compare as notas dele com as decisões deles, corrija as lacunas e só então deixe os analistas usarem a saída como ponto de partida em casos reais.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.