AWS lança o kiro-secops, baseline de segurança para o agente Kiro

O Kiro, ambiente de desenvolvimento com IA da AWS disponível como IDE e como CLI, não é um assistente que só sugere código: ele lê e escreve arquivos no disco, executa comandos no terminal, acessa variáveis de ambiente e chama servidores MCP externos. Essa autonomia é o que torna a ferramenta produtiva, mas também abre uma superfície de risco nova na estação de trabalho de quem programa com agente. Um agente que roda terraform apply também roda terraform destroy. Um agente que lê seu código-fonte também lê seu .env.

Foi para fechar essa lacuna que a AWS publicou o kiro-secops, um sample descrito em post assinado por Felipe Gonzales e Ricardo Makino, arquitetos de soluções na AWS, no blog da AWS Brasil. O projeto empacota, num binário Go único, um baseline de segurança da informação e DevSecOps pronto para instalar no Kiro, sem depender de cada desenvolvedor configurar permissions.yaml e kiroignore na mão.

O problema que ninguém resolve só com prompt bem escrito

O post lista cinco problemas concretos que aparecem assim que um agente de IA ganha permissão para agir no ambiente de desenvolvimento. Nenhum deles se resolve com boa vontade:

• O agente herda todas as suas permissões, rodando com seu usuário: acesso a ~/.aws/credentials, chaves SSH em ~/.ssh, arquivos .env, tokens em .npmrc e estado do Terraform (.tfstate), que guarda segredos em texto claro.
• Sob pressão de prazo, a tendência é silenciar prompts de aprovação liberando tudo de uma vez, com uma regra allow ampla ou um perfil allow-all.
• Conteúdo externo (arquivos do repositório, busca na web, resposta de servidor MCP) é entrada não confiável, e controle que depende só da interpretação do modelo é frágil por definição.
• Configuração manual diverge entre máquinas do time, e não há como responder objetivamente se o guardrail está ligado numa máquina específica.
• A revisão de segurança tradicionalmente acontece depois que o código já está escrito, quando corrigir é caro.

O projeto ataca os cinco pontos com uma premissa chamada de declarative-first: o bloqueio duro vive em configuração avaliada nativamente pelo Kiro, sem depender de runtime, sistema operacional ou cooperação do modelo. Hooks automatizam verificações por evento; steering e skills orientam sem bloquear. Cada mecanismo é explícito sobre o que garante e o que não garante.

Como o modelo de camadas resolve o elo mais fraco

A solução se organiza em duas camadas de implantação. A camada global, em ~/.kiro/, é o padrão que segue a pessoa em todos os projetos: permissions.yaml, kiroignore, steering, a skill de revisão e o próprio binário em ~/.kiro/bin/. A camada de workspace, dentro de .kiro no repositório, traz hooks de evento, configuração de scanners (Trivy, Checkov, Gitleaks), .pre-commit-config.yaml e workflow de CI, e vai versionada junto com o código.

Quando mais de uma regra se aplica à mesma ação, vale sempre a mais restritiva: deny tem prioridade sobre ask, que tem prioridade sobre allow. Isso significa que um projeto nunca consegue afrouxar o que a camada global bloqueou. Quando nenhuma regra corresponde à ação, o padrão é ask: na ausência de decisão explícita, o Kiro pergunta em vez de liberar.

Para quem administra uma frota de máquinas, existe uma terceira garantia: as mesmas regras deny/ask podem ser replicadas no escopo de Administração do Kiro e distribuídas por MDM, com correção de drift. O baseline já traz um template pronto (admin.yaml) e um guia de adoção. É essa peça que transforma "confio que cada máquina está configurada" em política imposta pela organização, independente da lembrança de cada desenvolvedor.

O que fica travado e o que só pede confirmação

O permissions.yaml, avaliado nativamente pelo Kiro, nega leitura e escrita de um conjunto canônico de segredos: .env e variações, secrets/, .pem, .key, chaves SSH (id_rsa, id_ed25519, id_ecdsa*), credenciais, .p12, .pfx, estado do Terraform e tokens de publicação (.npmrc, .pypirc). Também nega categorias de shell perigosas: remoção recursiva, escalonamento de privilégio, chmod -R 777, pipe para interpretador, exfiltração de rede (curl, wget, nc, ssh, scp), git destrutivo e mecanismos de persistência como crontab e at.

Operações de alto impacto não são bloqueadas, mas recebem effect: ask e aguardam confirmação explícita: terraform apply, terraform destroy, kubectl delete, git push, aws s3 rm, escrita em Dockerfile, arquivos .tf e workflows de CI. A escolha é deliberada: bloquear tudo cria o incentivo perverso de alguém resolver com chmod 777 e --force, sem proteção nenhuma. Pedir confirmação nos pontos certos é mais robusto do que ser contornado em todos.

Um detalhe que protege contra repositório hostil: as permissões de workspace não ficam dentro do repositório clonado, e sim em ~/.kiro/workspace-roots/<hash>/permissions.yaml, por usuário. Um repositório malicioso não consegue injetar regra de permissão na sua máquina só por ser clonado.

