Identity & Trust

El dolor

Llegas a esta página probablemente porque alguno de estos te describe:

• Tu organización ya tiene agentes IA en producción (asistentes internos, pipelines de RAG, agentes de soporte) que consumen APIs internas con un service account compartido o un token de larga duración guardado en un secret manager. Funciona, pero no podés contestar la pregunta “¿qué agente hizo qué cosa específica?” cuando un auditor la hace.
• La PKI corporativa legacy emite certificados manualmente, los rota cada 12 meses, y nadie sabe quién operó la CA por última vez. Cumple formalmente con la regulación pero no soportaría una auditoría real si alguien escarba.
• Workload identity en Kubernetes está medio implementada — algunos pods usan service accounts, otros van con tokens estáticos montados como volumes. El platform team sabe que está mal pero no tiene bandwidth para migrar a un modelo coherente.
• Compliance pidió cifrado y autenticación entre microservicios. El equipo respondió “ya tenemos mTLS con cert-manager” pero los certs los firma una CA self-signed sin rotation policy, sin revocation, sin attestation de qué workload los obtuvo.
• El equipo de seguridad sabe que SPIFFE/SPIRE existe y resolvería varios de estos problemas, pero el costo de aprender, desplegar y migrar producción se ve mayor que el costo de seguir con la deuda actual.

Ninguno de estos es problema de tooling — todos los componentes existen open source. Es problema de falta de ingeniero senior con la combinación de criptografía aplicada + Kubernetes + compliance que diseñe la arquitectura completa y la opere durante el período de cutover.

Lo que CultureTech prepara

Un Staff Engineer embebido en el equipo del cliente durante 3-6 meses, con foco en uno de estos dominios (no los cinco al mismo tiempo):

• Workload identity end-to-end con SPIFFE/SPIRE — Server, agents deployed por cluster, federación cross-cluster, integración con el IdP corporativo (Okta, Entra, Keycloak). El output es: cada workload obtiene su SVID criptográfica al boot, sin secrets estáticos, con attestation de namespace + service account + node identity.
• Agent identity para IA en producción — cada agente IA (asistente, RAG worker, pipeline batch) tiene identidad criptográfica propia, no un token compartido. Las llamadas a APIs internas se autentican con SVID, no con bearer tokens recyclables. El audit log responde “qué agente, qué llamada, qué payload” con prueba criptográfica.
• PKI moderna auditable — reemplazo de CAs legacy con SPIRE upstream CA o Smallstep/HashiCorp Vault como CA delegada. Rotation policy automática, revocation lists que sí se consultan, attestation de emisión. Documentación de operación pensada para que el auditor del banco la entienda, no solo el equipo de seguridad.
• Cross-cluster trust domains — si la organización tiene clusters en distintas regiones, cloud y on-prem, o k8s + máquinas virtuales, federación SPIFFE permite identidad coherente sin VPNs ni bastiones intermedios.
• Compliance evidence engineering — generar la trazabilidad que un auditor de banca, salud o defensa va a pedir. No es escribir un PDF — es instrumentar el sistema para que el reporte se genere solo con datos reales de producción.

El engagement entrega código en tu repo, manifests en tu cluster, runbooks de operación y rotación, y tu equipo operándolo. No entrega slideware ni “estrategia de identidad”.

Para quién es

• Organizaciones en sectores regulados (banca, salud, aeroespacial, defensa, GovTech, energía) donde compliance no es ornamento — Basel III, HIPAA, SOX, CMF chilena, regulación SBIF/CMF, NIST SP 800-204, ISO 27001 son operativas, no aspiracionales.
• Equipos que ya están adoptando agentes IA y reconocen que la identidad criptográfica de cada agente va a ser un requisito en los próximos 18 meses, no algo opcional.
• Platform/security teams con 3-10 personas senior que necesitan capacidad adicional con foco — no contratar 3 mid-level más, sino una intervención senior corta y enfocada en un dominio crítico.

No es

• Implementación de Okta / Entra / Auth0. Esos productos los implementa el vendor o un partner certificado. Esta práctica atiende el plane debajo: workload-to-workload, agent-to-API, cross-cluster trust.
• PKI as a service. No vendemos un servicio SaaS de CA. Construimos PKI dentro de la infraestructura del cliente.
• Auditoría de compliance. Esa la hace un auditor certificado. Lo que sí hacemos es engineerar la evidencia que el auditor va a pedir.
• Sustituto del equipo de seguridad interno. Es un acelerador durante el período de cutover.

Cómo se cruza con el portafolio

• Aether Telemetry — observabilidad semántica del trust plane. Cada SVID emitida, cada attestation, cada handshake mTLS se instrumenta con contexto contractual. Permite responder “qué agente hizo qué” con baja latencia, sin tener que reconstruir el audit log a mano.
• AI Governance LATAM — el playbook que cubre las 4 dimensiones para gobernar agentes IA en producción. Identity es una de las cuatro; este servicio implementa esa dimensión en profundidad.

Cuándo activa

Q3 2026. El servicio depende de tener al menos un ingeniero senior con la combinación específica (criptografía + Kubernetes + compliance operacional) dedicado full-time al engagement. Antes de Q3 2026 la capacidad está comprometida con el lanzamiento del portafolio inicial.

El proceso es: discovery semana (sin costo) → propuesta con scope acotado a un dominio (workload identity O agent identity O PKI modernization, no las tres a la vez) → engagement de 3-6 meses → handoff documentado. Sin retainer obligatorio post-engagement.