Governança de IA no código: permissões, arquivos fora do alcance, revisão humana e trilha de auditoria com o Kiro

Governar IA no código é decidir o que o agente pode ler, executar e alterar, quem revisa o que ele produz e onde fica a evidência do que aconteceu. No Kiro, a IA agêntica da AWS para desenvolvimento de software, essa governança se resolve em camadas: permissões declarativas, arquivos fora do alcance do agente, hooks de verificação, controles da organização e revisão humana no pipeline, com trilha de auditoria ligando tudo.

Verificado contra a documentação de permissões, governança e proteção de dados do Kiro na atualização de 15/10/2026. Os controles administrativos mudam entre versões: confira a página de cada um antes de distribuir a configuração.

Nenhuma camada resolve sozinha, e a documentação oficial do Kiro é explícita sobre onde cada uma termina: controles aplicados no cliente, superfícies em que um recurso não existe, configurações que o próprio usuário consegue desligar. O método está em conhecer esses limites e posicionar cada controle onde ele é mais forte. Se o Kiro é novidade para o seu time, o panorama do Kiro explica as superfícies (IDE, CLI, Web) e o modelo de adoção.

Do Shadow AI à IA governada no desenvolvimento

O Shadow AI no time de engenharia tem uma forma específica: um agente com acesso ao repositório, ao terminal e às credenciais de quem o executa, usado sem política. Os riscos são concretos e cada um tem um controle correspondente nas camadas a seguir:

• Segredo no contexto. Sem configuração, o Kiro lê arquivos dentro do workspace sem pedir confirmação, segundo a documentação de permissões. Um .env, uma chave privada ou um estado do Terraform entram no contexto da conversa.
• Comando destrutivo. O agente que tem permissão para aplicar uma mudança de infraestrutura também consegue destruí-la. Por isso o baseline publicado pela AWS Brasil coloca terraform apply, terraform destroy, kubectl delete e git push em confirmação (ask).
• Dependência maliciosa. O agente resolve um problema instalando um pacote. Nome parecido com o de um pacote legítimo, versão sem fixação ou script de instalação passam despercebidos num diff grande.
• Servidor MCP não confiável. Um servidor MCP local roda na máquina do desenvolvedor, com as credenciais configuradas para ele, e a resposta das ferramentas volta para o agente como entrada não confiável. Tratei do desenho seguro no post sobre MCP no Kiro.
• Código sem revisão. O volume de alteração cresce mais rápido que a capacidade de revisar, e o "parece certo" substitui o "foi verificado".
• Conta pessoal. Pela página de proteção de dados, o conteúdo de usuários do Free Tier e de assinantes individuais (login com AWS Builder ID ou login social) pode ser usado para melhoria do serviço, inclusive treinamento de modelo, com opção de desativar. O conteúdo de usuários enterprise não é usado para isso. Um desenvolvedor no plano pessoal com o código da empresa é Shadow AI, mesmo usando a ferramenta aprovada.

Camada 1: permissões

O permissions.yaml é a política declarativa do agente, avaliada pelo próprio Kiro antes de cada ação. A documentação de permissões organiza as regras em seis escopos:

Não existe precedência entre escopos. A resolução é por efeito: deny > ask > allow, e o mais restritivo vence, venha de onde vier. Um deny em qualquer escopo bloqueia a ação e nenhum allow o anula. Isso torna o modelo previsível para quem governa: a organização não precisa "ganhar" do usuário: o deny dela prevalece.

As regras se aplicam por capacidade: fs_read, fs_write, shell, web_fetch, web_search, mcp, subagent, skill, power, context, diagnostics e sandbox_network, além das metacapacidades all, builtin e filesystem. Em shell, o padrão é um prefixo de comando com *, e o campo exclude recorta exceções. O exemplo da documentação libera o npm e mantém a publicação de pacote fora da liberação:

rules:
  - capability: shell
    effect: allow
    match:
      - "npm *"
    exclude:
      - "npm publish*"

