No primeiro post desta série, falei sobre as principais novidades do Kiro CLI em 2026: Voice Mode, nova TUI, sessões persistentes, Rewind, subagents...
Mas como o Kiro CLI lida com segurança enquanto faz tudo isso? Porque uma coisa é um chatbot responder perguntas. Outra coisa é uma ferramenta que lê seus arquivos, executa comandos no seu terminal, acessa serviços AWS e toma decisões encadeadas.
Tool Trust: controle granular sobre o que o agente pode fazer
O coração da segurança do Kiro CLI é o sistema de Tool Trust, um mecanismo de permissões que controla quais ferramentas o agente pode usar e sob quais condições.
Toda ferramenta no Kiro CLI opera em um de três estados:
allowed — executa automaticamente, sem perguntar.
requires-approval — pede confirmação antes de executar.
denied — bloqueada, o agente não consegue usá-la.
Por padrão, toda ferramenta que pode modificar seu sistema exige aprovação. Isso inclui escrita de arquivos, execução de comandos shell, e chamadas AWS que não são read-only.
O controle é feito via configuração de agente:
allowedTools define quais ferramentas operam sem prompt.
toolsSettings permite restringir por caminhos, comandos e serviços.
Isso significa que você pode:
Liberar apenas ferramentas de leitura (read, grep, glob).
Restringir escrita a diretórios específicos.
Bloquear caminhos sensíveis (.env, secrets/).
Definir exatamente quais comandos shell são permitidos.
Negar tudo por padrão com denyByDefault: true.
Quando denyByDefault está ativo, comandos que não casam com allowedCommands são silenciosamente negados — nem aparece prompt.
Além da configuração permanente, você controla permissões em tempo real:
/tools trust write — confia na ferramenta de escrita nesta sessão.
/tools trust-all — confia em tudo (sessão apenas).
/tools reset — revoga tudo e volta ao padrão.
O /tools reset limpa todas as permissões acumuladas na sessão: ferramentas confiadas, comandos shell aprovados, e caminhos de leitura/escrita liberados.
O gate de confirmação: --trust-all-tools
Quando você inicia com --trust-all-tools, o Kiro não simplesmente libera tudo silenciosamente. Ele exibe um gate de confirmação explícito antes da sessão começar, exigindo que você aceite conscientemente.
Depois disso, um banner de aviso permanente fica visível durante toda a sessão:
“Trust All Tools active, confirmations are off”
Isso garante que você nunca esqueça que está operando em modo de confiança total.
Controle de Acesso por Diretório e Caminho
O sistema de permissões vai além de “pode ou não pode usar a ferramenta”. Ele opera no nível de caminhos:
allowedPaths — diretórios onde o agente pode ler/escrever sem perguntar.
deniedPaths — diretórios sempre bloqueados (tem precedência sobre allowedPaths).
Exemplo prático: o agente pode escrever em ./src/** mas nunca em ./.env ou ./secrets/**, mesmo se você confiar na ferramenta de escrita.
Para AWS, o mesmo princípio se aplica. Operações de leitura na AWS são auto-aprovadas por padrão (com base em 7.069 operações read-only catalogadas). Escrita exige confirmação a menos que o serviço esteja em allowedServices.
Controle de Acesso para Web
O Kiro também controla quais URLs o agente pode acessar:
trusted — regex de URLs auto-aprovadas.
blocked — regex de URLs sempre bloqueadas.
blocked tem precedência sobre trusted. Regex inválida em blocked nega tudo (fail-safe). Regex inválida em trusted é silenciosamente ignorada.
Isso permite criar agentes que podem consultar documentação oficial mas não acessar sites de paste ou repositórios externos.
Subagents: isolamento real
Quando o Kiro delega trabalho para subagents, o isolamento de segurança é real e documentado:
Subagents não herdam trust do agente pai — cada um usa seu próprio allowedTools.
Subagents não podem spawnar sub-subagents — previne recursão descontrolada.
Sessões de subagent terminam ao completar a tarefa — não ficam persistentes.
Cada subagent tem suas próprias conexões MCP isoladas — não compartilham estado.
Fail-fast: se um estágio falha, os outros são cancelados imediatamente.
Isso é design de menor privilégio aplicado a pipelines de agentes.
Session Management: rastreabilidade nativa
Toda sessão no Kiro CLI é automaticamente salva a cada turno. Não é opt-in, é o comportamento padrão.
O que é armazenado:
{session_id}.json — metadados (diretório, timestamps, estado).
{session_id}.jsonl — log append-only de toda a conversa.
{session_id}.lock — indica sessão ativa.
Cada sessão recebe um UUID único. O Kiro exporta a variável KIRO_SESSION_ID para todos os processos filho (comandos shell, hooks, MCP servers, chamadas AWS), permitindo correlacionar toda atividade com a sessão que a originou.
Sessões podem ser listadas, resumidas, exportadas para arquivo (portabilidade) e deletadas.
Rewind: reversibilidade como feature
O /rewind não é apenas um “desfazer”. Ele cria um fork da sessão em um ponto anterior, preservando o histórico original intacto.
Na prática:
Você seleciona um turno anterior no menu interativo.
Uma nova sessão é criada com o histórico até aquele ponto.
A sessão original permanece intocada.
Você continua de onde escolheu.
Isso é útil quando o agente tomou um caminho errado, você volta ao ponto de decisão e tenta outra abordagem sem perder nada.
Voice Mode: processamento local e integridade verificada
O Voice Mode do Kiro tem duas propriedades de segurança documentadas:
Processamento 100% local — o áudio é transcrito localmente via Whisper (whisper.cpp/whisper-rs). Nenhum áudio sai da sua máquina.
Verificação de integridade SHA-256 — o arquivo do modelo Whisper é verificado criptograficamente:
Após download: se o arquivo está corrompido ou foi alterado em trânsito, é descartado.
Antes de cada uso: se o arquivo foi modificado após download (por outro processo, por exemplo), é rejeitado.
Falha de verificação: o arquivo inválido é automaticamente deletado e baixado novamente do CDN oficial.
Proteção adicional: no Unix, o diretório do modelo é restrito a acesso owner-only (mode 0700).
Isso previne cenários onde um atacante substitui o modelo por uma versão maliciosa.
Shell: deny by default
O controle de shell merece destaque porque é onde mora o maior risco. O Kiro oferece:
allowedCommands — regex de comandos auto-aprovados.
deniedCommands — regex de comandos sempre bloqueados.
autoAllowReadonly — auto-aprova comandos somente-leitura (ls, cat, git status).
denyByDefault — nega tudo que não casa com allowedCommands.
Quando denyByDefault: true está configurado, o agente literalmente não consegue executar comandos que você não autorizou explicitamente. Comandos perigosos são silenciosamente negados sem sequer mostrar prompt.
Rejeição com feedback
Quando o agente tenta usar uma ferramenta e você rejeita, pode digitar o motivo. Esse feedback é enviado de volta ao agente para que ele ajuste o comportamento:
“User denied tool execution. Feedback: Don’t modify that file — it’s generated and will be overwritten”
O agente recebe esse contexto e adapta sua abordagem. Não é um “não” cego, é um “não, e aqui está o porquê”.
E se eu quiser que ele faça tudo sozinho?
Até agora falei de controles, aprovações, restrições. Mas e quando você quer que o agente opere com autonomia? Quando a tarefa é clara, o ambiente é controlado, e parar a cada ação só atrasa?
O Kiro CLI suporta isso, e te dá formas de fazer com graus diferentes de confiança.
Trust total na sessão
kiro-cli chat --trust-all-tools "Rode os testes e corrija os que falharem"
Exibe gate de confirmação antes de iniciar (você aceita conscientemente). Banner permanente lembra que confirmações estão desligadas. Aplica a toda a sessão, o agente pode usar qualquer ferramenta sem perguntar.
Quando usar: tarefas pontuais em ambiente isolado (branch de dev, container, sandbox).
Trust em ferramentas específicas
kiro-cli chat --trust-tools=read,write,shell,grep "Refatore o módulo auth"
Ou durante a sessão: /tools trust write shell
Libera apenas as ferramentas listadas. Outras continuam pedindo confirmação. Reseta ao fechar a sessão.
Quando usar: você sabe quais ferramentas a tarefa precisa, mas não quer liberar acesso AWS ou web.
Agente pré-configurado com autonomia
A forma mais segura de autonomia permanente é criar um agente dedicado com allowedTools, allowedPaths, deniedPaths e regras de shell definidas. O agente opera dentro dessas regras sempre, sem precisar de aprovação manual.
Quando usar: fluxo de desenvolvimento diário. Você define as regras uma vez e o agente opera dentro delas sempre.
Headless para automação (CI/CD)
kiro-cli chat --no-interactive --trust-all-tools "Analise o código e gere relatório de cobertura"
Sem interface interativa — roda e termina. Ideal para pipelines de CI/CD. Obrigatório usar --trust-all-tools ou --trust-tools em modo headless (senão trava esperando input que nunca vem).
O princípio
A autonomia no Kiro não é “tudo ou nada”. É um espectro configurável:
Desde o máximo controle (tudo pede confirmação) até a máxima autonomia (--trust-all-tools), passando por /tools trust na sessão, --trust-tools no startup, e agentes pré-configurados.
Você escolhe onde quer ficar nesse espectro, e pode mudar a qualquer momento. O ponto é que a decisão é sua, não do agente.
O que depende de você
O Kiro CLI te dá os mecanismos. Mas segurança não é automática, depende de configuração:
Configure deniedPaths para proteger .env, credenciais, configs de produção.
Use denyByDefault no shell para ambientes sensíveis.
Não use --trust-all-tools sem necessidade real.
Revise as ações antes de aprovar — sempre leia o que o agente vai fazer.
Crie agentes especializados com o mínimo de ferramentas necessárias.
Configure deniedServices na AWS para bloquear IAM, Organizations, etc.
A ferramenta implementa controle de acesso granular. Mas quem define as regras é você.
E agora?
No próximo artigo, vamos levar essa discussão para a realidade corporativa.
Abordaremos governança, gestão de mudanças, supply chain, distribuição, LGPD e como homologar essa tecnologia em escala.
Até lá!