Configurar o Kiro em modo Autopilot não significa liberar automaticamente toda ação do agente. O Autopilot permite que ele continue o trabalho sem pedir revisão a cada etapa do plano; as permissões determinam o que ele pode executar em arquivos, terminal, web e integrações. Para trabalhar com autonomia de forma segura, é preciso configurar as duas camadas.
Resumo técnico
O Autopilot controla o fluxo da tarefa. O arquivo permissions.yaml controla as operações. A combinação recomendada é: permitir atividades locais de rotina, exigir confirmação para mudanças compartilhadas e bloquear de forma explícita segredos e comandos irreversíveis.
Por que o Kiro ainda pede aprovação?
Quando aparece a mensagem “Your approval is required to continue”, com as opções Allow, Always allow, Deny e Always deny, o Autopilot pode estar ativo corretamente. A solicitação vem da política de permissões: aquela ação de terminal, arquivo ou ferramenta corresponde a uma regra com efeito ask ou deny.
As duas camadas de controle
- Autopilot: é selecionado no rodapé do chat e permite que o agente avance pelo plano sem parar para pedir aprovação de cada etapa lógica.
- Permissions: são regras que classificam cada operação por capability, effect e match. Elas decidem se a operação será executada, pedirá confirmação ou será bloqueada.
As capabilities mais relevantes são fs_read para leitura de arquivos, fs_write para escrita, shell para comandos de terminal, web_search e web_fetch para pesquisa e acesso web, e mcp para ferramentas conectadas por servidores MCP.
Onde configurar as permissões
- Escopo do usuário: ~/.kiro/settings/permissions.yaml. Vale para todos os projetos da máquina.
- Escopo do projeto: .kiro/settings/permissions.yaml dentro do workspace. Vale apenas para aquele repositório.
- Escopo organizacional: políticas corporativas aplicadas pela organização. Elas prevalecem sobre a configuração local.
Na prática, use o escopo de projeto quando quiser limites próprios para laboratório, desenvolvimento, homologação, projetos de clientes ou produção. Ao versionar o arquivo no repositório, a equipe trabalha com a mesma política de autonomia.
Como ler uma regra no permissions.yaml
- Capability: identifica a classe da operação, como shell ou fs_write.
- Effect: define a decisão. Allow executa sem modal; ask interrompe para confirmação; deny bloqueia a operação.
- Match: limita a regra a padrões de caminho ou de comando. É usado para proteger arquivos específicos e para diferenciar comandos comuns de operações críticas.
Passo a passo para configurar o modo autônomo
- No rodapé da conversa, selecione Autopilot. Esse é o primeiro requisito para que o Kiro siga o plano de execução.
- Abra a paleta de comandos com Ctrl + Shift + P e procure por Permissions. Se preferir, abra diretamente o arquivo de permissões do usuário ou do projeto.
- Crie primeiro as regras deny para dados sensíveis e comandos destrutivos. Isso estabelece o limite que não poderá ser ultrapassado por uma permissão ampla.
- Inclua regras ask para publicação, deploy, mudanças em infraestrutura e qualquer ação que altere estado compartilhado.
- Inclua regras allow para leitura, escrita, shell local, pesquisa e acesso web usados no trabalho cotidiano.
- Salve o arquivo YAML. As regras passam a valer nas próximas ações; não é necessário reiniciar o Kiro.
- Peça ao agente para executar git status. Se a regra shell estiver liberada e não houver match restritivo, o comando deve executar sem aprovação.
Há também um atalho operacional: ao receber uma caixa de aprovação, a opção Always allow cria uma regra para comandos semelhantes. Isso é útil para construir uma allowlist incremental, desde que a equipe revise periodicamente o que foi liberado.
Opção A: autonomia total para ambientes descartáveis
Uma política com effect allow para todas as capabilities elimina praticamente todas as perguntas. Ela pode ser útil em sandboxes, demos e repositórios temporários. Não é indicada para máquinas com credenciais, código de clientes ou conexão com produção, pois o agente poderá executar operações sensíveis sem qualquer ponto de parada.
Opção B: autonomia com piso de segurança
Para times de engenharia, a abordagem recomendada é separar as regras em três grupos: deny para proibições permanentes, ask para decisões humanas e allow para rotina. A seguir está a política do PDF transformada em especificação de configuração, sem usar blocos de código no artigo.
1. Bloqueie o acesso a segredos
Crie uma regra com capability filesystem e effect deny. Nos matches, inclua os padrões **/.env, **/.env.*, **/*.pem, **/*.key, **/id_rsa*, **/.ssh/**, **/.aws/credentials e **/*.tfstate. Essa regra evita leitura ou alteração de variáveis de ambiente, chaves privadas, diretórios SSH, credenciais de cloud e estados de infraestrutura.
2. Bloqueie comandos de alto impacto
Crie uma regra com capability shell e effect deny. Os matches devem cobrir rm -rf /*, rm -rf ~*, sudo *, chmod 777*, mkfs*, dd * of=/dev/*, shutdown*, reboot*, git push –force*, git push -f* e comandos que usem –no-verify. O objetivo é impedir exclusão ampla, alteração de permissões insegura, formatação de disco, reinicialização, envio forçado ao repositório e bypass de validações.
3. Exija confirmação para ações externas ou compartilhadas
Crie uma regra com capability shell e effect ask. Inclua git push*, npm publish*, docker push*, gh pr merge*, terraform apply*, terraform destroy*, aws * delete-*, aws * terminate-* e aws iam *. Essas ações não são bloqueadas: elas param no momento certo para que uma pessoa confirme o impacto antes da execução.
4. Libere a rotina local
- Crie uma regra fs_read com effect allow para leitura de arquivos.
- Crie uma regra fs_write com effect allow para edição de arquivos do projeto.
- Crie uma regra shell com effect allow para testes, build, instalação de dependências, análise de logs e comandos locais.
- Crie regras web_search e web_fetch com effect allow quando a pesquisa e o acesso web fizerem parte do fluxo autorizado.
Com essa divisão, o Kiro consegue criar e editar arquivos, executar testes, analisar logs, instalar dependências e avançar na implementação sem interrupção. A confirmação fica concentrada em publicação, deploy, infraestrutura, credenciais e mudanças com efeito fora da máquina.
Precedência: por que uma regra allow pode não funcionar
A ordem de decisão é deny, depois ask e por fim allow. A regra mais restritiva vence. Portanto, uma regra ampla que libera shell não desbloqueia um comando que também corresponda a um deny específico. Da mesma forma, uma política organizacional pode se sobrepor ao arquivo local do projeto.
O que deve continuar exigindo confirmação
- Mudanças compartilhadas: git push, publicação de pacotes, envio de imagens Docker e merge de pull requests.
- Infraestrutura: terraform apply, terraform destroy, exclusão ou término de recursos em cloud e mudanças de identidade e acesso.
- Dados sensíveis: variáveis de ambiente, chaves, credenciais e arquivos de estado.
- Transferência de dados: comandos que enviam informação para fora do ambiente devem ser avaliados de acordo com a política da empresa.
Compatibilidade com configurações anteriores
Algumas versões antigas usam kiroAgent.trustedCommands e kiroAgent.commandDenylist no arquivo settings.json. O modelo atual, baseado em capabilities no permissions.yaml, permite uma política mais granular por tipo de operação e por padrão de comando. Em versões recentes, ele deve ser o padrão adotado.
Diagnóstico rápido
- Autopilot está ligado, mas um comando pede aprovação: verifique se shell está em ask ou se o comando coincide com um match específico.
- Uma alteração no YAML não teve efeito: valide a indentação de dois espaços e confirme se o arquivo foi salvo no escopo correto.
- Uma regra allow não libera uma ação: procure por deny, ask ou uma política organizacional mais restritiva.
- O Kiro para sempre no mesmo comando: use o padrão do comando para localizar a regra correspondente e decida se ele deve ser allow, ask ou deny.
Boas práticas de operação
- Aplique autonomia por ambiente, e não como uma regra global para todas as máquinas e projetos.
- Comece com uma allowlist incremental e revise as permissões liberadas pelo uso de Always allow.
- Mantenha deny explícito para segredos, mesmo quando a política geral permite leitura e escrita.
- Use .kiroignore para retirar arquivos e pastas sensíveis do contexto do agente.
- Versione permissions.yaml junto com o repositório e trate a política como parte da governança de engenharia.
- Use checkpoints, revisão de mudanças e recursos de revert ou rewind antes de concluir tarefas de maior impacto.
Conclusão
O Autopilot sozinho não define autonomia operacional. A autonomia real vem da política de permissions: permitir o trabalho local, pedir aprovação para mudanças compartilhadas e negar permanentemente o que ameaça dados, infraestrutura ou continuidade do ambiente. Esse modelo reduz atrito no desenvolvimento sem abrir mão de controle.
