Não tenho time de segurança: como usar um agente de AI sem perder o controle

Um SaaS sem time de segurança pode passar a rotina de segurança para um agente de AI sem perder o controle sobre ela. A Azion Platform bloqueia ataques em tempo real, e um agente de codificação agendado, como o Claude Code, lê os eventos de tráfego e bloqueia IPs abusivos com prazo de validade. Quem define até onde o agente vai é você, já que a Azion limita o acesso dele pelo token e você define no arquivo de instruções por quanto tempo cada bloqueio vale e o que precisa da sua aprovação.

Em time enxuto, a segurança costuma perder para a próxima feature. Ninguém tem uma tarde livre para olhar log de WAF, e o ataque costuma aparecer justo na semana do lançamento. Na prática, a proteção fica no default, e alguém só olha os eventos depois que um cliente reclama.

Entregar tudo a um agente, sem limites, troca um problema por outro. Um agente com acesso amplo à conta pode errar em escala, e você só descobre depois. Por isso, o caminho que funciona é dividir o trabalho, deixando a rotina com o agente enquanto você define as regras do jogo e aprova o que muda a política.

Usar um agente de AI na segurança significa perder o controle?

Não, desde que o acesso do agente seja limitado na plataforma, e não só pelas instruções dele. Na Azion, o agente age com o token que você criou, que só dá acesso aos recursos que você liberou, como as Network Lists. A lista em que ele escreve, a data de validade de cada bloqueio e o que precisa da sua aprovação ficam nas instruções e nas ferramentas liberadas para ele, e cada requisição bloqueada fica registrada no Real-Time Events.

Cada parte do sistema tem um papel diferente:

O agente também não fica no caminho da requisição, e se ele falhar ou atrasar, o tráfego continua passando pelo Firewall da Azion com as mesmas regras de antes. Se ele interpretar mal um evento, pode bloquear um IP legítimo, mas não altera regras do Firewall nem do WAF, e as perguntas frequentes mostram como desfazer o bloqueio.

O que a Azion bloqueia sozinha, sem agente?

A primeira camada não depende de AI porque DDoS Protection, WAF, rate limit e Bot Manager decidem cada requisição no data center que a recebe, e o bloqueio não espera ninguém acordar.

Este post parte de um app que já está atrás da Azion com essas proteções ligadas. Se o seu ainda não está, o caminho está no post Como proteger um SaaS que começou a sofrer ataques, sem migrar nem reescrever nada.

Quais controles a Azion dá sobre o agente de AI?

Estes controles definem e registram o que o agente faz:

• O agente se conecta aos MCP servers da Azion com um token pessoal, e é o token que decide o que as ferramentas de escrita podem mudar. A documentação dos MCP servers orienta limitar o token aos recursos de que o agente precisa. Na Azion, o acesso de cada usuário à conta é definido em Teams Permissions. Crie um usuário só para o agente em Users Management e coloque-o em um time com apenas View Real-Time Events, para ler os eventos, e View Network Lists e Edit Network Lists, para ler e escrever nas Network Lists. O token do agente é gerado com esse usuário, e assim o agente não usa o token de quem administra a conta.
• O token pessoal tem data de expiração, de 1 dia a 1 ano ou uma data que você escolhe, e não pode ser alterado depois de criado. Prefira uma validade curta, renove o token antes de ele vencer e configure um alerta para quando o job falhar. Para revogar o acesso do agente, basta apagar o token.
• Cada IP entra na lista com uma data de validade, e a cada execução o agente regrava a lista, o que descarta os itens vencidos. É esse ciclo que encerra um bloqueio errado, como explicado mais adiante.
• Toda ferramenta dos MCP servers que cria, altera ou apaga aceita dry_run, que devolve a requisição exata da API sem enviá-la. Nas primeiras semanas, o agente só mostra o que faria, e você confere.
• Cada requisição bloqueada aparece no Real-Time Events com o IP, a rota e o status 403. Junto com o log do job, isso mostra por que o IP entrou na lista e o que aconteceu com as requisições dele.

