Velocidade e segurança com agentes de IA: um framework de controle para times de desenvolvimento

O desafio de escalar segurança com agentes de IA

Agentes de IA para programação — como o Kiro e o Claude Code — já fazem parte do dia a dia de muitos times de desenvolvimento. Com um simples prompt em linguagem natural, eles geram funcionalidades, escrevem testes e refatoram código. Em uma tarde, um único agente pode abrir dezenas de pull requests em diferentes repositórios.

Essa produtividade tem um custo: os agentes otimizam para completar tarefas na velocidade de uma máquina, sem qualquer compreensão do perfil de risco da organização. Além disso, por meio de protocolos como o Protocolo de Contexto de Modelo (MCP), eles ultrapassam os limites da IDE — chamando APIs, consultando bancos de dados e modificando infraestrutura inteira.

Para endereçar esse cenário, a AWS publicou um framework de controle de segurança de aplicações (AppSec) voltado especificamente para agentes de IA em desenvolvimento de software. O framework se organiza em dois pilares: controles no momento de autoria, que moldam o que o agente produz dentro da IDE, e controles no momento do build, que verificam e bloqueiam o que chega à produção. Os controles existentes do Ciclo de Vida de Desenvolvimento de Software Seguro (SDLC) continuam válidos e são peça central de uma estratégia de defesa em profundidade.

Os principais riscos identificados

O framework identifica sete categorias de risco, ordenadas por severidade:

R001 — Injeção de prompt e de contexto: agentes leem conteúdo não confiável (descrições de issues, páginas web, respostas MCP, arquivos README de pacotes de terceiros). Esse conteúdo pode redirecionar o agente para divulgar segredos ou invocar ferramentas sem consentimento. É o risco número um do OWASP Top 10 para Aplicações com Modelos de Linguagem (LLM). O tratamento recomendado é separar o agente que orquestra ações confiáveis daquele exposto a conteúdo não confiável, aplicando acesso mínimo de somente leitura ao segundo, e exigindo aprovação humana para ações irreversíveis.
R002 — Divulgação inadvertida de dados e configurações permissivas: agentes tendem a gerar políticas com permissões amplas demais, grupos de segurança abertos, armazenamento sem criptografia ou credenciais embutidas no código. O tratamento envolve documentos de steering com requisitos de segurança e varredura de política como código (Checkov, cfn-nag) na IDE e no pipeline.
R003 — Mudanças não controladas chegando à produção: a geração em velocidade de máquina pode propagar um padrão falho por vários repositórios antes de ser identificado. O tratamento inclui regras de proteção de branch, revisão humana obrigatória em pull requests e execuções de agente em sandbox.
R004 — Riscos na cadeia de suprimentos: agentes podem recomendar pacotes depreciados, referenciar versões com Vulnerabilidades e Exposições Comuns (CVEs) conhecidas ou até “alucinar” nomes de pacotes inexistentes. O tratamento é Análise de Composição de Software (SCA) no pipeline — por exemplo, com o Amazon Inspector ou Dependabot — e resolução de dependências via um registro controlado como o AWS CodeArtifact.
R005 — Acesso externo não controlado: sem restrições sobre quais ferramentas e dados o agente pode acessar via MCP, uma única integração mal configurada abre caminho para recursos sensíveis. O tratamento é escopar os servidores MCP ao mínimo necessário e auditar as invocações de ferramentas.
R006 — Alucinações e código incorreto: código que compila, passa no linting e parece razoável ainda pode estar funcionalmente errado — misusando APIs, introduzindo erros lógicos sutis ou implementando operações sensíveis de segurança de forma incorreta. O tratamento é combinar verificação determinística (Teste de Segurança de Aplicações Estático — SAST, testes unitários) com revisão não determinística (LLM como revisor).
R007 — Expansão de escopo: dado um prompt de correção de bug, o agente pode também refatorar código ao redor, desabilitar um teste instável ou reorganizar imports. O tratamento é um documento de especificação que define o que deve mudar e o que não deve.

