GONDOR e RAVEN: como estruturei meu primeiro agente de segurança

TL;DR: Estruturei a GONDOR como uma plataforma interna de agentes de Cybersecurity. O primeiro agente é o RAVEN, criado para apoiar Threat Hunting e investigações por meio de workflows controlados no n8n, integração via MCP e credenciais protegidas. A primeira versão consulta Defender e Cloudflare, correlaciona evidências e permanece totalmente read-only.

O RAVEN nasceu de um problema muito prático.

Durante uma investigação, o analista costuma alternar entre ferramentas, adaptar consultas, copiar resultados e tentar reconstruir uma linha do tempo. O trabalho exige conhecimento técnico, mas uma parte considerável do tempo é consumida por tarefas repetitivas.

Minha ideia não foi criar uma IA que substituísse o analista. Foi construir uma camada segura de automação para reduzir esse trabalho operacional sem entregar credenciais ou liberdade irrestrita ao modelo.

Por que GONDOR e RAVEN

GONDOR é o nome da plataforma.

A referência vem de O Senhor dos Anéis. Gondor representa uma das grandes linhas de defesa da Terra-média. No projeto, o nome identifica o ecossistema que reúne agentes, workflows, integrações, controles de acesso, credenciais e documentação.

RAVEN é o primeiro agente da plataforma.

O nome significa "corvo" em inglês e também lembra o papel dos corvos em Game of Thrones: transportar informações entre diferentes lugares. A analogia combina com um agente que consulta fontes distintas e devolve inteligência consolidada.

RAVEN também funciona como sigla:

Response, Analysis, Visibility, Events & Notifications

A referência aos dois universos é intencional. GONDOR representa a estrutura de defesa. RAVEN representa quem busca, conecta e transporta a informação.

Agente não é a mesma coisa que workflow

Essa foi uma das primeiras definições importantes do projeto.

O agente interpreta o pedido, escolhe a capacidade necessária, analisa os resultados e organiza a resposta. O workflow executa uma tarefa previsível.

Na arquitetura atual:

Analista
  → Claude ou Codex
  → instruções do RAVEN
  → MCP
  → workflows no n8n
  → APIs de segurança
  → resultado sanitizado

O raciocínio acontece no cliente compatível com MCP. A execução controlada acontece no n8n.

Assim, o RAVEN não é apenas um fluxo isolado. Ele é formado pelas instruções do agente, pelas ferramentas expostas via MCP, pelos workflows autorizados e pelas políticas que limitam o que pode ser executado.

Os três primeiros workflows

O MVP começou com três capacidades.

Defender Hunting

Recebe parâmetros de investigação ou uma consulta validada, executa o hunting no Microsoft Defender e devolve apenas os campos necessários para análise.

Cloudflare Security Events

Consulta eventos de segurança do Cloudflare para localizar atividade relacionada a IP, domínio, rota ou outro indicador dentro de uma janela de tempo definida.

Hunting e correlação

Combina resultados das fontes disponíveis para ajudar o analista a identificar relações, organizar evidências e construir uma visão inicial da investigação.

A ideia é permitir uma solicitação como:

"Investigue este indicador nas fontes disponíveis, considere as últimas 24 horas e organize os eventos encontrados."

O agente interpreta a intenção, chama os workflows necessários e apresenta os resultados de forma estruturada. A conclusão continua sendo responsabilidade do analista.

Onde ficam as credenciais

O principal requisito de segurança era simples: o modelo não poderia receber os tokens das ferramentas.

As credenciais das APIs ficam armazenadas no cofre de credenciais do n8n e são utilizadas somente pelos nós responsáveis pelas consultas.

O fluxo funciona assim:

1. O analista envia uma solicitação.
2. O cliente chama uma ferramenta do RAVEN por MCP.
3. O n8n valida os parâmetros recebidos.
4. O workflow usa internamente a credencial da API.
5. A consulta é executada com permissão somente de leitura.
6. O resultado é filtrado antes de retornar ao agente.

Os tokens não ficam no prompt, na IDE, no Confluence, no repositório ou na resposta do MCP.

Segurança por design

Expor automações de segurança para um agente exige mais do que colocar um WAF na frente do endpoint.

A primeira versão foi estruturada com algumas decisões importantes:

• permissões read-only nas integrações;
• workflows específicos, sem ferramenta genérica para executar qualquer requisição;
• autenticação e controle de acesso ao MCP;
• credenciais separadas por integração;
• validação de parâmetros, período e volume de resultados;
• registro das execuções;
• acesso de uso separado do acesso administrativo ao n8n;
• ausência de ações automáticas de contenção.

O RAVEN pode consultar, correlacionar e apoiar a análise. Ele não pode bloquear IP, isolar dispositivo, revogar sessão ou alterar incidente.

Esse limite foi proposital. Antes de automatizar uma decisão de impacto, preciso validar qualidade das respostas, rastreabilidade, comportamento das integrações e ganho real para o time.

O que mudou na rotina

O primeiro ganho foi transformar consultas que dependiam de navegação manual em capacidades reutilizáveis.

Em vez de cada analista reconstruir o mesmo caminho em diferentes ferramentas, o workflow centraliza a integração e entrega uma saída padronizada. Isso facilita o uso por outros integrantes da equipe e reduz a dependência de conhecimento sobre cada API.

O valor não está apenas em "perguntar para uma IA". Está em controlar o que a IA pode chamar, quais dados pode receber e quais limites devem ser respeitados.

Essa diferença separa um prompt interessante de uma capacidade operacional de segurança.

Documentação e governança

A documentação da plataforma registra:

• objetivo e escopo da GONDOR;
• papel do RAVEN;
• arquitetura MCP;
• workflows disponíveis;
• permissões utilizadas;
• responsáveis pelas integrações;
• modelo de acesso;
• logs e auditoria;
• limitações conhecidas;
• roadmap de evolução.

Os detalhes públicos deste artigo foram sanitizados. Endpoints, identificadores, consultas internas, nomes de ambientes, credenciais e evidências reais não fazem parte desta publicação.

Próximos passos

A evolução do projeto inclui:

• ampliar as fontes de investigação;
• melhorar a correlação de indicadores;
• criar templates de relatórios;
• medir tempo economizado por investigação;
• adicionar testes de prompt injection e abuso das ferramentas;
• versionar workflows e instruções;
• definir critérios de aprovação para futuras ações de resposta.

Automatizar contenção não é o próximo passo automático. Primeiro vêm observabilidade, confiança e governança.

Minha principal conclusão

Construir um agente de segurança não é apenas conectar um modelo a várias APIs.

O trabalho mais importante está em desenhar permissões, restringir ferramentas, proteger credenciais, validar entradas, registrar execuções e deixar claro onde termina a automação e começa a decisão humana.

O RAVEN está sendo uma experiência prática de como aplicar IA à segurança sem abandonar os fundamentos.

A GONDOR é a estrutura. O RAVEN é o primeiro agente. Os workflows são as capacidades controladas que tornam essa ideia útil no dia a dia.