Para ambientes mais fechados, existe o perfil strict, selecionável na instalação, que nega web_fetch, nega publicação em gerenciador de pacote e remove a lista ampla de comandos liberados, deixando o restante cair no ask padrão. Um teste automatizado garante que o strict seja sempre um superconjunto das restrições do baseline padrão.

O revisor que não pode consertar o que encontra

Bloqueio determinístico cobre categorias conhecidas de risco, mas não avalia se um controle de acesso está correto nem se uma concatenação de string virou SQL injection. É aí que entra o agente kiro-secops-reviewer: tem acesso de leitura e shell para rodar scanners, mas nega escrita e acesso à rede nas próprias permissões inline. Ele não pode alterar o código que revisa, o que evita o padrão de um mesmo agente apontar e consertar silenciosamente o próprio achado.

A skill kiro-secops-review estrutura o fluxo: triagem por OWASP Top 10 2025, mapeamento para CWE e OWASP ASVS nível 1, com material de referência por linguagem (Go, Java, Node.js, Python, Rust, shell) e template de threat model STRIDE. O resultado pode sair em formato SARIF, o que permite levá-lo direto para o code scanning do GitHub ou GitLab. Em CI, o mesmo agente roda em modo headless e somente leitura, produzindo revisão de pull request e triagem de relatórios DAST, com imagens de contêiner e pipelines de exemplo para GitHub Actions e GitLab CI.

Os hooks e o runtime guard fail-closed

O baseline instala seis hooks, divididos entre ações determinísticas de comando e ações assistidas por IA:

Os dois primeiros hooks chamam o runtime guard, que lê o contexto da chamada como JSON no stdin e decide de forma determinística: sai com código 0 para permitir e 2 para bloquear, devolvendo a mensagem de erro ao modelo pelo stderr. A propriedade central é ser fail-closed: JSON malformado, schema desconhecido ou payload acima de 1 MiB só podem resultar em bloqueio, nunca em liberação silenciosa. Em vez de casar só expressões regulares, o guard tokeniza o comando respeitando aspas, desembrulha invólucros como sudo, env e nice, e identifica recursão perigosa em rm, find e chmod.

Os autores do post destacam os dois hooks de spec-driven development como o melhor retorno sobre esforço do baseline inteiro:

Os dois hooks de SDD, na nossa experiência, têm o melhor retorno sobre esforço do baseline inteiro.

Felipe Gonzales e Ricardo Makino, Arquitetos de Soluções na AWS

Quando um requirements.md nasce em .kiro/specs/, o hook garante uma seção de requisitos de segurança escrita em formato EARS (WHEN ... THE SYSTEM SHALL ...), cobrindo validação de entrada, autenticação antes de autorização, segredos em cofre, criptografia em trânsito e em repouso, tratamento de erro sem vazamento de informação, log, auditoria e rate limiting. Quando nasce um design.md, o hook injeta a seção de threat model com fronteiras de confiança e análise STRIDE por componente. Segurança deixa de ser etapa de revisão e passa a ser parte do artefato de design desde o primeiro rascunho.

Instalação: três comandos e um cuidado que evita frustração

O binário é compilado localmente (o projeto não publica releases) com Go 1.25 ou superior e GNU Make, e roda em macOS, Linux e Windows, amd64/x86_64 e arm64, sem necessidade de sudo:

git clone https://github.com/aws-samples/sample-kiro-secops-baseline.git
cd sample-kiro-secops-baseline
make build
./kiro-secops version

Antes de escrever qualquer coisa no disco, dá para ver o plano com ./kiro-secops install --dry-run. A instalação de fato roda com ./kiro-secops install (ou --profile strict para a postura mais fechada), e o próprio instalador mostra a diferença entre + (arquivo criado) e ~ (merge estrutural no permissions.yaml e no kiroignore existentes, sem sobrescrever regra própria do desenvolvedor).

Um detalhe de uso que os autores destacam como a causa mais comum de "instalei e não bloqueou nada": a sessão do Kiro carrega a configuração só no início, então é preciso reiniciar a sessão depois de instalar para o guardrail entrar em vigor. Vale também adicionar o binário ao PATH (echo 'export PATH="$HOME/.kiro/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc) antes de seguir em frente.

Para quem programa com agente, o que muda na prática

Quem já usa Kiro, Claude Code, Cursor ou outro agente de código ganha aqui um modelo de referência replicável mesmo fora do Kiro: separar bloqueio determinístico (independente do modelo) de orientação assistida por IA (que pode falhar) é a diferença entre confiar que o agente "vai se comportar" e garantir, por configuração avaliada fora do modelo, que ele não vai ler seu .env nem rodar terraform destroy sem confirmação.

Vale checar, antes de instalar qualquer coisa em produção, se o perfil padrão ou o strict cobre os segredos específicos do seu stack (o conjunto canônico do post não menciona, por exemplo, arquivos de configuração de banco gerenciado fora do padrão .env), e revisar o admin.yaml se a decisão for distribuir a política por MDM em toda a equipe. O código-fonte completo, com os templates de steering, os scanners e os exemplos de pipeline, está no repositório aws-samples/sample-kiro-secops-baseline no GitHub.

Fonte: AWS Brasil — Blog