Controles determinísticos versus não determinísticos

O framework diferencia dois tipos de mitigação:

Mitigações determinísticas [D] produzem o mesmo resultado toda vez. Linters, scanners SAST, detecção de segredos e política como código definem invariantes de segurança — sem credenciais hardcoded, sem políticas IAM com wildcard. Use quando a condição pode ser expressa como uma regra.
Mitigações não determinísticas [ND] usam o julgamento do modelo. Incluem documentos de steering, revisão por LLM e verificação de conformidade com especificações. Capturam problemas que as regras deixam passar, mas são probabilísticas. São a nova camada que o código gerado por IA exige — porque um agente pode produzir código que passa em todos os testes determinísticos e ainda assim estar funcionalmente errado.
Revisão humana [H] é a camada final para decisões que nenhum dos dois tipos de ferramenta consegue tomar. O ponto importante é: aplique onde o julgamento é realmente necessário, não em tudo. Rotear tudo para um humano gera fadiga de consentimento, onde revisores aprovam por reflexo e o controle perde valor.

Pilar 1: Controles no momento de autoria

Os controles de autoria atuam dentro da IDE, antes e logo após a geração do código.

Contexto como controle de segurança [ND]

Times de segurança escrevem invariantes de segurança como orientações em linguagem natural em um documento de steering — por exemplo: políticas IAM devem seguir o princípio do menor privilégio; credenciais devem vir do AWS Secrets Manager; grupos de segurança não podem permitir acesso irrestrito. Esse arquivo é carregado no contexto do agente no início de cada sessão, fazendo com que ele gere código com esses padrões por padrão. O steering reduz o volume de problemas que chegam ao pipeline, mas não substitui as verificações posteriores.

Especificações como limites de escopo [ND]

Antes de gerar código, exige-se uma especificação revisada que define o que deve mudar e o que não deve. Fluxos orientados por especificação criam um ponto de revisão humana na fase de design. Para correções de bug, a especificação inclui uma lista explícita de comportamentos que devem continuar funcionando — um limite escrito contra a expansão de escopo.

Acesso controlado a ferramentas via MCP [D + ND]

Servidores MCP atuam como gateways controlados entre o agente e ferramentas externas. O framework recomenda escopar cada servidor MCP ao conjunto mínimo de ferramentas necessárias e fornecer uma credencial dedicada com permissões reduzidas — não as credenciais do próprio desenvolvedor. Evite autoApprove: ["*"], que remove a aprovação humana em todas as chamadas de ferramentas. Consulte a documentação de configuração de MCP do Kiro para detalhes de implementação.

Varredura de código na IDE [D]

Análise estática em tempo real captura erros de sintaxe, incompatibilidades de tipo e problemas de configuração enquanto o desenvolvedor ainda tem contexto completo. Extensões focadas em segurança (plugins ESLint de segurança, Checkov, SAST) adicionam feedback imediato — uma política IAM malformada é sinalizada antes que o agente continue construindo sobre ela.

Hooks: guardrails automáticos no ponto de ação [D + ND]

Hooks de shell são disparados ao salvar arquivos e executam verificações determinísticas (linters, formatadores, scanners de segurança). Hooks baseados em IA são disparados ao completar tarefas e verificam se a implementação corresponde à especificação, se há casos extremos não testados e se arquivos foram modificados fora do escopo da tarefa.

Pilar 2: Controles no momento do build

Os controles de build rodam no pipeline após o commit do código e antes de chegar à produção.

Varredura de segurança em camadas [D]

