A Pinterest Vincula Cada Caminho de Código a um Papel. Esse é o Modelo de Permissão de Agentes.

A Pinterest opera centenas de workspaces Terraform que governam dezenas de milhares de recursos AWS, e a credencial de nenhum engenheiro decide o que cada mudança pode tocar. Um arquivo de configuração decide. Ammar Ekbote e Chan Kim, Senior Software Engineers da Pinterest, publicaram neste mês o desenho do Resource Provisioner Pipeline (RPP), e a frase que sustenta tudo é curta: “By linking specific code paths to specific workspaces and roles, we ensure that changes are made in the right environment with the absolute minimal IAM permissions required.”

Lido como encanamento de Terraform, o texto vira higiene de infraestrutura. Ele é hoje a formulação publicada mais limpa de um modelo de permissão para agentes.

Nada ali é ideia nova. Menor privilégio, controle duplo e CI auditável são ortodoxia de segurança há duas décadas. O que a Pinterest entregou é justamente a parte que costuma ser pulada: um formato concreto de vínculo, uma sequência concreta de portões e um número de escala que torna os dois críveis.

O Vínculo é um Arquivo, Não uma Convenção

O RPP mantém uma configuração central de mapeamento de workspaces. Cada entrada declara quatro coisas:

name, a identidade do workspace
working_directory, o caminho de código que aquele workspace governa
github_repo, o repositório onde esse caminho vive
agent_iam_roles, os papéis reduzidos que a execução assume

Essa é a superfície inteira de permissão. Uma página de wiki descrevendo quem deveria mexer em quê governa nada; uma cultura de revisão em que o engenheiro sênior repara que algo parece estranho governa quase nada. O RPP usa um arquivo que o pipeline lê antes de rodar qualquer coisa, e a resposta para “o que essa mudança pode fazer” sai do caminho alterado, não da identidade de quem abriu o pull request.

A consequência importa mais que o formato. Quando a permissão deriva do caminho, o autor se torna irrelevante para o raio de dano. Um engenheiro sênior de confiança e um agente autônomo que abram o mesmo pull request contra o mesmo diretório recebem capacidade idêntica. Nenhum dos dois alarga isso sendo persuasivo, e nenhum dos dois alarga isso estando comprometido.

A Pinterest também valida o bloco de backend: se o backend de estado declarado não corresponde ao diretório em que a execução acontece, o build falha. Essa é a cláusula antifraude. Sem ela, uma mudança poderia morar em um caminho governado e gravar seu estado, e seus recursos, silenciosamente em outro lugar.

O Portão de Quatro Passos

Toda mudança percorre a mesma sequência, e cada passo existe para pegar uma falha diferente.

Lint. A análise estática roda em todo pull request com regras Semgrep customizadas, ao lado de integrações Helix e de IA. É a camada barata, que pega erros de padrão antes que algo caro comece a rodar.

Plan. O Terraform plan roda automaticamente, e um plan que falha bloqueia o merge. O ponto não é que a saída do plan seja informativa. O ponto é que a falha do plan é condição de bloqueio, não um comentário que alguém talvez leia.

Aprovação humana. Os code owners aprovam o pull request. A Pinterest é explícita sobre por que esse passo não é cerimônia: “This intentional step guarantees that code owners are consciously authorizing infrastructure changes.” A titularidade é imposta via CODEOWNERS, então quem aprova é a pessoa responsável por aquele caminho, e não quem estiver online.

Apply. Nada aplica no merge. O apply acontece apenas quando alguém publica um comentário explícito no pull request. A separação entre “isso está correto” e “faça agora” é preservada como dois atos humanos distintos.

A centralização paga um segundo dividendo que a própria Pinterest aponta: “If a widespread vulnerability occurs (such as a runner shell vulnerability), we can roll out a fix in a single centralized place instead of modifying hundreds of repositories.” Um pipeline copiado em trezentos repositórios são trezentas operações de correção. Um pipeline que todo repositório chama é uma só.

Onde Isso Transfere

Terraform é a instância. O padrão generaliza para qualquer agente que escreve em um sistema de registro, que é a maioria dos agentes interessantes.

Já argumentamos que a caixa de contenção precisa vir da infraestrutura, e não do prompt, e que permissões pertencem ao lugar onde o dado mora. O RPP é a aparência desses argumentos quando alguém de fato os constrói e os opera em uma escala que vale citar.

Troque os substantivos e a estrutura se mantém. Um agente que atualiza um livro-razão de cobrança: o vínculo mapeia o caminho do módulo a um papel de banco com escrita exatamente nas tabelas daquele módulo. Um agente que grava em um CRM: o vínculo mapeia o caminho da integração a um escopo de API que cobre exatamente os objetos permitidos. Um agente que altera um modelo do data warehouse: o vínculo mapeia o diretório do modelo a um papel e a um schema específico, com o equivalente à validação de backend conferindo que o schema alvo corresponde ao diretório.

O passo de simulação também transfere, e é o que mais times pulam. O Terraform plan existe porque o Terraform é declarativo. A maioria dos sistemas de registro não é, então o equivalente precisa ser construído: uma escrita simulada que produza um diff legível e uma regra de que a simulação falha bloqueia o merge. Sem isso, a aprovação humana aprova intenção, e não efeito. O revisor está concordando com uma descrição do que a mudança vai fazer, que é exatamente aquilo que um agente sabe fazer soar razoável.

O Que Isso Custa

Ser honesto sobre o trade-off facilita vender o padrão internamente.

Execução vinculada ao caminho significa que a fronteira do workspace e o layout do código passam a ser a mesma decisão. Dividir um diretório significa dividir um workspace e um papel. Times que reorganizam repositórios com leveza vão sentir o atrito imediatamente, e esse atrito é o mecanismo funcionando.

Apply por comentário explícito significa que alguém precisa estar presente. Para uma mudança pequena às 16h de uma sexta, isso soa burocrático. É a mesma burocracia que impede um agente de mesclar e publicar uma mudança de infraestrutura enquanto todo mundo dorme.

Pipelines centralizados criam dependência central. Quando o RPP quebra, centenas de repositórios param. A Pinterest aceita isso porque a propriedade inversa, corrigir em um lugar em vez de centenas, vale mais que o risco de disponibilidade. Essa conta só fecha se o pipeline central for tratado como serviço de primeira linha.

Faça Isso Agora

Escolha o agente da sua organização com mais acesso de escrita a um sistema de registro. Abra o arquivo, ou a página de wiki, ou a memória tribal que responde “o que esse agente pode alterar”. Então faça uma única pergunta: a resposta deriva do caminho de código ou de uma credencial que o agente carrega?

Se for credencial, você está confiando no autor. Reescreva como vínculo. Um caminho, um papel, permissões mínimas e falha de build quando o alvo declarado não corresponder ao diretório em execução. Depois acrescente o portão de simulação e faça a falha dele bloquear o merge. Aprovação humana e apply por comentário podem vir depois. O vínculo é a peça que torna o resto exigível em vez de sugerido.

A Pinterest não descobriu nada. Escreveu a ortodoxia em um formato copiável na segunda-feira, em uma escala que remove a desculpa de que aquilo não funciona no grande.

Fontes

Pinterest Engineering. “Securing Infrastructure at Scale: Introducing Pinterest’s Resource Provisioner Pipeline (RPP).” Julho de 2026.

A Victorino ajuda organizações de engenharia a transformar permissões de agentes em vínculos por caminho que o pipeline impõe: contato@victorino.com.br | www.victorino.com.br