Elimine o token de longa duração: um playbook de CTO para segredos na era dos agentes

Seus segredos estão a uma instalação de pacote do roubo. Após relatos de que a CLI de um gerenciador de senhas popular foi alvo em uma campanha mais ampla de supply chain, e com ferramentas de IA agora pedindo conexões diretas aos seus SaaS, confiar em máquinas de desenvolvedores e sandboxes de agentes com tokens de longa duração tornou-se indefensável. Isso não é FUD; é uma lacuna de arquitetura. A solução não é outro vault; é mudar como as credenciais são emitidas, têm seu escopo definido e são usadas — em todos os lugares.

A ameaça mudou. Seu modelo de segredos provavelmente não.

No último ano, três tendências convergiram:

• Ataques de supply chain subiram na pilha — de registries comprometidos e typosquats a CLIs e extensões trojanizadas. A Checkmarx rastreou uma campanha tentando comprometer ferramentas de desenvolvedores, incluindo um pacote de Bitwarden CLI, via gerenciadores de pacotes. Tenha você usado exatamente esse pacote ou não, a lição é simples: a sua CLI “amigável” agora faz parte da superfície de ataque.
• Agentes de IA estão pedindo chaves de verdade — OpenAI e Anthropic estão lançando conectores de agentes para apps pessoais e corporativos. O ganho de conveniência é real — e a deriva de escopo também. Sem um broker, você está entregando tokens de atualização do OAuth (refresh) ou API keys para código que você não escreveu, rodando em contextos que você não controla totalmente.
• Equipes remotas e nearshore aumentaram o raio de impacto — cada novo laptop, rede doméstica e região multiplica os lugares onde um token pode ser armazenado em cache, capturado ou exfiltrado. Se você está reforçando o time com engenheiros sêniores no Brazil (boa decisão), ainda assim precisa de um plano de controle uniforme e aplicável para segredos.

Se o seu modelo atual é: "password manager + .env + GitHub PAT + cloud access key + DB password + SSH key", então você está dependendo de higiene de endpoint e disciplina do desenvolvedor. Isso não é estratégia; é desejo.

Princípio, não produto: intermediado, efêmero, auditável

Um programa moderno de segredos tem três propriedades:

• Intermediado: Fluxos obtêm credenciais a partir de um ponto de aplicação de política (PEP), não armazenadas em endpoints. Identidades chegam aos recursos por meio de um broker que pode impor postura do dispositivo, grupo de usuários, hora do dia, ambiente e escopo.
• Efêmero: Credenciais expiram rápido. Roles de nuvem via STS normalmente duram 15–60 minutos. Certificados SSH por 1–8 horas. Acesso a DB via IAM ou certs de curta duração. Tokens OAuth com escopos estreitos e TTLs curtos. Nada de chaves de acesso ou PATs de longa duração.
• Auditável: Todo grant é logado e atribuível a uma identidade de usuário/workload. Você consegue responder “quem acessou o DB de produção na sexta às 14:03 UTC?” sem raspar o histórico do terminal.

Vaults ainda importam — mas um vault é um repositório. O risco está no uso. O broker é o gargalo onde você aplica política, emite logs e revoga acesso.

Framework de decisão do CTO: três planos para corrigir, nessa ordem

1) Plano de identidade: estabeleça quem/o quê está solicitando

• Identidade humana: Exija SSO com MFA resistente a phishing (WebAuthn/passkeys). Elimine MFA legada sempre que possível. Limite a sessão do SSO a um dia de trabalho (8–12 horas) e exija reautenticação para escalada de privilégio.
• Identidade de workload: Pare de embutir segredos em containers e VMs. Use SPIFFE/SPIRE ou federação de identidade de workload nativa da nuvem (GCP WIF, AWS STS, Azure workload identities). Seu CI/CD deve trocar um token OIDC por um role; nada de chaves estáticas de nuvem em secrets do CI.
• Postura do dispositivo: Vincule o acesso a dispositivos verificados e gerenciados (atestado MDM/EDR); se o laptop não estiver criptografado, atualizado e monitorado, ele não acessa produção — ponto final.

2) Plano de emissão: elimine credenciais estáticas

• Roles de nuvem: Use OIDC para obter credenciais de role de curta duração. Padrão de 15–60 minutos. Proíba usuários IAM com access keys. Exija encadeamento de roles com IDs externos para fornecedores.
• Operações de Git: Substitua PATs clássicos por tokens granulares apoiados em SSO ou por certs SSH com TTL de 8 horas. Faça cumprir SSO de organização no GitHub ou GitLab; desative Git por HTTPS baseado em senha.
• Bancos de dados: Use autenticação via IAM (AWS RDS, Cloud SQL) ou certs x509 de curta duração emitidos por um broker (por exemplo, Teleport para acesso a DB, HashiCorp Boundary ou Vault PKI). Gire root/senhas para uso apenas de break-glass.
• SSH: Migre de chaves estáticas para certificados SSH assinados (a CA emite certs de 4–8 horas). As chaves nunca residem nos servidores; a revogação é instantânea ao interromper a CA.
• OAuth para SaaS: Ao conectar agentes ou CLIs a SaaS, use escopos de menor privilégio e tokens de acesso de curta duração. Prefira brokers fora de banda que possam cunhar e renovar em nome do agente, de modo que o agente nunca retenha um refresh token de longa duração.

