"Cero claves permanentes" se convirtió en un objetivo alcanzable en 2026
En 2026, conservar API keys permanentes en entornos cloud-native pasó a considerarse "operación heredada". Las claves permanentes se almacenan durante largos períodos en archivos o variables de entorno, y los vectores de exposición son múltiples: commits accidentales en código, exposición en logs de CI, copias de seguridad personales de empleados que ya no están en la empresa. Según un estudio conjunto de GitGuardian y Truffle Security publicado a finales de 2025, el número de API keys válidas encontradas en repositorios públicos de GitHub supera los 13 millones anuales, con 2,1 millones solo de AWS Access Keys detectadas.
La combinación de plataformas de gestión de secretos e identidad de workload es lo que permite mejorar esta situación de forma estructural. La gestión de secretos habilita la operación de "emitir tokens de corta duración dinámicamente cuando se necesitan e invalidarlos después de su uso", mientras que la identidad de workload permite el diseño de "llamar a APIs cloud sin necesidad de tener claves permanentes". La integración de ambas hace posible, a escala de toda la organización, el objetivo de que "no existan claves de larga vida en ningún lugar".
Comparación de plataformas de gestión de secretos
HashiCorp Vault sigue siendo el estándar de facto en el mercado enterprise. Su fortaleza es la funcionalidad de secretos dinámicos: proporciona de forma nativa el mecanismo de "generar nuevas credenciales al momento de la solicitud y hacerlas expirar automáticamente transcurrido el TTL" para bases de datos, APIs cloud, SSH y PKI. Con PostgreSQL, por ejemplo, se puede configurar en pocas líneas de política que "cada vez que la aplicación inicia sesión se cree un usuario temporal que se elimina a los 5 minutos". Su debilidad es el costo operativo: mantener una configuración HA con logs de auditoría y Auto-unseal requiere un equipo de plataforma dedicado. En 2026 se observa una tendencia creciente hacia la adopción de HCP Vault.
AWS Secrets Manager es la primera opción en entornos nativos de AWS. Permite controlar los permisos de lectura con granularidad fina mediante roles IAM y ofrece integración estándar de rotación con RDS, DocumentDB y Redshift. Su debilidad es el entorno multi-cloud: para centralizar la gestión de credenciales de GCP y Azure hay que construir el pipeline de ingesta manualmente.
Doppler es un SaaS orientado a la experiencia del desarrollador que ha ganado cuota rápidamente entre startups y empresas medianas. Con un solo comando de CLI sincroniza secretos entre entornos local, CI y producción, y la integración con GitHub Actions, Vercel y Heroku se configura con ajustes mínimos. Su desventaja es la debilidad en la funcionalidad de secretos dinámicos: como plataforma base de emisión real de tokens de corta duración, es inferior a Vault. En 2026, la configuración de "Doppler para entorno de desarrollo, Vault para producción" no es inusual. Infisical, 1Password Secrets Automation y Bitwarden Secrets Manager también se han convertido en actores que no se pueden ignorar.
SPIFFE/SPIRE: el estándar de identidad de workload
En el mundo de la identidad de workload, SPIFFE y SPIRE se consolidaron como la especificación estándar y su implementación de referencia respectivamente. El núcleo de SPIFFE es la idea de "asignar a cada workload un ID único basado en certificados X.509 llamado SVID (SPIFFE Verifiable Identity Document), y usar ese ID para autenticación mutua y emisión de claves de corta duración".
SPIRE es la implementación nativa de Kubernetes, con una arquitectura de servidor (autoridad certificadora) y agente (residente en cada nodo). El agente inspecciona los atributos de runtime del Pod (service account, namespace, hash de imagen) y, si hay una Registration Entry coincidente, emite un SVID con ID SPIFFE al Pod. La aplicación obtiene el SVID a través de la Workload API y lo usa para comunicaciones mTLS con otros servicios o como JWT-SVID. El valor de SPIFFE está en poder crear una "capa de identidad común que atraviesa cloud, on-premise e híbrido", y su adopción avanza en entornos mixtos de múltiples clouds y edge. En Japón, NTT Communications, LINE Yahoo y Mercari han anunciado públicamente su adopción.
Workload Identity Federation
La WIF (Workload Identity Federation) de GCP recibe un OIDC/SAML Assertion y realiza el intercambio de tokens por el Service Account correspondiente. Cuando se opera GCP desde GitHub Actions, antes era necesario poner un JSON de service account key en GitHub Secrets; con WIF, el token OIDC se verifica directamente en el lado de GCP y se obtiene un Access Token temporal. Las claves permanentes desaparecen de la operación del repositorio: es el ejemplo típico de zero trust. La Workload Identity de Azure emite Federated Credentials desde Entra ID a workloads de AKS, y AWS logra el equivalente de WIF con IAM Roles Anywhere e IAM OIDC Provider.
El punto clave en el diseño de WIF es "la descripción del boundary de confianza". Permitir matches amplios como `repo:my-org/*:ref:refs/heads/*` crea vectores de abuso desde repositorios forked o rutas de escalamiento para atacantes con permisos de creación de branches. Se recomienda incluir en las condiciones el nombre de la organización, el repositorio, el entorno y la branch, todos a la vez.
Secretless Broker: ocultando completamente las claves a la aplicación
El Conjur Secretless Broker de CyberArk ofrece un diseño que oculta "la existencia misma de las claves" al proceso de la aplicación. Antes, la aplicación obtenía la clave con el cliente de Vault, la retenía en memoria y luego se conectaba a la base de datos; durante ese período podría quedar expuesta en un core dump. El Secretless Broker es un proxy local entre la aplicación y la base de datos o API: la aplicación se conecta en texto plano a `localhost:5432`, y el proxy se autentica usando el SPIFFE ID, obtiene la clave de Vault y gestiona la conexión y autenticación con el sistema destino. Funciona bien con el patrón de Kubernetes Sidecar, y en 2026 crece la implementación integrada con Istio y Linkerd.
NHI en la era de los agentes de IA
En 2026, los agentes de IA emergieron como el nuevo cliente principal de la gestión de secretos y la identidad de workload. A través de LangChain, AutoGen, CrewAI o los servidores MCP de Anthropic, los agentes operan de forma cruzada en Slack, Jira, GitHub y APIs internas. Las implementaciones ingenuas suelen terminar en configuraciones donde el PAT personal del desarrollador se escribe en variables de entorno, lo que quiebra el principio NHI (Non-Human Identity) y combina los tres problemas clásicos: no apto para auditoría, exceso de privilegios e imposibilidad de revocar el acceso cuando la persona se va.
La arquitectura estándar es la siguiente: la entidad del agente (Pod/Serverless) recibe un SPIFFE ID y se identifica ante Vault. Vault emite tokens de corta duración para cada SaaS integrado a través del motor de secretos dinámicos, y los invalida al finalizar el trabajo. Los logs de auditoría registran "qué SPIFFE ID, a través de qué secreto, operó qué recurso".
Clave es el movimiento de la especificación "OAuth for Agents". En un borrador que avanza en el IETF en 2026, se está estandarizando el flujo de autorización cuando el agente actúa en representación del usuario (on-behalf-of), la expresión de alcances y los campos de auditoría. Okta, Auth0 y Cloudflare ya ofrecen implementaciones anticipadas y soportan la emisión de tokens que incluyen los claims `actor` y `on_behalf_of`. Cuando se opera un servidor MCP internamente, la práctica recomendada es emitir una NHI por servidor MCP e identificarlos mediante SPIFFE ID.
Prioridad de implementación y pasos de migración
La prioridad se determina por "impacto en caso de exposición × frecuencia de exposición". En la primera fase, se reemplazan las claves permanentes de CI/CD por WIF: solo con cambiar GitHub Actions → AWS/GCP/Azure a base de OIDC se eliminan la mayoría de los secretos de CI. En la segunda fase, se migra la conexión de la base de datos de la aplicación a secretos dinámicos. En la tercera fase, se introduce SPIFFE/SPIRE y la comunicación entre microservicios pasa a mTLS basado en SVID. En la cuarta fase, se diseña la NHI de los agentes de IA e integra la infraestructura de operación de agentes para que aproveche todo lo anterior.
Una falla de Vault tiene un impacto especialmente grande; la configuración HA es obligatoria, y también hay que documentar el "camino de Break Glass cuando Vault está completamente caído". Zero trust no puede significar "cero disponibilidad": diseñar un camino de excepción que no paralice el negocio en caso de falla es la señal de madurez. La era en la que cero claves permanentes es técnicamente alcanzable ya llegó. Lo que lo impide ya no es la falta de tecnología, sino tres factores: el diseño de la organización operativa, la integración en el proceso de desarrollo y la construcción de consenso con la alta dirección.