A sequência recomendada é: detecção de segredos primeiro (mais barata, alta severidade), depois SAST, depois SCA e por fim varredura de Infraestrutura como Código (IaC). A varredura de IaC valida templates do AWS CloudFormation, Terraform e AWS CDK contra políticas de segurança antes do deploy. Cada etapa interrompe o pipeline em caso de falha. Os resultados são exportados no formato Formato de Intercâmbio de Resultados de Análise Estática (SARIF) para auditoria de conformidade. O projeto open source Automated Security Helper (ASH) agrupa scanners de segredos, SAST, SCA e IaC em um único comando executável localmente e no AWS CodeBuild.

Quality gates [D]

Gates de qualidade convertem resultados de varredura em decisões de prosseguir ou não. Defina limites por severidade: bloquear em achados críticos, exigir justificativa para altos, rastrear médios. A regra é determinística: se um limite é violado, o pipeline para. Diferencie modos bloqueante e consultivo — falhas duras na branch principal, consultivas em branches de feature.

Revisão assistida por IA [ND]

Um revisor LLM faz a triagem de cada pull request antes da revisão humana, verificando conformidade com a especificação, expansão de escopo e padrões de segurança que passam no SAST mas violam a intenção. O AWS Security Agent (revisão de código em preview no momento da publicação) verifica pull requests contra requisitos de segurança gerenciados pela AWS e personalizados. Um princípio crítico: o agente que escreveu o código não deve ser o mesmo que o revisa. Onde possível, use um modelo diferente para revisão — dois modelos iguais podem compartilhar os mesmos pontos cegos sistemáticos.

Revisão humana no loop [ND + H]

Exija aprovação humana na maioria dos pull requests, especialmente os que tocam código sensível a segurança ou de alto impacto. Escale a profundidade da revisão ao risco da mudança: mudanças de baixo risco podem ter revisão mais leve; mudanças de lógica nova ou sensível exigem revisão profunda e um segundo revisor. Posicione dois gates de aprovação: após as varreduras de segurança e antes do deploy em produção. Trate a revisão humana como controle secundário — revisores são não determinísticos e também podem deixar passar problemas.

Implementando na AWS

O framework é agnóstico de ferramenta, mas a AWS fornece blocos de construção diretos para cada pilar:

Kiro para controles de autoria: documentos de steering em .kiro/steering/, fluxos orientados por especificação, hooks de agente e integrações MCP. Todos os guardrails ficam versionados no repositório em .kiro/, compartilhados por todo o time. Para ambientes corporativos, o Kiro suporta AWS IAM Identity Center para login único. Verifique a disponibilidade atual por Região.
AWS CodeBuild e AWS CodePipeline para controles de build: cada ferramenta de varredura roda como uma ação de build; código de saída diferente de zero falha a ação; achados são exportados como SARIF para o Amazon S3; ações de aprovação manual interrompem o pipeline, enviam notificações via Amazon SNS e registram decisões e identidade do revisor para auditoria.

Por onde começar

A AWS sugere três passos iniciais:

Comece com steering e especificações — encode requisitos de segurança como steering e use especificações para novas funcionalidades. Maior impacto, menor esforço. O projeto open source Project CodeGuard (iniciativa da Coalition for Secure AI sob a OASIS Open, da qual a Amazon é membro contribuinte) publica regras de steering reutilizáveis para classes de risco comuns — credenciais hardcoded, misconfigurações de IaC, cadeia de suprimentos e segurança MCP.
Adicione gates determinísticos no pipeline — integre SAST, SCA e detecção de segredos. São controles básicos independentemente do uso de IA.
Calibre e itere — revise o que os controles estão capturando, ajuste o steering para problemas recorrentes e expanda a autonomia do agente conforme a confiança cresce.

Um ponto central do framework: desenvolvedores continuam responsáveis pela segurança do que entregam. Agentes de IA aceleram o desenvolvimento; eles não transferem a responsabilidade.

Recursos adicionais

Fonte

Balancing speed and safety: A control framework for AI coding agents (https://aws.amazon.com/blogs/security/balancing-speed-and-safety-a-control-framework-for-ai-coding-agents/)