La etiqueta de la credencial no es el alcance de la credencial.
Un token de servicio de 1Password limitado a una bóveda puede cartografiar toda la organización: cada usuario, cada grupo y cada permiso. La etiqueta decía que era una sola bóveda. La API discrepaba. El alcance debe aplicarse de verdad, no etiquetarse.
La criptografía es a prueba de balas. SRP-6a según RFC 5054, AES-256-GCM, comparaciones en tiempo constante, prueba de conocimiento cero. 1Password acertó con la criptografía. Lo que no acertó fue con la etiqueta del bote.
Este mes, dos ingenieros de Token Security dedicaron tres días a realizar ingeniería inversa del protocolo de autenticación SRP propietario de 1Password. No buscaban una vulnerabilidad. Intentaban sustituir un puente SCIM por un cliente Python para herramientas de identidad no humana. Lo que encontraron fue una brecha entre lo que la credencial dice que puede hacer y lo que realmente puede hacer [1][2].
Un token de cuenta de servicio limitado a una sola bóveda, con permisos de lectura, puede enumerar a todos los usuarios de la organización. Todos los grupos. Todas las pertenencias a grupos. Todos los permisos de bóveda en todas las bóvedas. Nombres, correos electrónicos, estados y marcas de tiempo de la última autenticación. La etiqueta del token dice «una bóveda». La API dice otra cosa [1].
1Password lo ha confirmado. El comportamiento es intencional. El ajuste granular del alcance está en la hoja de ruta, sin fecha [2].
Hasta dónde llega realmente el token
Gil Portnoy y Henry, escribiendo para Token Security, documentaron cinco puntos de conexión de la API que un token de cuenta de servicio «de una bóveda» puede invocar con pleno éxito [1]:
/api/v2/users devuelve a todos los usuarios de la organización: UUID, nombre, correo electrónico, estado, tipo y marca de tiempo de la última autenticación. /api/v1/groups devuelve todos los grupos con sus permisos y estado. Los comandos de la CLI para pertenencia a grupos, usuarios y permisos de bóveda, y grupos de bóveda devuelven todos datos en vivo. /api/v3/account devuelve metadatos de la cuenta. /api/v2/vault/{id}/vaultaccess devuelve información de acceso a la bóveda.
Ninguno de estos puntos de conexión está limitado a la bóveda para la que se aprovisionó el token. Al token se le dijo «leer una bóveda». La API le dio un mapa de toda la organización [1].
He aquí el punto más afilado: la enumeración no funciona a través del SDK oficial de 1Password. Esa vía devuelve UNSUPPORTED o FORBIDDEN. Funciona a través de la API interna de la CLI, que los investigadores tuvieron que analizar mediante ingeniería inversa. El «alcance» es una restricción del lado del cliente en el SDK. La credencial subyacente tiene lectura en toda la organización. Un atacante no utiliza su SDK [1].
Los investigadores construyeron el cliente en unas 420 líneas de Python. Cinco puntos de conexión de la API. Visibilidad completa de la organización. Publicaron el análisis el 16 de julio [1].
El problema no es la cerradura. Es el llavero.
Los investigadores son precavidos en este punto. La criptografía es realmente sólida. La implementación de SRP utiliza una prueba de conocimiento cero estandarizada por el RFC: el servidor nunca ve la contraseña, el cliente nunca ve el salt, y cada fallo de autenticación devuelve el mismo mensaje de error, de modo que un atacante no obtiene información. 1Password documentó sus propias desviaciones no estándar (incluido un verso de «Penny Lane» de los Beatles incrustado en una constante criptográfica como huevo de pascua) y esas desviaciones son neutrales en materia de seguridad [1].
El problema no es la cerradura. Es lo que abre la llave. Cuando una credencial se etiqueta como «limitada a una bóveda», los administradores aprovisionan agentes con ella creyendo que el radio de impacto es reducido. El agente recibe una credencial. La credencial recibe el organigrama. Nadie pretendía eso, pero nadie puede ver que esté ocurriendo [1].
Cuando entrega a un agente un token «limitado», el agente opera dentro del alcance que la API realmente aplica, no del alcance que describe la etiqueta. Si el agente se ve comprometido, mediante una inyección de prompts, un archivo de convención envenenado, un ataque a la cadena de suministro o cualquiera de los vectores que las defensas basadas en texto no pueden cerrar por completo, el atacante no obtiene una bóveda. Obtiene la topología organizativa: quién pertenece a cada grupo, quién tiene acceso a cada bóveda y cuándo se autenticó cada persona por última vez. Es la fase de reconocimiento de una brecha, servida en una única llamada a la API [1].
La brecha entre el alcance documentado y el alcance efectivo no es exclusiva de 1Password. Toda API de gestión de credenciales toma decisiones de autorización implícitas que los administradores nunca ven. Lo que Token Security demostró es que la brecha es real, medible y explotable con un fin de semana de trabajo y un hook de Frida [1].
Qué hace de forma distinta una bóveda diseñada para esto
La función de la credencial es sobrevivir al mundo en el que se encuentra. Si un token «limitado» puede cartografiar su organización en silencio, el alcance nunca fue real. Fue una etiqueta.
Clavitor no etiqueta credenciales y espera lo mejor. El agente recibe una credencial con nombre explícito, recuperada en vivo en el instante de la llamada, inyectada en una única petición, y desaparece. No hay ningún token permanente que un atacante pueda reutilizar. No hay un punto de conexión de mapa organizativo tras una etiqueta de alcance que nadie verificó. La bóveda no expone la enumeración al agente. El agente alcanza aquello para lo que fue nombrado, y nada más.
Cada acceso queda registrado en el agente concreto que lo realiza, en la bóveda, y no en el extremo donde se ejecuta el agente. Si un token se ve comprometido, el radio de impacto es el alcance de esa única llamada, y no la topología organizativa que hay detrás.
Los principios detrás de una bóveda que aplica el alcance en lugar de etiquetarlo: Los diez principios de la gestión de credenciales
Clavitor (@clavitorai) es la bóveda de credenciales creada para agentes de IA, y contra ellos. clavitor.ai
Fuentes
[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec
[2] @TheTokenSec — hilo en X sobre el hallazgo de escalada de alcance, 16 de julio de 2026 — «1Password confirmed this is by design, to support vault-management workflows»