Seis comportamentos documentados definem o desenho:

• Comandos compostos são avaliados por partes. Comandos ligados por ;, &&, || ou | são separados e cada subcomando passa pelas regras. Uma regra para npm test * não libera npm test ; curl .... Opções que lançam outro programa, como tar --to-command, sempre pedem aprovação.
• O padrão sem configuração é permissivo na leitura. O agente lê arquivos dentro do workspace, roda comandos git de leitura e comandos de informação do sistema sem perguntar; todo o resto pede aprovação. Um permissions.yaml soma regras a esse padrão, sem substituí-lo, por isso a negação de leitura de segredos precisa ser explícita.
• A permissão do workspace fica fora do repositório. O arquivo mora em ~/.kiro/workspace-roots/<hash>/, e a documentação é direta: um repositório clonado não injeta regras de permissão. Regra que precisa valer para o time inteiro vai no perfil do agente, versionado e revisado, ou no escopo de administração.
• Caminhos protegidos. Escrita em .git/**, .kiroignore e nos diretórios agents, hooks, workflows e powers sempre pede confirmação, e nenhum allow remove essa pergunta. Escrita em .kiro/settings/ e ~/.kiro/workspace-roots/ é sempre negada. O agente não altera os próprios controles sem uma pessoa confirmar.
• Workspace não confiável. Até a pessoa confiar no workspace, o Kiro não carrega agentes, steering, configuração MCP, skills nem workflows dele, e pergunta antes de cada comando de shell, cada chamada MCP e cada ativação de Power. As regras deny continuam valendo.
• Sem cliente interativo, ask vira deny. Em execução headless, não existe canal para a pergunta, então todo ask é tratado como negação. Uma sessão headless só executa o que foi liberado explicitamente.

Duas observações de superfície. Na IDE, a configuração Agent Autonomy (Autopilot ou Supervised) é aplicada antes das regras: em Supervised, o agente pergunta antes de qualquer ação. No Kiro Web, permissions.yaml e aprovações interativas não se aplicam, porque o agente roda num sandbox gerenciado na nuvem.

O escopo de agente é o lugar certo para papéis com raio de ação reduzido. Um revisor de segurança que lê o código e roda scanners, mas não escreve nem busca na web, fica assim, no formato do guia de configuração de agentes:

{
  "name": "revisor-seguranca",
  "description": "Revisor somente leitura: lê o código e roda scanners, sem escrita e sem web",
  "prompt": "Revise o diff da branch atual contra main. Aponte segredos, injeção, permissões amplas em IaC e dependências novas. Não proponha edição: descreva o achado, o arquivo e a linha.",
  "tools": ["read", "shell"],
  "permissions": {
    "rules": [
      { "capability": "fs_read", "effect": "allow" },
      { "capability": "shell", "match": ["git diff *", "gitleaks *", "semgrep *", "checkov *"], "effect": "allow" },
      { "capability": "fs_write", "effect": "deny" },
      { "capability": "web_fetch", "effect": "deny" },
      { "capability": "web_search", "effect": "deny" },
      { "capability": "mcp", "effect": "deny" }
    ]
  }
}

Um detalhe de método: a regra de fs_write governa a ferramenta de escrita do agente. Um comando de shell liberado roda com as permissões do usuário e faz o que o próprio comando sabe fazer. Por isso a lista de shell do revisor contém só os comandos de que ele precisa, e nenhum interpretador genérico.

Camada 2: o que o agente não lê

O .kiroignore impede o Kiro de ler arquivos do workspace, com sintaxe no estilo do .gitignore. Onde o recurso é suportado, o arquivo bloqueado continua bloqueado qualquer que seja a ferramenta de leitura, e resultados de busca que apontem para ele são filtrados, inclusive caminho e conteúdo. Ele aceita um arquivo na raiz e em subdiretórios, além de um arquivo global em ~/.kiro/settings/kiroignore.

# Credenciais e configuração local
.env
.env.*
!.env.example
.npmrc
credentials/

# Chaves e certificados
*.pem
*.key
*.p12

# Estado de infraestrutura (contém saídas e, às vezes, segredos)
*.tfstate
*.tfstate.backup

# Dados de cliente e extrações
customer-data/
pii/
data/exports/
*.sql
*.dump

Os limites declarados na própria página definem como usar o recurso:

• Cobertura por superfície. O .kiroignore do workspace funciona na IDE e no CLI V3; o arquivo global, só na IDE. Web e Mobile não são suportados.
• Sem reinclusão sob pasta excluída. Ignorar secrets/ torna !secrets/public.txt ineficaz. Use padrões mais específicos.
• O usuário controla a leitura do arquivo. Na IDE, a configuração kiroAgent.agentIgnoreFiles define quais arquivos de ignore valem, e o valor [] desliga os arquivos de ignore do workspace.
• Não é apresentado como fronteira de segurança. A documentação lista segurança como motivação, sem garantia de aplicação, e sugere testar pedindo ao Kiro que leia um arquivo ignorado.

A conclusão prática: o .kiroignore tira o ruído e o grosso do risco do contexto, e a negação que precisa resistir a uma configuração local vai em regra deny de fs_read, no escopo de administração. Mantenha os dois alinhados, com a mesma lista de padrões.

Camada 3: hooks de verificação

Permissão responde "pode ou não pode" por padrão de texto. Hook responde com lógica: lê a entrada da ferramenta, decide e explica. No gatilho Pre Tool Use, um hook de comando que sai com código 2 bloqueia a execução, e o STDERR volta para o modelo como explicação, conforme a referência de códigos de saída. Qualquer outro código diferente de zero é falha do hook, mostrada como aviso, e não bloqueio.

Um controle de governança que permissão por prefixo não expressa bem: dependência nova passa por revisão humana. O hook abaixo bloqueia a instalação de pacote nomeado e orienta o agente a registrar a dependência na spec.

{
  "version": "v1",
  "hooks": [
    {
      "name": "guard-dependencias",
      "description": "Dependência nova passa pela spec e por revisão humana",
      "trigger": "PreToolUse",
      "matcher": "shell",
      "action": { "type": "command", "command": "bash tools/kiro-hooks/guard-dependencias.sh" },
      "timeout": 10
    }
  ]
}

#!/usr/bin/env bash
# PreToolUse em shell. exit 0 libera; exit 2 bloqueia e o STDERR vai ao agente.
set -u
payload="$(cat)"

# Fail-closed: sem jq não há leitura segura do payload.
command -v jq >/dev/null 2>&1 || { echo "guard-dependencias: jq ausente; bloqueando." >&2; exit 2; }
cmd="$(printf '%s' "$payload" | jq -r '.tool_input.command // empty')"

# Instalação com pacote nomeado (flags antes do nome são aceitas).
# "npm install" e "npm ci" sem nome instalam do lockfile e passam.
padrao='(npm|pnpm|yarn)[[:space:]]+(install|i|add)([[:space:]]+-[^[:space:]]+)*[[:space:]]+[^-[:space:]]'
padrao+='|pip3?[[:space:]]+install[[:space:]]+[^-[:space:]]'
padrao+='|go[[:space:]]+get[[:space:]]'

if printf '%s' "$cmd" | grep -Eq -- "$padrao"; then
  echo "guard-dependencias: dependência nova exige revisão humana." >&2
  echo "Registre pacote, versão fixa e motivo no design.md da spec e aguarde aprovação." >&2
  exit 2
fi
exit 0

echo '{"tool_input":{"command":"npm i -D pacote-exemplo"}}' \
  | bash tools/kiro-hooks/guard-dependencias.sh; echo "rc=$?"   # esperado: rc=2

echo '{"tool_input":{"command":"npm ci"}}' \
  | bash tools/kiro-hooks/guard-dependencias.sh; echo "rc=$?"   # esperado: rc=0

O campo tool_input.command é o mesmo usado nos testes do baseline da AWS Brasil para guards de shell; confirme com um payload capturado na sua versão do Kiro, como mostrei no post sobre hooks no Kiro. Lá também está o par que fecha o turno: um hook de comando no gatilho Stop com o campo confirm, que pergunta antes de rodar um checklist de revisão sobre o diff, e um confirmCommand que pula a pergunta quando não há alteração.

Três limites a respeitar. Hooks rodam na IDE e no CLI, não no Web. Uma lista de padrões não é sandbox: o próprio baseline da AWS Brasil registra que ela pode ser contornada, por exemplo, embrulhando o comando num interpretador. E hook do repositório é código executado na máquina de quem abre o projeto: o Kiro sempre pede confirmação para o agente escrever no diretório de hooks, e o diretório precisa de dono no CODEOWNERS.

Camada 4: governança da organização

As camadas anteriores dependem da configuração de cada máquina. No plano Enterprise, o administrador define políticas no console do Kiro, em Settings > Shared settings, descritas na documentação de governança:

• Modelos aprovados e modelo padrão. Por padrão, o usuário acessa qualquer modelo suportado. Com o controle de modelos ligado, o administrador escolhe a lista aprovada e um modelo padrão aplicado a todos os clientes. A documentação orienta conferir o escopo de inferência e a localização do endpoint de cada modelo contra os requisitos de residência de dados. Modelo novo lançado pelo Kiro só fica disponível depois de entrar na lista, e modelo removido continua disponível até a sessão reiniciar.
• MCP desligado ou com registry. O controle de MCP desliga todos os servidores ou publica uma lista aprovada por HTTPS. O Kiro busca o registry na inicialização e a cada 24 horas, encerra servidor que saiu da lista e, se não alcança a API de governança, desliga o MCP. A política vale para usuários com IAM Identity Center ou chave de API; usuários com Builder ID ou login social ficam fora dela.
• Chaves de API desligadas por padrão. As chaves de API servem para automação com o Kiro CLI, local ou em pipeline de CI/CD, e só podem ser geradas se o administrador habilitar.
• web_search e web_fetch desligáveis. As ferramentas web vêm ligadas por padrão e podem ser desligadas para a conta ou a organização inteira.
• Controles de login. Os controles de login limitam os métodos oferecidos na tela de entrada e preenchem a URL e a região do IAM Identity Center. Ficam no managed-settings.json, a partir da IDE 1.2 e do CLI 2.25.0.

O mesmo managed-settings.json carrega as políticas de permissão da organização, que só aceitam deny e ask. No macOS, o arquivo fica em /Library/Application Support/Kiro/managed-settings.json; nos demais sistemas, no caminho protegido indicado pela documentação para cada plataforma. Um arquivo que combina login corporativo obrigatório, segredos fora de leitura e confirmação em operações de risco:

{
  "rules": [
    { "capability": "signin_method", "match": ["*"], "exclude": ["idc"], "effect": "deny" },
    {
      "capability": "fs_read",
      "match": ["**/.env", "**/.env.*", "**/*.pem", "**/*.key", "**/*.tfstate", "~/.aws/**", "~/.ssh/**"],
      "exclude": ["**/.env.example"],
      "effect": "deny"
    },
    { "capability": "shell", "match": ["sudo *"], "effect": "deny" },
    {
      "capability": "shell",
      "match": ["terraform apply*", "terraform destroy*", "kubectl delete*", "git push*"],
      "effect": "ask"
    }
  ],
  "settings": {
    "idc_start_url": "https://minha-organizacao.awsapps.com/start",
    "idc_region": "us-east-1"
  }
}