3) Plano de egress: controle como os segredos são usados

• Brokers de credencial: Encaminhe acesso a DB/SSH/Kubernetes por um broker que termina no recurso e cunha credenciais efêmeras sob demanda (Teleport, Boundary, strongDM). Para agentes de IA, use um proxy de segredos dedicado (o projeto do HN Agent Vault é um exemplo open-source) para que o agente nunca toque credenciais brutas.
• Política de rede: Egress de produção deve ser default-deny, com listas explícitas de permitidos para endpoints de SaaS dos quais você depende. Se um agente tentar exfiltrar um token para um site de paste, deve falhar rápido e com alarde.
• Logging e canários: Logue todo grant e sessão. Plante tokens canários em lugares onde nunca deveriam ser usados; alerte no primeiro toque.

Como isso fica na prática

Eis um padrão mínimo e sensato que implementamos para startups dos EUA escalando engenharia com equipes nearshore no Brazil:

• Desenvolvedores se autenticam com SSO + WebAuthn. A postura do dispositivo é verificada (Kandji/Intune + EDR). Em São Paulo ou Austin, os controles de postura são os mesmos.
• Para acessar a AWS, o dev executa uma CLI assinada e com pinning que troca o SSO por um role da AWS de 45 minutos via STS. Nenhuma access key em disco.
• Para consultar o Postgres de produção durante um incidente de 15 minutos, o dev solicita acesso no broker. A política aprova com base no papel de on-call e na postura do dispositivo. O broker abre um túnel TCP e emite um cert de DB de 15 minutos. O log de consultas é mapeado à identidade.
• Para fazer push no GitHub, o dev usa certs SSH com TTL de 8 horas emitidos no login. A organização faz cumprir SSO e proíbe PATs clássicos.
• Agentes de codificação de IA rodam em containers efêmeros. Quando precisam chamar APIs internas ou o JIRA, pedem uma capacidade ao proxy de segredos do agente. O proxy cunha um token estreito e de curta duração com uma lista de endpoints e verbos permitidos e loga todo uso.

Nenhuma credencial bruta é armazenada em laptops ou nas sandboxes de agentes. Se uma CLI maliciosa tentar ler ~/.aws/credentials, não encontra nada. Se tentar exfiltrar um token, o token intermediado já expirou ou está restrito a uma única ação e faixa de IP.

Implementação: um plano de 90 dias

Dias 0–30: elimine tokens óbvios de longa duração

• Inventário: Enumere segredos usados por humanos, CI e serviços. Foque em PATs de GitHub/GitLab, chaves de acesso de nuvem, senhas de DB e chaves SSH.
• Política imediata: Exija SSO + WebAuthn. Faça cumprir expiração de PATs e minimização de escopo. Desative PATs clássicos para acesso à organização. Desative Git por HTTPS baseado em senha.
• Comece pela nuvem: Migre o CI para assunção de role baseada em OIDC (GitHub Actions OIDC para AWS/GCP/Azure). Gire e delete chaves de nuvem de longa duração.
• Proteja endpoints: Bloqueie histórico de shell do desenvolvedor para segredos e exija armazenamento no chaveiro do SO para quaisquer tokens de curto prazo. Ative varredura de segredos em pre-commit e no nível da organização no VCS.

Dias 31–60: introduza brokers e certs

• Escolha um broker: Opte por Teleport, Boundary, strongDM ou ferramenta comparável que seu time consiga operar. Coloque em HA na sua nuvem.
• SSH e DB primeiro: Migre o SSH para certs assinados por uma CA (TTL de 8 horas). Substitua senhas de DB por certs de curta duração emitidos pelo broker ou acesso via IAM. Tranque as credenciais de superusuário do DB para break-glass.
• Endurecimento do Git: Habilite SSO de organização, tokens granulares e assinatura obrigatória de SSH. Se seu VCS permitir, imponha TTL máximo de 7 dias para tokens de Git; caso contrário, use certs SSH.

Dias 61–90: traga agentes e SaaS para o escopo

• Proxy de segredos para agentes: Introduza um serviço de proxy mínimo para agentes de IA. Ele deve cunhar tokens de capacidade estreitos e com tempo limitado por ferramenta (ex.: apenas criação de issues no JIRA) e manter refresh tokens no servidor.
• Rede e canários: Aperte as listas de permitidos de egress de produção. Plante tokens canários em caminhos prováveis de exfiltração (dotfiles, logs de build) e alerte no primeiro uso.
• Drills: Faça um exercício de purple team: injete um binário de CLI trojanizado falso em uma sandbox e meça tempo até detecção, raio de impacto e velocidade de revogação.

