Uma fintech que auditei no ano passado tinha políticas de IAM no console da AWS escritas com rigor, com papéis separados por função, MFA em ações sensíveis e CloudTrail ativo em todas as regiões. O relatório de acesso saía limpo. Na mesma semana, ao cruzar credenciais com o repositório interno, encontrei que metade dos desenvolvedores tinha permissão de push direto na branch principal do serviço de pagamentos, e três contas de serviço de CI possuíam tokens com escopo de administrador de organização no GitHub, gerados dois anos antes e nunca rotacionados. O controle no IAM estava maduro, mas o controle no repositório era inexistente. O atacante não precisaria sequer chegar à AWS: comprometendo uma conta de desenvolvedor, publicaria código malicioso diretamente em produção, passando pelo pipeline como mudança legítima.
O comportamento se repete em ambientes que tratam controle de acesso como domínio isolado do IAM. O princípio do menor privilégio, formalizado nos controles A.5.15 e A.8.2 da ISO 27001:2022 e detalhado no ciclo de provisionamento de A.5.18, funciona como propriedade que precisa atravessar todas as camadas onde uma identidade pode executar uma ação com consequência, e o repositório de código é uma dessas camadas, talvez a mais crítica em organizações que operam pipeline contínuo. Quem tem permissão de merge em main tem, na prática, capacidade de deploy. Quem gera um token de CI com escopo amplo cria uma identidade persistente que raramente aparece em revisões de acesso, porque essas revisões costumam olhar usuários humanos e ignorar contas de serviço.
A tese operacional é que menor privilégio é uma propriedade de sistema. Se o controle é denso no IAM e raso no Git, o atacante escolhe o caminho raso. A assimetria entre camadas produz uma superfície de ataque que o relatório de conformidade não captura, porque cada camada é auditada isoladamente e a soma não é verificada. O invasor não respeita a fronteira entre ferramentas, explora a composição. Um token de GitHub Actions que tem permissão pra publicar em um registro privado e simultaneamente pra alterar workflows é uma identidade com poder agregado que nenhum dos dois sistemas avalia integralmente.
A decomposição do mecanismo começa na identidade. Cada ator no sistema, humano ou automatizado, deve ter o escopo definido em função da ação mínima necessária pra a tarefa específica, e não da tarefa genérica associada ao cargo. Desenvolvedor de pagamentos precisa apenas de permissão de merge via pull request no diretório do serviço de pagamentos, nunca de push global no monorepo, e essa permissão pode ser concedida via CODEOWNERS combinado com branch protection. Conta de serviço de CI precisa de token de repositório com escopo limitado à ação executada, sem passar por token de organização, idealmente via OIDC federation com expiração curta, o que elimina o token de longa duração como artefato. O GitHub, o GitLab e o Bitbucket já expõem esses mecanismos há anos. A lacuna está na implementação.
O trade-off é a fricção operacional. Permissões granulares exigem manutenção contínua, e a tentação gerencial é conceder o superescopo uma vez e esquecer, porque o custo marginal de manter controle fino é percebido como maior que o risco de conceder demais. O custo real aparece apenas durante o incidente: um token de administrador vazado força revogação e rotação de toda a cadeia que confiou nele; um token com escopo de um repositório específico força contenção local.
Em um projeto recente, observei o efeito composto. Uma organização com cerca de oitenta desenvolvedores adotou OIDC federation pra CI em outubro de 2025, substituindo tokens pessoais e de máquina por credenciais efêmeras emitidas por workflow. No mesmo trimestre, aplicou CODEOWNERS obrigatório em todos os repositórios críticos e reduziu permissão de push direto a uma lista nominal de quatro mantenedores por repositório. O tempo médio de merge subiu cerca de dezoito por cento nas primeiras quatro semanas e estabilizou. O ganho veio três meses depois, quando um desenvolvedor teve a conta comprometida via phishing: o atacante conseguiu abrir pull requests, mas não conseguiu fazer merge em nenhum serviço crítico, porque a conta comprometida não era CODEOWNER dos repositórios relevantes. A contenção foi local, feita em menos de uma hora.
O efeito de segunda ordem é que a disciplina de escopo cria rastro auditável. Cada concessão passa a ser uma mudança registrada vinda de uma origem identificável, e cada merge crítico ganha aprovação nominal. A ISO 27001 exige revisão periódica de direitos de acesso no Anexo A.5.18, e essa revisão só se torna factível quando os direitos são granulares o bastante pra serem lidos um a um. Permissões amplas resistem à revisão porque ninguém consegue declarar com confiança se ainda são necessárias; permissões específicas aceitam a pergunta "esta pessoa ainda executa esta tarefa?" com resposta binária.
O perímetro de controle de acesso termina no ponto onde uma identidade pode causar efeito observável em produção. Em organizações modernas esse ponto está, com frequência, dentro do repositório de código e do pipeline que dali deriva. Tratar essas camadas como infraestrutura secundária produz uma assimetria que o adversário identifica antes do auditor, e a assimetria é onde o incidente acontece.