Agentes de IA para Segurança e DevOps: Produtividade ou Risco?

Agentes frontier, no contexto da AWS, são construídos sobre o Amazon Bedrock Agents com acesso a grupos de ação (action groups) que invocam ferramentas reais: AWS Security Hub, GuardDuty, Systems Manager Run Command, Lambda, e até APIs externas via HTTP. A diferença em relação a um chatbot com RAG é fundamental: o agente não apenas responde — ele planeja, executa, observa o resultado e itera. Isso é o loop ReAct (Reason + Act) operando sobre infraestrutura real.

Em um ambiente financeiro regulado — PCI-DSS, SOC 2, BACEN 4.658, LGPD — cada ação do agente precisa ser auditável, reversível onde possível, e bounded por princípios de menor privilégio. O problema é que os modelos de linguagem grandes (LLMs) são inerentemente não-determinísticos. A mesma instrução pode gerar sequências de ação diferentes em execuções distintas. Para um pipeline de ETL isso é tolerável; para um agente que tem permissão de modificar security groups ou executar scripts em instâncias EC2, é um risco operacional de primeira ordem.

O Bedrock Agents oferece rastreabilidade via InvokeAgent com enableTrace: true, que expõe o chain-of-thought e cada chamada de ferramenta no CloudWatch Logs. Isso é necessário, mas não suficiente. A rastreabilidade sem controle de escopo de permissão é apenas um log bonito do desastre.

Depois de trabalhar com times de plataforma e segurança em múltiplos contextos, identifiquei quatro padrões recorrentes de como agentes de IA são implantados para segurança e DevOps. Não são categorias teóricas — são escolhas reais com trade-offs reais.

Padrão 1 — Agente Totalmente Autônomo: O agente recebe um objetivo de alto nível ('audite a postura de segurança desta conta AWS e corrija desvios de CIS Benchmark') e executa sem intervenção humana. Usa Bedrock Agents com action groups para Security Hub, Config, e IAM Access Analyzer. O risco principal é o blast radius de uma decisão errada do modelo — uma regra de SCP aplicada incorretamente pode bloquear workloads de produção.

Padrão 2 — Semi-Autônomo com Aprovação Humana: O agente planeja e propõe, mas cada ação destrutiva ou de alto impacto passa por um checkpoint de aprovação humana via Step Functions .waitForTaskToken. Este é o padrão que eu defendo para ambientes financeiros regulados.

Padrão 3 — Assistido (Copilot): O agente apenas sugere; um engenheiro executa. Toda a inteligência está na geração de runbooks, análise de logs e triagem de alertas. Zero autonomia de execução.

Padrão 4 — Pipeline Determinístico com IA Pontual: Automação tradicional (Step Functions, EventBridge, Lambda) com LLM invocado apenas para tarefas específicas de linguagem natural — classificar a severidade de um alerta, gerar um sumário de incidente, ou traduzir um CVE em impacto de negócio. O agente não tem ferramentas; é apenas um transformador de texto dentro de um fluxo controlado.

O risco mais subestimado em agentes de segurança autônomos não é o modelo alucinar — é o modelo ser induzido a agir de forma maliciosa por dados que ele processa. Isso é prompt injection indireta: um finding do Security Hub que contém um payload crafted no campo description pode instruir o agente a executar ações não intencionadas. Em ambientes onde o agente tem permissão de ec2:AuthorizeSecurityGroupIngress ou iam:AttachRolePolicy, o impacto é imediato e potencialmente irreversível.

A mitigação começa no IAM. Para o Padrão 2 (semi-autônomo), o execution role do agente deve usar IAM conditions restritivas. Por exemplo, para remediação de Security Hub, o role deve ter securityhub:UpdateFindings apenas com condition StringEquals: aws:ResourceTag/Environment: sandbox. Ações em produção exigem um segundo role assumido explicitamente após aprovação humana, com sts:AssumeRole registrado no CloudTrail.

