Una identidad puede ser válida… y aun así terminar autorizando algo que nadie permitió como conjunto. Ese es el supuesto que no se suele cuestionar. Se asume que cada credencial representa un permiso aislado, que se valida, se usa y queda contenida dentro de esa acción. Bajo esa lógica, acumular validaciones no cambia el sistema. Solo añade capacidades independientes.
Eso funciona mientras cada permiso se evalúa por separado. Una credencial entra, habilita una acción y su efecto termina ahí. Otra hace lo mismo en otro momento y en otro entorno. Todo parece limpio porque cada decisión conserva su propio límite y no altera el resto. El sistema responde como si cada autorización existiera sola.
Pero ese no es el sistema real. Las credenciales no desaparecen. Permanecen. Un usuario valida distintas acciones en distintos momentos. Cada una es correcta. Cada una fue autorizada bajo condiciones específicas. Cada una parece inofensiva por sí misma. El problema no está en cada permiso. Está en lo que ocurre cuando todos siguen activos al mismo tiempo.
Ahí aparece el cambio real. Un sistema recibe múltiples credenciales válidas. Cada una permite algo distinto. Ninguna representa un riesgo por separado. Pero cuando conviven, dejan de comportarse como piezas aisladas. Juntas cambian el nivel de acceso disponible. No porque alguien haya autorizado ese resultado, sino porque el sistema no distingue entre permiso individual y estado acumulado.
El modelo correcto ya no es una llave que abre una puerta. Es un tablero donde cada autorización deja una pieza activa, y el sistema sigue leyendo todas aunque hayan sido emitidas en contextos distintos. Lo que antes era secuencial se vuelve compuesto. Lo que antes era puntual se vuelve estructural.
En términos técnicos, esto no escala de forma lineal. Cada nueva credencial no añade solo una acción posible. Añade combinaciones. El sistema ya no ejecuta permisos aislados. Ejecuta estados acumulados. Y ese estado no fue diseñado como una unidad coherente. Se formó por persistencia de decisiones correctas que nunca fueron pensadas como conjunto.
Ahí aparece la consecuencia que importa. El acceso deja de depender de lo que el usuario pidió en ese momento. Empieza a depender de todo lo que el sistema nunca eliminó. La identidad deja de representar una intención actual y empieza a representar un historial activo de autorizaciones todavía disponibles.
Ese es el punto de ruptura. El usuario no solicita algo indebido. El sistema no valida nada incorrecto. Y aun así, la acción ocurre. No porque haya un error, sino porque cada parte que la compone fue autorizada en algún momento. Solo que nunca como una sola decisión.
Y cuando ese conjunto se ejecuta, ya no hay una validación única que puedas revocar. No existe un permiso individual que puedas retirar para deshacer el resultado. Porque el problema no está en una pieza. Está en la suma.
Ese es el daño irreversible. El sistema no solo pierde control sobre lo que permite. Pierde la capacidad de explicar por qué lo permitió. Y cuando una autorización no puede explicarse con una sola decisión, tampoco puede revertirse con una sola corrección.
A partir de ahí, el problema deja de ser técnico y se vuelve operativo. El usuario obtiene un acceso que nunca le fue concedido como totalidad. El desarrollador no ve una falla lógica; ve un privilegio emergente construido con permisos válidos. Y el sistema ejecuta algo que puede justificar por partes, pero no como conjunto.
En Sign, este no es un problema de validación ni de sincronización. Es un problema de acumulación de privilegio. La red no solo debe verificar identidades. Debe impedir que autorizaciones correctas, persistentes y reutilizables terminen construyendo accesos que nadie aprobó explícitamente.
Porque cuando múltiples permisos válidos construyen un acceso nuevo, el sistema ya no ejecuta una decisión.
Ejecuta una acumulación.
Y cuando lo que se ejecuta no puede revocarse, explicarse ni contenerse como una sola autorización…
la identidad deja de ser control.
Se convierte en privilegio emergente.