Até aqui, falamos sobre o que mudou no Kiro CLI e sobre como ele lida com segurança no nível individual. Agora quero trazer isso para o ambiente corporativo.
Instalar uma ferramenta de IA no computador pessoal é decisão individual. Colocá-la dentro de uma organização é outra história. E o Kiro CLI foi desenhado pensando nessa segunda realidade.
Um agente, múltiplas superfícies: IDE, CLI, Web e Mobile
O Kiro não é apenas uma ferramenta de terminal. É uma plataforma unificada que opera em múltiplas superfícies — IDE, CLI, Web e Mobile — com o mesmo motor de agente por trás.
Isso significa que:
A configuração é portável entre superfícies.
As regras de permissão funcionam da mesma forma em todas.
O que você define em um lugar, vale nos demais.
A governança é centralizada, independente de como o time acessa.
Para ambientes corporativos, essa unificação é essencial. Em vez de governar cinco ferramentas diferentes com cinco modelos de segurança distintos, você governa uma plataforma com controles consistentes.
Permissões: controle granular real
O sistema de permissões do Kiro é declarativo e baseado em capabilities. Funciona assim:
Capabilities — o que o agente pode fazer:
fs_read (leitura de arquivos)
fs_write (escrita de arquivos)
shell (execução de comandos)
web_fetch / web_search (acesso à web)
mcp (servidores MCP)
subagent (delegação para subagentes)
Effects — o que acontece quando o agente tenta usar uma capability:
deny → bloqueado sempre
ask → pede aprovação do usuário
allow → executa silenciosamente
Prioridade: deny > ask > allow. Uma regra de deny sempre vence, não importa onde está definida.
Na prática, isso se traduz em um arquivo permissions.yaml:
rules:
- capability: fs_write
match: ["*.env", "*.pem", "*.key"]
effect: deny
- capability: shell
match: ["rm -rf *", "sudo *"]
effect: deny
- capability: shell
match: ["git *", "npm *"]
effect: allow
- capability: fs_read
effect: allow
Isso é menor privilégio implementado em YAML. Simples, auditável e declarativo.
Escopos: do individual ao corporativo
O que torna o modelo de permissões do Kiro poderoso para empresas é a arquitetura de escopos:
Kiro (hardcoded) — Interno, não configurável. Controlado pelo Kiro (invariantes de segurança).
Administration — managed-settings.json (Enterprise). Controlado pelo administrador da organização.
User — ~/.kiro/settings/permissions.yaml. Controlado pelo próprio usuário.
Workspace — ~/.kiro/workspace-roots/<hash>/permissions.yaml. Controlado pelo usuário, por projeto.
Agent — Dentro do perfil do agente. Controlado por quem criou o agente.
Session — Em memória. Decisões tomadas durante a sessão.
O ponto-chave: as regras de administração (Enterprise) aplicam deny e ask, nunca allow. Isso garante que o administrador pode restringir, mas nunca relaxar proteções do nível Kiro.
E mais: as permissões de workspace ficam fora do repositório, em ~/.kiro/workspace-roots/<hash>/. Um repositório clonado não pode injetar regras de permissão — a confiança é algo que você configura na sua máquina, não algo que o código fonte define.
Governança Centralizada
No console Enterprise do Kiro, administradores controlam:
Modelos — Quais modelos de IA o time pode usar. Você pode restringir a uma lista aprovada e definir um modelo padrão para todos os clientes.
MCP (Model Context Protocol) — Quais servidores MCP são permitidos. Você pode desabilitar MCP completamente ou definir um allow-list de servidores homologados. A política pode ser definida no nível da organização ou sobrescrita por conta.
API Keys — Por padrão, usuários não podem gerar API keys. O administrador habilita explicitamente.
Web Tools — web_search e web_fetch podem ser desabilitados para todos os usuários quando a organização não quer que o agente acesse a internet.
Cloud Sessions — Para organizações usando IAM Identity Center, Cloud Sessions ficam desativadas por padrão até o administrador optar por habilitá-las.
Isso é governança prática: não uma política em PDF, mas controles reais que se aplicam automaticamente.
Trusted Workspaces: confiança explícita
Na primeira abertura de um projeto, o Kiro CLI pergunta:
“Você confia neste workspace?”
Em workspaces não confiáveis, o agente restringe capabilities: sem shell, escrita limitada. O agente opera no modo defensivo até você explicitamente confiar naquele ambiente.
Para ambientes corporativos isso é relevante: um repositório desconhecido que alguém clona não ganha acesso automático a nada. A confiança é um ato deliberado.
Custom Agents: padronizando o time
O Kiro permite criar agentes personalizados com perfis em Markdown que incluem:
System prompt customizado.
Permissões específicas embutidas.
Servidores MCP inline.
Seleção de ferramentas por tag.
Resources específicos.
Isso significa que a equipe de Segurança pode ter um agente configurado de uma forma, a equipe de Desenvolvimento de outra, e a equipe de Infraestrutura de outra. Cada um com as permissões e ferramentas adequadas para sua função.
Os agentes vivem em .kiro/agents/ no repositório — compartilhados com o time via Git, mas as permissões de execução continuam sendo controladas pelo usuário/admin.
Headless Mode: automação com controle
O Kiro CLI suporta headless mode — execução sem interface interativa, ideal para CI/CD e automação.
Isso permite integrar o Kiro em pipelines de forma programática:
Análise automatizada de código.
Geração de relatórios.
Execução de tarefas de manutenção.
Validações de segurança em pull requests.
O headless mode respeita as mesmas permissões e controles. Automação não significa ausência de governança.
Proteção de Dados: o que o Kiro faz com suas informações
Para organizações que se preocupam com dados, o Kiro documenta claramente:
Criptografia:
TLS 1.2+ para tudo em trânsito.
AWS KMS para dados em repouso.
Empresas podem usar Customer Managed Keys (CMK) — chaves que você cria, controla e gerencia.
Dados Enterprise:
Conteúdo de usuários Enterprise não é usado para treinamento de modelo (service improvement).
Enterprise users são automaticamente opted-out de telemetria e coleta de conteúdo.
Armazenamento:
Sessões locais ficam em SQLite em ~/.kiro/.
Cloud Sessions ficam na região configurada pelo admin.
Cross-region inference pode processar em regiões diferentes, mas não altera onde dados são armazenados.
Opt-out:
Usuários individuais podem desabilitar coleta de telemetria e compartilhamento de conteúdo nas configurações.
Managed Updates: atualização controlada
Para ambientes Enterprise, o Kiro oferece Managed Updates — atualizações gerenciadas que dão ao administrador controle sobre:
Quando novas versões são distribuídas.
Para quais grupos.
Em qual ritmo.
Isso se conecta diretamente com o conceito de homologação: a empresa pode avaliar uma nova versão antes de distribuí-la em escala, sem que colaboradores individuais atualizem por conta própria.
Identidade e Autenticação
O Kiro Enterprise suporta conexão com Identity Providers corporativos. Cada ação do agente está vinculada a um usuário autenticado, o que responde à pergunta fundamental de auditoria:
“Quem fez isso?”
A ferramenta também disponibiliza monitoramento e tracking para administradores acompanharem o uso dentro da organização. Sim, o Kiro faz perfeitamente o papel de “fofoqueiro” que precisamos.
Skills e Steering: padronização de conhecimento
Dois recursos do Kiro se tornam especialmente valiosos em times:
Skills (.kiro/skills/<nome>/SKILL.md): capacidades reutilizáveis que são automaticamente detectadas por todos os agentes no workspace. O time pode criar skills compartilhados que padronizam como o agente executa determinadas tarefas, garantindo consistência.
Steering (documentos de direcionamento): podem ser configurados com modos de inclusão (always, fileMatch, manual, auto), permitindo que guidelines de segurança, padrões de código ou procedimentos operacionais estejam sempre presentes no contexto do agente.
Isso transforma o Kiro de “um chatbot que cada pessoa usa do seu jeito” em “um agente que segue as práticas da equipe”.
O que o Kiro bloqueia por padrão (invariantes de segurança)
Existem ações que o Kiro nunca permite, independente de configuração:
Escrita em ~/.kiro/settings/ — o agente não pode modificar suas próprias permissões.
Escrita em .kiro/settings/ — mesma razão.
Escrita em ~/.kiro/workspace-roots/ — proteção das configurações de confiança.
E existem ações que sempre pedem aprovação:
Escrita em .git/**
Escrita em .kiro/agents/**
Escrita em .kiro/hooks/**
Escrita em .kiroignore
Esses são limites invioláveis. Não importa o que o usuário configure, o agente não vai alterar seu próprio limite de segurança.
Na prática: como isso muda a adoção corporativa
Quando uma empresa avalia o Kiro CLI, ela pode apresentar à Segurança:
Menor privilégio — Permissions YAML com deny/ask/allow por capability.
Controle centralizado — Enterprise governance (modelos, MCP, web, API keys).
Proteção de dados — CMK, opt-out de treinamento, criptografia em trânsito/repouso.
Auditoria — Sessões rastreáveis, identidade vinculada, monitoramento.
Segmentação de acesso — Custom agents por equipe com permissões distintas.
Controle de atualizações — Managed Updates.
Confiança explícita — Trusted Workspaces.
Automação segura — Headless mode com mesmas permissões.
Padronização — Skills + Steering compartilhados via Git.
Isso não elimina a necessidade de avaliação, homologação e processos internos. Mas oferece respostas concretas para as perguntas que Segurança precisa fazer.
Shadow AI vs. alternativa oficial
E aqui voltamos a um ponto que mencionei no post anterior: Shadow AI.
Se a organização não oferece ferramentas aprovadas, as pessoas vão usar o que encontrarem. E vão usar sem controle, sem governança e sem visibilidade.
O Kiro oferece uma alternativa onde:
O administrador define o que pode e o que não pode.
As permissões são declarativas e auditáveis.
Os dados Enterprise não são usados para treinamento.
As atualizações são controladas.
A identidade está vinculada a cada ação.
É a diferença entre “o time usa IA sem controle nenhum” e “o time usa IA dentro de uma estrutura governada”.
E agora vem a parte divertida
Até aqui eu falei bastante de governança, permissões e controles.
No próximo, e último post desta série, vou sair completamente da teoria e trazer ideias de como eu utilizaria o Kiro CLI no dia a dia de Segurança da Informação e o que essa tecnologia consegue fazer pelo nosso trabalho.
Até lá!