A primeira regra fecha a lacuna do Builder ID: só o login da organização aparece na tela, e com ele valem as políticas de MCP e a regra de que o conteúdo não é usado para melhoria do serviço. O idc_region é a região da sua instância do IAM Identity Center.

Agora o limite, que a documentação declara em cada página. Políticas de permissão, controle de MCP e controle de ferramentas web são aplicados no cliente e podem ser contornados por quem tem acesso administrativo à máquina. Os controles de login valem só onde o arquivo foi distribuído, falham aberto se o arquivo for inválido e não restringem o Kiro Web. As configurações compartilhadas, como MCP, modelos e chaves gerenciadas pelo cliente, também não se aplicam a sessões do Kiro Web; as sessões na nuvem vêm desligadas por padrão em organizações com IAM Identity Center e só funcionam se o administrador as ligar. Na prática, governança da organização pede três coisas juntas: gestão de dispositivos (MDM) para distribuir e proteger o arquivo, a documentação cita Jamf e Kandji como exemplos; o provedor de identidade decidindo quem usa o Kiro; e controles que não dependem da estação de trabalho, que são as próximas camadas.

Camada 5: revisão humana e pipeline

A estação de trabalho é o lugar da produtividade; o pipeline é o lugar da garantia. Quatro controles transformam a revisão humana em processo:

1. Spec revisada antes do código. Requisitos, design e tarefas aprovados por uma pessoa antes da implementação, como descrevi no post sobre specs no Kiro. É o momento mais barato para barrar uma dependência, uma permissão ampla ou um dado pessoal sem necessidade.
2. Pull request com dono. O CODEOWNERS com revisão obrigatória na proteção de branch garante que a configuração do agente e os controles tenham revisores definidos.
3. Varredura de segredos, SAST e IaC no CI. Gitleaks para segredos, Semgrep para código e Checkov ou Trivy para infraestrutura como código, todos bloqueantes na branch principal.
4. Caminho único para produção. Mudança de infraestrutura entra por IaC e pela esteira de CI/CD com aprovação, e a estação de trabalho fica com credenciais de leitura.

# Configuração do agente e controles: plataforma e segurança revisam
/.kiro/              @minha-org/plataforma @minha-org/appsec
/.kiroignore         @minha-org/appsec
/tools/kiro-hooks/   @minha-org/plataforma @minha-org/appsec

# Caminho para produção
/.github/workflows/  @minha-org/plataforma
/infra/              @minha-org/plataforma

A referência mais completa para essa camada é o Baseline de Segurança DevSecOps para o Kiro, publicado no blog da AWS Brasil em 15/09/2026 por Felipe Gonzales e Ricardo Makino, Arquitetos de Soluções na AWS. O sample, sob licença MIT-0, organiza os controles em duas camadas: uma global, em ~/.kiro/, instalada uma vez por máquina, com permissions.yaml, kiroignore, steering de codificação segura e um agente revisor; e uma de workspace, versionada no repositório, com hooks, configuração de scanners e workflow de CI. Os hooks incluem guards de bloqueio em PreToolUse para shell e para escrita e uma revisão no fim do turno. O steering cobre OWASP Top 10 2025 e OWASP API Security Top 10 e entra na tabela de mecanismos do sample como advisory: orienta a geração de código, e o bloqueio fica com os guards e as permissões. É o mesmo papel que defendo no post sobre steering no Kiro. O revisor tem leitura e shell para rodar scanners, e as permissões inline do agente negam escrita e acesso à rede; o resultado sai em SARIF para o code scanning do repositório.

