A etiqueta do credencial não é o âmbito do credencial.

A criptografia é à prova de bala. SRP-6a do RFC 5054, AES-256-GCM, comparações em tempo constante, prova de conhecimento nulo. A 1Password acertou na criptografia. O que falhou foi a etiqueta do frasco.

Este mês, dois engenheiros da Token Security passaram três dias a engenharia reversa do protocolo de autenticação SRP proprietário da 1Password. Não estavam à procura de uma vulnerabilidade. Estavam a tentar substituir uma ponte SCIM por um cliente Python para ferramentas de identidades não humanas. O que encontraram foi um intervalo entre aquilo que o credencial diz que pode fazer e aquilo que realmente pode fazer [1][2].

Um token de conta de serviço limitado a um único cofre, com permissões de leitura, consegue listar todos os utilizadores da organização. Todos os grupos. Todas as pertenças a grupos. Todas as permissões ao nível do cofre em todos os cofres. Nomes, emails, estados, marcas temporais da última autenticação. A etiqueta do token diz "um cofre". A API diz outra coisa [1].

A 1Password confirmou. O comportamento é intencional. A delimitação granular está no roteiro, sem data definida [2].

Aquilo a que o token realmente acede

Gil Portnoy e Henry, escrevendo para a Token Security, documentaram cinco endpoints de API que um token de conta de serviço "de um cofre" consegue aceder com sucesso total [1]:

/api/v2/users devolve todos os utilizadores da organização: UUID, nome, email, estado, tipo, marca temporal da última autenticação. /api/v1/groups devolve todos os grupos com as respetivas permissões e estado. Os comandos de CLI para pertenças a grupos, utilizadores e permissões de cofres, e grupos de cofres devolvem todos dados em tempo real. /api/v3/account devolve metadados da conta. /api/v2/vault/{id}/vaultaccess devolve informação de acesso ao cofre.

Nenhum destes endpoints está limitado ao único cofre para o qual o token foi provisionado. Ao token foi dito "ler um cofre". A API deu-lhe um mapa de toda a organização [1].

Eis o ponto mais afiado: a enumeração não funciona através do SDK oficial da 1Password. Esse caminho devolve UNSUPPORTED ou FORBIDDEN. Funciona através da API interna da CLI, que os investigadores tiveram de analisar em engenharia reversa. O "âmbito" é uma restrição imposta pelo lado do cliente no SDK. O credencial subjacente tem leitura ao nível de toda a organização. Um atacante não usa o seu SDK [1].

Os investigadores construíram o cliente em cerca de 420 linhas de Python. Cinco endpoints de API. Visibilidade total da organização. Publicaram o relatório a 16 de julho [1].

O problema não é a fechadura. É o chaveiro.

Os investigadores são cuidadosos neste ponto. A criptologia é genuinamente forte. A implementação de SRP usa uma prova de conhecimento nulo padronizada pela RFC: o servidor nunca vê a palavra-passe, o cliente nunca vê o salt, e cada falha de autenticação devolve a mesma mensagem de erro, pelo que um atacante não aprende nada. A 1Password documentou as suas próprias desvios não padronizados (incluindo uma letra dos Beatles de "Penny Lane" enterrada numa constante criptográfica como easter egg) e esses desvios são neutros em termos de segurança [1].

O problema não é a fechadura. É aquilo que a chave abre. Quando um credencial é etiquetado como "limitado a um cofre", os administradores provisionam agentes com ele na crença de que o raio de impacto é reduzido. O agente recebe um credencial. O credencial recebe o organograma. Ninguém queria isso, mas também ninguém consegue vê-lo a acontecer [1].

Quando dá a um agente um token "limitado", o agente opera dentro do âmbito que a API realmente impõe, não do âmbito que a etiqueta descreve. Se o agente for comprometido, através de uma injeção de prompt, de um ficheiro de convenção envenenado, de um ataque à cadeia de fornecimento, ou de qualquer um dos vetores que as defesas baseadas em texto não conseguem fechar por completo, o atacante não fica com um cofre. Fica com a topologia organizacional: quem está em que grupo, quem tem acesso a que cofres, quando autenticou cada pessoa pela última vez. É a fase de reconhecimento de uma violação, entregue numa única chamada de API [1].

A diferença entre o âmbito documentado e o âmbito efetivo não é exclusiva da 1Password. Todas as APIs de gestão de credenciais tomam decisões de autorização implícitas que os administradores nunca veem. O que a Token Security provou é que a diferença é real, mensurável e explorável com um fim de semana de trabalho e um hook do Frida [1].

O que um cofre construído para isto faz de forma diferente

A função de um credencial é sobreviver ao mundo onde se encontra. Se um token "limitado" consegue mapear silenciosamente a sua organização, o âmbito nunca foi real. Foi uma etiqueta.

A Clavitor não limita credenciais e espera pelo melhor. O agente recebe um credencial explicitamente nomeado, obtido em tempo real no instante da chamada, injetado num único pedido, e desaparece. Não existe um token permanente para um atacante reutilizar. Não existe um endpoint de mapeamento organizacional por trás de uma etiqueta de âmbito que ninguém verificou. O cofre não expõe enumeração ao agente. O agente acede àquilo para o qual foi nomeado, e a mais nada.

Cada acesso é registado no agente específico que o efetuou, no cofre, e não no endpoint onde o agente corre. Se um token for comprometido, o raio de impacto é o âmbito dessa única chamada, não a topologia organizacional por trás dela.

Os princípios por trás de um cofre que impõe o âmbito, em vez de o etiquetar: As Dez Regras da Gestão de Credenciais

A Clavitor (@clavitorai) é o cofre de credenciais construído para agentes de IA, e contra eles. clavitor.ai

Fontes

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — thread no X sobre a descoberta da escalada de âmbito, 16 de julho de 2026 — "1Password confirmed this is by design, to support vault-management workflows"