Os controles funcionam em duas camadas. Na Azion, o time do agente define a que tipo de recurso ele tem acesso, e a permissão Edit Network Lists vale para todas as listas da conta. No próprio agente, o arquivo de instruções define em qual lista ele escreve e quando usa o dry_run, e um conjunto fechado de ferramentas liberadas define o que ele pode chamar, que são a create_graphql_query do observe, a get_network_list e a update_network_list do secure e as que mandam o resumo. No modo não interativo do Claude Code (claude -p), uma ferramenta que precisa de aprovação só roda se estiver liberada, por exemplo em --allowedTools; as outras são negadas. A action do GitHub roda o Claude Code nesse mesmo modo.

Como o agente de AI monitora o tráfego do SaaS?

O agente lê o Real-Time Events da sua conta a cada execução. Ele roda em modo não interativo em um job agendado, por exemplo no GitHub Actions, e segue um arquivo de instruções versionado no repositório.

Dois MCP servers fazem o trabalho. No observe, a ferramenta create_graphql_query escreve uma query GraphQL a partir de um objetivo em linguagem natural e a executa na sua conta, com a fonte de dados real-time-events. No secure, a ferramenta update_network_list grava os itens da lista de bloqueio.

Os dados vêm do dataset workloadEvents, o mesmo do Real-Time Events. Cada requisição fica consultável de 20 a 40 segundos depois de acontecer e é mantida por 7 dias. Os campos que mais interessam ao agente são estes:

• remoteAddress: o IP de quem fez a requisição.
• requestUri e host: a rota e o domínio atacados.
• status: o código HTTP, em que 429 indica rate limit e 403 indica uma regra Deny.
• wafBlock, wafMatch e wafAttackFamily: se o WAF bloqueou, as infrações encontradas e a família do ataque, como SQL injection ou XSS.

Com isso, o agente responde às perguntas que você faria se tivesse tempo, como quais IPs mais receberam 429 no login, quais rotas concentram bloqueios do WAF e se algum IP aparece nos dois resultados.

Como o agente bloqueia IPs sem mexer na política de segurança?

Escrevendo em uma Network List, sem mexer nas regras do Firewall. Uma Network List é uma lista de IPs, ASNs ou países que as regras do Firewall consultam, com até 20.000 itens. A regra que bloqueia quem está na lista é sua. Você a cria uma vez no Firewall, pelo Console, e o token do agente não tem permissão para alterá-la. O agente altera só o conteúdo da lista, que ele grava direto pela API, pelo MCP server secure.

A regra fica no Rules Engine do Firewall, com o critério Network matches e a Network List de bloqueios escolhida pelo nome, e com o comportamento Deny (403 Forbidden). Para que o Firewall use Network Lists, o módulo Network Shield precisa estar ligado. As listas do tipo IP/CIDR aceitam endereços IPv4 e IPv6, e os outros critérios e comportamentos estão na documentação do Rules Engine do Firewall.

Nas Network Lists do tipo IP/CIDR, o prazo de validade é escrito depois do endereço, com o prefixo --LT e um horário UTC:

203.0.113.45 --LT2026-10-29T18:00:00Z
198.51.100.0/24 --LT2026-10-30T06:00:00Z

Na Azion, os itens vencidos saem da lista na próxima vez que ela é gravada, como explica a documentação de Network Lists, e por isso a cada execução o agente grava a lista inteira, mesmo quando não há IP novo.

A mudança na lista vale assim que ela é gravada, e uma alteração nos itens de uma lista que já está em uso por regras chega ao tráfego em poucos segundos. A partir daí, as requisições daquele IP recebem 403 e aparecem no Real-Time Events com esse status; com o Debug Rules ligado, o campo stacktrace mostra também a regra que bloqueou, como explica o post sobre proteger um SaaS sem migrar.

Quando o agente age sozinho e quando ele pede aprovação?

O agente age sozinho no que é reação e pede aprovação no que é política. Bloquear um IP por tempo limitado é reação, então ele faz e avisa. Mudar o rate limit, ligar o modo de bloqueio do WAF ou criar uma regra nova é política, então ele propõe a mudança no resumo, e você decide se aplica no Console.