Para o Padrão 4, o design é mais limpo: o Lambda que invoca bedrock:InvokeModel tem apenas bedrock:InvokeModel no seu policy. O resultado do LLM é tratado como dado não confiável — passa por um parser determinístico que extrai apenas campos esperados (severidade, categoria, impacto estimado) antes de alimentar o Step Functions. Isso elimina completamente o risco de prompt injection porque o LLM nunca tem acesso a ferramentas de execução.

Um detalhe operacional crítico: o Bedrock Agents tem um timeout padrão de 30 segundos por invocação de ferramenta. Em workflows de segurança onde uma ferramenta pode levar 2–3 minutos (ex: rodar um AWS Config rule evaluation), isso causa falhas silenciosas. Configure actionGroupExecutor com Lambda de alta memória (512 MB+) e ajuste o timeout da função para 300 segundos, com retry configurado no próprio Bedrock Agents (maxRetries: 2, stopSequences bem definidos).

Um agente de segurança sem observabilidade adequada é um ator privilegiado opaco na sua conta AWS. O enableTrace: true no Bedrock Agents gera eventos de trace no CloudWatch Logs com a estrutura modelInvocationInput, modelInvocationOutput, rationale, invocationInput (para cada ferramenta), e observation. Isso é o mínimo — não o suficiente.

Para ambientes financeiros, eu implemento três camadas adicionais:

1. Métricas customizadas de comportamento do agente: Um Lambda wrapper que instrumenta cada invocação do agente e publica métricas no CloudWatch Metrics com dimensões AgentId, ActionGroup, ToolName, e DecisionOutcome. Isso permite criar alarmes em ToolInvocationRate (pico anormal de chamadas a ferramentas) e RemediationActionCount (número de ações de remediação por hora).

2. Correlação com CloudTrail via Athena: Cada sessionId do Bedrock Agent é propagado como tag nas chamadas de API subsequentes via Lambda context. Isso permite, via Athena sobre CloudTrail S3, reconstruir exatamente quais API calls foram feitas como consequência de uma decisão específica do agente — essencial para investigação forense.

3. SLOs de confiança do agente: Defino um SLO de AgentDecisionAccuracy baseado em amostragem: um subconjunto das decisões do agente é revisado por um humano e classificado como correto/incorreto. Se a taxa de decisões corretas cair abaixo de 95% em uma janela de 7 dias, o agente é automaticamente rebaixado para o Padrão 3 (copilot) via feature flag no Parameter Store. Isso é o circuit breaker de confiança que a maioria das implementações ignora.

PCI-DSS v4.0, SOC 2 Type II e BACEN 4.658 foram escritos para sistemas determinísticos. Nenhum deles tem controles explícitos para agentes de IA não-determinísticos com capacidade de execução. Isso cria um gap de governança real que precisa ser endereçado por design, não esperado que os auditores resolvam.

Os três problemas de governança que encontro consistentemente:

Segregação de funções (SoD): Um agente que pode tanto detectar quanto remediar viola o princípio de SoD. A solução é arquitetural: o agente de detecção tem um role IAM separado do agente de remediação, e o workflow de aprovação no Step Functions é o ponto de cruzamento auditável.

Change management para ações de agente: Toda remediação automática é tecnicamente uma mudança de configuração. Em ambientes com ITSM (ServiceNow, Jira Service Management), o agente deve criar um change record antes de executar qualquer ação. Isso pode ser feito via action group que chama a API do ITSM — o agente não executa sem um change ID válido.

Versionamento e rollback de decisões de agente: Diferente de código, você não pode fazer rollback de um modelo de linguagem para uma versão anterior de forma simples. O que você pode fazer é versionar o agentAliasId — cada alias aponta para uma versão específica do agente com um conjunto fixo de action groups e instruções de sistema. Mantenha pelo menos duas versões em produção e implemente um mecanismo de fallback via Lambda que detecta degradação de performance e redireciona para a versão anterior.

A realidade é que os times de compliance vão pedir evidências de que o agente não pode agir fora do escopo definido. A única resposta convincente é mostrar a política IAM do execution role, o Step Functions state machine com os checkpoints de aprovação, e o CloudTrail mostrando que nenhuma ação foi executada sem o token de aprovação correspondente.