Turnkey lanza Managed Secrets para que los agentes de IA accedan a credenciales

Turnkey ha lanzado Managed Secrets, una solución que amplía su infraestructura de monederos basada en enclaves para incluir las claves de API, las contraseñas, los datos de pago y la información de recuperación que las aplicaciones y los agentes de IA necesitan para funcionar. El anuncio del 29 de octubre marca la expansión de la empresa más allá de la gestión de claves privadas, hacia un problema más amplio: permitir que el software actúe sin dispersar credenciales reutilizables por toda su infraestructura.

El producto permite a los equipos decidir qué servicio puede recuperar una credencial y si esa solicitud requiere la aprobación de una persona o de varias partes. En las aplicaciones financieras, esto podría consistir en entregar una clave de API de un exchange a un sistema autorizado de operaciones, sin que quede expuesta en la conversación de un asistente de IA ni en su entorno de ejecución.

Trasladar el acceso a las credenciales a un entorno de ejecución seguro

Las credenciales almacenadas en variables de entorno o archivos de configuración son fáciles de usar para el software, pero un ataque al proceso que las lee puede dejar su contenido al descubierto. Un sistema de gestión de secretos puede centralizar el almacenamiento y los controles de acceso; la cuestión pendiente es dónde se vuelve legible una credencial y en qué sistemas hay que confiar en ese momento.

Managed Secrets realiza las comprobaciones de autorización dentro de los entornos de ejecución seguros de Turnkey. Antes de importar un secreto, el cliente lo cifra y, después, el entorno de ejecución seguro vuelve a cifrarlo para almacenarlo. Cuando llega una solicitud, dicho entorno evalúa las políticas y aprobaciones pertinentes antes de cifrar el resultado con la clave del destinatario previsto. El solicitante y el destinatario pueden ser servicios distintos.

Esa separación es importante. Una aplicación puede iniciar una tarea y reunir las aprobaciones sin adquirir la capacidad de descifrar la credencial necesaria para completarla. La firma de una persona autorizante permite liberar el secreto, pero no concede automáticamente acceso al secreto liberado.

La criptografía que protege la importación y la exportación

La documentación del canal seguro de Turnkey describe un protocolo basado en el cifrado híbrido de clave pública, o HPKE. Este combina el acuerdo de claves mediante clave pública con el cifrado autenticado, de modo que la información confidencial puede atravesar sistemas intermediarios en forma de texto cifrado. Durante la importación, el cliente verifica el material de clave firmado por el entorno de ejecución seguro; durante la exportación, cifra la información con una clave pública incluida en la solicitud firmada.

Las claves de los destinatarios están concebidas para usarse una sola vez. Turnkey señala que los clientes deben respetar esa regla por su cuenta: el protocolo no puede impedir que un cliente defectuoso reutilice la clave de destino. Por eso, la implementación del cliente forma parte del modelo de seguridad, junto con el entorno de ejecución seguro.

La página del producto Managed Secrets especifica el cifrado AES-256-GCM de cada secreto cuando está almacenado. Su API admite tanto credenciales individuales como solicitudes de varios secretos. Las exportaciones por lotes se rechazan en su totalidad si alguno de los secretos solicitados no cuenta con autorización, lo que impide liberar un conjunto aprobado solo parcialmente.

Por qué sigue siendo importante el destinatario

La expresión «los agentes pueden usar credenciales sin verlas» describe un patrón de integración, no garantiza que todos los procesos receptores sean incapaces de leer el texto sin cifrar. La documentación para desarrolladores de Turnkey indica explícitamente que puede haber texto sin cifrar dentro del entorno de ejecución seguro y en el cliente que importa o exporta un secreto.

Si un servicio de ejecución independiente tiene la clave del destinatario, puede descifrar y usar una credencial sin que esta quede al alcance del modelo. Si la clave está en el entorno de ejecución del propio agente, ese entorno puede descifrarla. Por tanto, sigue siendo necesario proteger al destinatario, su memoria y sus registros.

Existe un segundo límite: las políticas pueden examinar el contexto de una solicitud, como el dominio de pago declarado, pero Turnkey no verifica de forma independiente que esa declaración sea cierta. Una declaración firmada permite establecer quién la hizo. Las aplicaciones siguen necesitando comprobaciones fiables que vinculen esa declaración con la operación real.

Aprobaciones que pueden adaptarse a la evolución de un flujo de trabajo

Los equipos pueden permitir la recuperación directa, exigir que una persona apruebe una solicitud o requerir el acuerdo de varios roles de agente. Las políticas pueden cambiar sin necesidad de volver a importar el secreto subyacente, lo que permite iniciar un flujo de trabajo con supervisión estricta y automatizar más adelante determinadas solicitudes.

La guía de acceso programable de Turnkey muestra a un agente de navegador y a un agente de pagos que firman conjuntamente una solicitud. Solo el agente de pagos recibe los datos de la tarjeta en un formato que puede descifrar. Antes de aprobarla, el componente del navegador comprueba que el dominio propuesto coincida con el de la página que está utilizando. El ejemplo muestra por qué la independencia de los roles y la validación importan más que limitarse a contar dos aprobaciones.

Los roles de agente pueden usar credenciales de sesión con permisos limitados y caducidad, lo que permite a los operadores revocar una instancia en ejecución. Sin embargo, revocar el acceso futuro no puede borrar un secreto que el destinatario ya haya descifrado; la rotación posterior de las credenciales sigue siendo una medida operativa independiente.

De la infraestructura de monederos a la automatización financiera

La arquitectura de seguridad actual de Turnkey utiliza AWS Nitro Enclaves y combina el aislamiento por hardware con compilaciones reproducibles y atestación remota. La reproducibilidad permite comparar las compilaciones de software, mientras que la atestación aporta pruebas sobre el código que se ejecuta en el enclave. Managed Secrets aplica esa base a credenciales que van más allá de las claves de firma de blockchain.

La empresa identifica a las firmas de negociación, los sistemas backend de tecnología financiera, los desarrolladores de agentes de IA y los custodios de MPC como usuarios previstos. Las credenciales de los exchanges y los tokens de OAuth permiten mantener el acceso a los servicios; las copias de seguridad de las participaciones de clave y las claves de recuperación contribuyen a la resiliencia. Se trata de usos distintos, con diferentes requisitos de aprobación y destinatarios, aunque compartan la infraestructura de almacenamiento.

Para los equipos de tecnología financiera, la importancia radica en establecer una división más clara entre solicitar una acción, autorizar el acceso y recibir una credencial utilizable. Managed Secrets proporciona la infraestructura necesaria para esa división. La protección resultante depende de políticas estrictas, aprobadores fiables y un servicio bien protegido que, en última instancia, utiliza el secreto.