Um arquivo de instruções como este define essa fronteira:

# Rotina de segurança do SaaS (roda a cada 15 minutos)

1. Consulte workloadEvents desde a execução anterior para app.seusaas.com.br.
2. Bloqueie na Network List "bloqueio-temporario-agente", por 6 horas,
   IPs com mais de 200 respostas com status 429 em /login ou mais de 20 bloqueios do WAF.
3. Nunca bloqueie IPs da lista "clientes-conhecidos" nem faixas maiores que /24.
4. Regrave a lista inteira a cada execução, mesmo sem IP novo, mantendo o item fixo criado junto com a lista.
5. Mande um resumo no canal #seguranca: IPs bloqueados, motivo e rota.
6. Se o mesmo padrão aparecer em 3 execuções seguidas, proponha no resumo
   uma regra permanente. Não aplique.
7. Não altere Firewall, WAF nem regras pela API. Só a Network List.

Os números do arquivo são exemplos, a calibrar com o tráfego real do seu app. Com o resumo, você acompanha o que o agente fez sem abrir o Console. Em vez de descobrir o ataque pelo cliente, você lê no Slack que 14 IPs foram bloqueados no login às 3h da manhã e decide, no café, se aprova a regra permanente que o agente sugeriu.

Passo a passo para usar um agente de AI na segurança do SaaS sem perder o controle

1. Coloque o app atrás da Azion, com WAF, rate limit e Bot Manager, como mostra o post sobre proteger um SaaS sem migrar.
2. No Console, em Network Lists, crie uma lista do tipo IP/CIDR chamada bloqueio-temporario-agente, com 192.0.2.1 no campo List. Esse endereço é reservado para documentação e fica na lista como item fixo, sem data de validade, porque uma Network List precisa ter pelo menos um item. Se quiser, crie também uma lista clientes-conhecidos com os IPs dos seus clientes, que o agente consulta antes de bloquear.
3. No Firewall do app, confira na aba Main Settings se o Network Shield está ligado. Na aba Rules Engine, crie uma regra com o critério Network matches bloqueio-temporario-agente e o comportamento Deny (403 Forbidden).
4. Para ver no stacktrace a regra que bloqueou, ligue a opção Debug Rules na aba Main Settings do mesmo Firewall.
5. No menu da conta, em Teams Permissions, crie um time com View Real-Time Events, View Network Lists e Edit Network Lists. Em Users Management, crie um usuário só para o agente, com um e-mail que você controla, escolha esse time no campo Teams e ative a conta pelo e-mail de convite.
6. Entre no Console com o usuário do agente e, em Personal Tokens, no menu da conta, gere o token pessoal com uma validade curta. Anote a data de vencimento para renovar o token antes dela.
7. Crie um repositório no GitHub para o agente e adicione nele o arquivo de instruções, com as regras de bloqueio (quantas respostas 429 ou bloqueios do WAF levam um IP para a lista), o prazo de cada bloqueio, as exceções, o canal do resumo e a ordem de usar dry_run nas primeiras semanas.
8. Prepare o repositório para o agente.
   • Instale o Claude GitHub App e dê ao workflow a permissão id-token: write, que a action usa para se autenticar.
   • Para mandar o resumo, escolha uma ferramenta para o canal, como um MCP server do Slack.
   • Guarde o token da Azion, a chave da Claude API e o token do canal do resumo como secrets do repositório.