Notas de tooling e números concretos

• STS e tempos de vida de tokens: Sessões de role do AWS STS costumam ser de 15–60 minutos; defina 45 minutos como equilíbrio. GCP WIF emite tokens de 1 hora. Certs SSH de 4–8 horas combinam com um bloco de trabalho. Certs de DB de 15 minutos induzem bom comportamento.
• Brokers: O acesso a DB/SSH/K8s do Teleport centraliza política e oferece gravações por sessão. Boundary é sólido se você já está em HashiCorp. Se você precisar construir o seu para agentes, copie os princípios: credenciais efêmeras, política na borda e logs de auditoria completos.
• Endurecimento de supply chain: Faça pinning e verifique CLIs com assinaturas do Sigstore/cosign. Trave o npm com ignore-scripts=true em ambientes sensíveis. Use pipx ou ambientes isolados para tooling Python. Mantenha um tap interno e assinado para fórmulas do Homebrew.

O que você vai trocar

• Fricção vs. risco: TTLs curtos causam reautenticações ocasionais. Aceite. A alternativa é um token de 90 dias em cache no histórico do shell de um laptop roubado.
• Lacunas em ferramentas legadas: Algumas ferramentas de terceiros não suportam OIDC ou certs. Use o broker para encapsulá-las ou quarentená-las fora de produção até suportarem.
• Risco de centralização: Um broker é caminho crítico. Rode em HA entre zonas, teste failover e tenha um plano de break-glass que não volte a segredos de longa duração.

Custo e ROI, com realismo

• Esforço de engenharia: Espere 2–3 engenheiros sêniores por 8–10 semanas para aterrar as mudanças centrais em uma organização de 50–150 engenheiros. Isso inclui nuvem, VCS, DB, SSH e proxy inicial para agentes.
• Licenciamento: Teleport/strongDM/ferramentas de broker normalmente custam US$ 20–40 por usuário/mês. Boundary e Vault são open-source, mas você pagará em operações. Você economiza isso em um único incidente evitado ou em horas de preparação de auditoria.
• Redução do raio de impacto: Migrar de PATs de 90 dias e senhas de DB indefinidas para credenciais de role de 45 minutos e certs de DB de 15 minutos faz os tokens roubados expirarem onde estão. A maioria das tentativas de exfiltração vira barulhenta e inútil.

Equipes nearshore: mesmo plano de controle, ergonomia diferente

Engenheiros no Brazil trabalhando com 6–8 horas de sobreposição com times dos EUA devem ter controles de postura e caminhos intermediados idênticos. Os únicos ajustes que recomendamos:

• Brokers conscientes de latência: Coloque uma borda de broker perto de São Paulo (AWS sa-east-1, GCP southamerica-east1) para manter túneis de DB ágeis. Termine onde os recursos vivem.
• Jurisdição de dados: Se você espelhar dados para o Brazil por latência, garanta que seu broker imponha políticas no nível do recurso para que PII permaneça onde deve. Mantenha logs de auditoria centralizados nos EUA para compliance.
• Higiene de conectividade: Exija split DNS e VPN com postura de dispositivo para recursos sensíveis; não dependa de internet pública para acesso a DB de produção mesmo com certs.

Não espere a próxima manchete

O ciclo de notícias sobre a Bitwarden CLI vai passar. As integrações de agentes vão ficar mais chamativas. Outra CLI vai cair. O seu trabalho é tornar esses eventos desinteressantes para sua organização. Você faz isso eliminando segredos de longa duração, intermediando o acesso na borda e reduzindo a autoridade e o tempo de vida de cada token até que sejam quase inúteis para um atacante.

Você não precisa de um programa de zero trust de 12 meses para chegar lá. Em 90 dias, com esforço focado e os brokers certos, você consegue tornar o próximo pacote comprometido ou conector de agente superdimensionado um não-evento.

Principais pontos

• Pare de armazenar segredos poderosos e de longa duração em máquinas de desenvolvedores e em sandboxes de agentes; o perfil de risco mudou.
• Adote um modelo intermediado, efêmero e auditável: credenciais de curta duração via STS/OIDC, certs SSH, auth de DB via IAM e um broker de acesso que aplique política.
• Controle egress e escopo para agentes de IA com um proxy de segredos; não entregue refresh tokens aos agentes.
• Implemente em 90 dias: elimine tokens de longa duração, suba brokers, migre SSH/DB para certs e traga agentes e SaaS para o escopo.
• Espere fricção menor e lacunas em ferramentas; a redução do raio de impacto e a auditabilidade compensam.
• Equipes nearshore no Brazil se encaixam naturalmente nesse modelo; posicione bordas de broker regionalmente e mantenha a política idêntica.