As limitações que os autores declaram são o melhor argumento para esta quinta camada: a camada global é padrão comum, editável pelo usuário, e o pre-commit pode ser contornado com --no-verify. O controle que ninguém desliga na própria máquina está no servidor: proteção de branch, revisão obrigatória e varredura bloqueante.

Trilha de auditoria

Quando alguém perguntar "quem mudou isso, com qual ferramenta, e quem aprovou?", a resposta vem de três fontes complementares:

Os dois recursos do Kiro estão na seção de monitoramento do plano Enterprise. O relatório de atividade é gravado diariamente às 02:00 UTC num bucket na região do perfil do Kiro, na conta em que os usuários estão assinados. O registro de prompts é ligado em Kiro Settings > Logging, com política de bucket que libera s3:PutObject ao principal de serviço indicado na documentação, e aceita chave do AWS KMS opcional. A documentação recomenda buckets separados para os dois.

O AWS CloudTrail fecha a trilha do lado da conta AWS. A página de monitoramento do Kiro o cita sem listar os eventos específicos do serviço; confirme quais aparecem no histórico de eventos da sua conta antes de escrever a regra de detecção. Para as ações que o agente executa na AWS por MCP ou pela AWS CLI, o CloudTrail registra a credencial usada. Um perfil dedicado com role_session_name próprio separa, na trilha, o que o agente fez do que a pessoa fez no terminal: segundo a documentação da AWS CLI, o nome da sessão passa a fazer parte do ARN da sessão da role e aparece nos registros do CloudTrail de cada operação.