9. Agende o agente no GitHub Actions com um workflow que usa a action anthropics/claude-code-action.
   • Use o gatilho schedule e um prompt que manda seguir o arquivo de instruções.
   • Em claude_args, passe um --mcp-config com os MCP servers observe (https://observe-mcp.azion.com/mcp) e secure (https://secure-mcp.azion.com/mcp), autenticados pelo cabeçalho Authorization: Token com o token do agente, e com o MCP server do canal do resumo.
   • No mesmo claude_args, passe um --allowedTools com o nome exato de cada ferramenta liberada, no formato mcp__<servidor>__<ferramenta>, usando os nomes de servidor do --mcp-config. Por exemplo, mcp__azion-observe__create_graphql_query, mcp__azion-secure__get_network_list e mcp__azion-secure__update_network_list, mais as ferramentas que o agente usa para o resumo.
   • Configure um alerta para quando o workflow falhar.
10. Acompanhe os resumos e ajuste as regras de bloqueio do arquivo de instruções. Quando os resultados estiverem certos, tire do arquivo a ordem de usar dry_run, e o agente passa a gravar na Network List de bloqueios.

Controle automatizado para você focar no que importa

Sem time de segurança, quem costuma descobrir o ataque é o desenvolvedor, pela reclamação de um cliente ou por um pico no painel. Com o agente, a rotina sai da sua mão, mas o controle fica com você. As permissões do token e as regras do Firewall continuam valendo a cada execução, porque quem as aplica é a Azion.

Até você chega só o que precisa de decisão, como um padrão que se repetiu e virou proposta de regra permanente, e o resto do tempo vai para o produto.

Quer ajuda com a segurança do seu SaaS? Fale com um especialista da Azion ou crie uma conta gratuita para testar o fluxo com o seu app.

Perguntas frequentes

Como cuidar da segurança de um SaaS sem time de segurança? Deixe a mitigação em tempo real com a plataforma, com DDoS Protection, WAF, rate limit e Bot Manager, e passe a rotina para um agente de AI agendado, que lê os eventos, bloqueia IPs abusivos por tempo limitado e avisa. Você define as permissões e as regras de bloqueio do agente e aprova as mudanças na política.

É seguro usar um agente de AI na segurança do meu SaaS? Pode ser, quando o acesso do agente é limitado na plataforma e o que ele faz está definido nas instruções. Na Azion, ele age só com as permissões do token, que o limitam às Network Lists, e as instruções definem em qual lista ele escreve e por quanto tempo vale cada bloqueio. Cada requisição bloqueada fica registrada no Real-Time Events. Mudanças nas regras do Firewall e do WAF ficam com você, que aplica no Console o que o agente propõe.

Como limitar as permissões de um agente de AI na Azion? Limite o token que o agente usa. Crie em Users Management um usuário só para o agente, coloque-o em um time de Teams Permissions com o mínimo necessário, como View Real-Time Events, View Network Lists e Edit Network Lists, e gere com ele um token pessoal de validade curta. Assim, o agente não usa o token de quem administra a conta, e para revogar o acesso basta apagar esse token.

O que acontece se o job do agente parar de rodar? O tráfego continua protegido, porque o agente não fica no caminho da requisição, e o Firewall segue aplicando as mesmas regras. Os bloqueios que já estão na lista continuam valendo, por isso renove o token antes de ele vencer e configure um alerta para falhas do job. Para liberar um IP na hora, abra a Network List no Console, apague a linha desse IP no campo List e salve.

Como bloquear IPs automaticamente na Azion? Com uma Network List do tipo IP/CIDR referenciada por uma regra Deny no Firewall. O agente escreve os IPs na lista pelo MCP server secure, cada um com prazo de validade (--LT), e regrava a lista a cada execução para descartar os vencidos. A mudança vale assim que a lista é gravada.

E se o agente bloquear um cliente real? O bloqueio acaba na primeira execução do agente depois da data de validade. Para liberar na hora, apague a linha do IP na Network List, pelo Console, e inclua o IP na lista clientes-conhecidos para o agente não bloqueá-lo de novo. Uma lista de exceções com os IPs de clientes conhecidos, consultada pelo agente antes de bloquear, reduz esse risco.

Que agente de AI posso usar? Os MCP servers da Azion funcionam com clientes como Claude Code, Cursor, Codex e Gemini CLI. Para rodar de forma agendada, o cliente precisa de um modo não interativo, como o claude -p do Claude Code.

Quanto tempo leva entre o ataque e o bloqueio pelo agente? É a soma de 20 a 40 segundos para o evento aparecer no Real-Time Events, do intervalo até a próxima execução do agente e de poucos segundos para a mudança na Network List chegar ao tráfego. Enquanto isso, rate limit, WAF e DDoS Protection continuam agindo na própria requisição.