# Perfil usado só pelo agente (MCP ou AWS CLI), com role de leitura
[profile kiro-agente-leitura]
role_arn = arn:aws:iam::111122223333:role/kiro-agente-leitura
source_profile = dev-sso
role_session_name = kiro-agente-jsilva

LGPD no registro de prompts

O registro de prompts grava o ID do usuário, o horário e o texto da conversa: é dado pessoal do colaborador. E pode conter dado pessoal de cliente, se alguém colar um registro no chat ou se a sugestão inline capturar código com dado real. Antes de ligar, o mínimo pela LGPD:

• Finalidade definida (art. 6º, I): auditoria de segurança e investigação de incidente, escrita na política, sem uso para avaliação de desempenho individual que não esteja declarado.
• Transparência (art. 6º, VI): os colaboradores sabem que o registro existe, o que ele contém e quem acessa.
• Necessidade (art. 6º, III): dado de cliente proibido no contexto do agente, reforçado pelo .kiroignore e pelas regras de leitura.
• Retenção e eliminação (arts. 15 e 16): prazo definido e aplicado por S3 Lifecycle, acesso restrito ao bucket e criptografia com KMS.
• Registro das operações (art. 37): o tratamento entra no inventário de dados da empresa.

Há também a questão de localização. A página de proteção de dados do Kiro lista regiões de inferência nos Estados Unidos e na Europa, nenhuma no Brasil, informa que alguns modelos usam inferência global em regiões comerciais do mundo todo e que o conteúdo enterprise pode ser armazenado na região do perfil. Trate o uso como transferência internacional (art. 33) e valide o enquadramento com o encarregado, à luz das orientações da ANPD. O desenho de LGPD na nuvem como um todo está no post sobre LGPD na cloud.

Política de uso de IA no desenvolvimento em uma página

Os controles técnicos executam uma política, e a política cabe numa página. O modelo que uso como ponto de partida tem oito itens:

1. Ferramentas aprovadas. Quais agentes e superfícies são permitidos, com login corporativo obrigatório. Conta pessoal com código da empresa é proibida.
2. Dado proibido no contexto. Credenciais, chaves, estado de infraestrutura e dado pessoal de cliente, com a lista espelhada no .kiroignore e nas regras de leitura.
3. Revisão obrigatória. Spec aprovada antes do código, pull request com revisão humana e CODEOWNERS na configuração do agente.
4. MCP aprovado. Só servidores do registry, com permissão mínima e credencial de leitura em produção.
5. Chaves de API. Quem pode gerar, para qual automação, com qual permissão e como são revogadas.
6. Registro. O que é registrado (atividade, prompts, CloudTrail), finalidade, quem acessa e por quanto tempo fica.
7. Incidentes. Segredo exposto ao agente, comando indevido ou dado pessoal no contexto: a quem comunicar, como rotacionar e como registrar.
8. Revisão da política. Dono nomeado e revisão periódica, porque recursos e limites do Kiro mudam a cada versão.

Checklist de governança

• Login restrito ao IAM Identity Center pelo managed-settings.json, distribuído por MDM.
• Regras deny de fs_read para segredos no escopo de administração, espelhadas no .kiroignore.
• Regras ask para terraform apply, kubectl delete e git push; deny para escalonamento de privilégio.
• Lista de modelos aprovados e modelo padrão definidos, com conferência de escopo de inferência.
• MCP desligado ou restrito a registry com versões fixadas.
• Ferramentas web avaliadas e desligadas onde não forem necessárias.
• Chaves de API desligadas, ou ligadas só para automações nomeadas.
• Agentes por função no repositório, com o revisor somente leitura.
• Hooks de bloqueio fail-closed, testados com payload e com dono no CODEOWNERS.
• Proteção de branch com revisão obrigatória e varredura de segredos, SAST e IaC bloqueantes.
• Relatório de atividade e registro de prompts em buckets separados, com KMS, acesso restrito e retenção.
• Perfil AWS dedicado ao agente, com permissão mínima e role_session_name identificável no CloudTrail.
• Política de uma página publicada, comunicada ao time e com data de revisão.

Com essas camadas no lugar, a pergunta deixa de ser "liberamos ou não a IA no código?" e passa a ser "quanto de autonomia cada papel recebe, com qual evidência". É uma decisão que se ajusta por etapa, como discuti no post sobre IA agêntica no desenvolvimento, e que se apoia nos mesmos princípios de segurança em cloud aplicados a qualquer conta AWS.

Para levar essas camadas ao seu time, com permissões, hooks, registry de MCP e trilha de auditoria desenhados para a sua organização e a sua conta AWS, conheça a adoção do Kiro com governança da RFX. Se a prioridade é a conta AWS em si, com IAM, detecção e evidência para auditoria, veja segurança na AWS.

Perguntas frequentes

O que é governança de IA no desenvolvimento de software?

É o conjunto de decisões e controles que define o que um agente de IA pode ler, executar e alterar no código e na infraestrutura, quem revisa o que ele produz e onde fica a evidência do que aconteceu. No Kiro, isso se distribui em camadas: permissões, arquivos fora do alcance do agente (.kiroignore), hooks de verificação, controles da organização no plano Enterprise e revisão humana no pipeline, com trilha de auditoria.

O Kiro lê arquivos .env por padrão?

Sem configuração, a documentação de permissões do Kiro informa que o agente lê arquivos dentro do workspace sem pedir confirmação. Para tirar credenciais e chaves do alcance, combine um .kiroignore com regras deny de fs_read no permissions.yaml e, no plano Enterprise, no managed-settings.json distribuído pela organização.

Um repositório clonado pode mudar as permissões do Kiro na minha máquina?

As regras de permissão do escopo de workspace ficam em ~/.kiro/workspace-roots/, fora do repositório, então um clone não injeta regras de permissão. Até o workspace ser marcado como confiável, o Kiro também deixa de carregar agentes, steering, MCP e skills do workspace e pede aprovação antes de cada comando de shell e de cada chamada MCP.

Os controles do plano Enterprise do Kiro podem ser contornados?

A própria documentação avisa que as políticas de permissão, o controle de MCP e o de ferramentas web são aplicados no cliente e podem ser contornados por quem tem acesso administrativo à máquina. Por isso o desenho correto combina distribuição por gestão de dispositivos (MDM), controle de acesso pelo provedor de identidade e controles independentes da estação de trabalho, como permissão mínima no IAM e aprovação no pipeline.

O registro de prompts do Kiro é dado pessoal sob a LGPD?

Sim. O registro de prompts do plano Enterprise grava o ID do usuário, o horário, os prompts e as respostas, o que identifica o colaborador, e pode conter dado de cliente se alguém colar esse dado no chat. Defina finalidade, informe os colaboradores, minimize o que entra no contexto, restrinja o acesso ao bucket e configure a retenção antes de ligar o registro.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.