Secretos para flotas de agentes: credenciales de vida corta, mínimo privilegio y nunca en el prompt

Desde el punto de vista de la seguridad, un agente de IA es un programa que decide en runtime qué hacer con tus credenciales. Ahí está el problema entero, en una sola frase. Cuando tenías un cron que llamaba a una sola API, podías dejar la key hardcodeada y olvidarte. Una flota de agentes es otra historia: muchos procesos, cada uno razonando sobre texto que no controlas del todo, cada uno capaz de llamar herramientas y soltar logs. Cuando termines de leer vas a tener un modelo concreto para que un secreto filtrado quede en algo pequeño, de vida corta, acotado, auditable, y una idea honesta de cuándo toda esta maquinaria realmente vale la pena.

El escenario que más me preocupa es ese en que la primera inyección de prompt o una línea de log perdida termina comprometiendo la cuenta completa. Por eso existe Infuse, nuestro gestor de secretos de API. Abajo te dejo los patrones que de verdad aguantan con una flota encima, más las concesiones de las que nadie habla.

01 · Por qué una flota rompe las reglas de siempre

Un solo script es un sistema cerrado. Lo escribiste tú, sabes a qué llama, y la única entrada no confiable es, a lo sumo, un payload de webhook que validas en la puerta. Puedes dejar la key hardcodeada, restringir los permisos del archivo y tener todo el flujo en la cabeza.

Un agente rompe cada una de esas suposiciones. El "camino de ejecución" lo decide en runtime un modelo razonando sobre texto, y parte de ese texto viene de afuera: una página extraída de la web, un correo, el resultado de una herramienta, un mensaje del usuario. Ese texto puede traer instrucciones. El agente no tiene una separación limpia entre datos y código como la tiene tu script; para un modelo de lenguaje, los datos son el código.

Ahora multiplica eso por una flota. Tienes un agente de investigación, uno de facturación, uno de operaciones, quizás un enjambre entero conectado entre sí. Cada uno toca secretos. Cada uno genera logs. A cada uno lo puedes desviar, aunque sea un poco, con lo que caiga en su ventana de contexto.

Si manejas los secretos de la flota como manejabas el cron, una key estática, compartida, eterna, estás a una sola instrucción inyectada con maña de que esa key haga todo lo que puede hacer, en cada sistema que alcance. El resto de este artículo va de achicar el tamaño de ese "todo" y de ese "cada sistema".

02 · Nunca metas una key en el prompt

Esta es la regla que se rompe primero, casi siempre sin querer. Alguien mete una API key en el system prompt para que el agente "tenga lo que necesita". Parece inofensivo. No lo es. Ese secreto ahora vive en:

• Los logs de requests del proveedor del modelo.
• Tu propio historial de conversación, que casi siempre termina en una base de datos.
• Cualquier herramienta de trazas u observabilidad que tengas conectada.
• La ventana de contexto misma, donde una instrucción inyectada con maña puede pedirle al modelo que la repita tal cual.

El arreglo es estructural, no un recordatorio. Un recordatorio ("no metas keys en los prompts") falla en el momento en que alguien anda apurado. La estructura significa que el agente no puede ver una credencial en crudo, porque ninguna llega nunca a su contexto.

La frontera del handle de herramienta

El agente ve handles de herramientas: schemas sin ningún secreto adentro. Cuando decide llamar a la API de pagos, emite un tool call. Tu runtime, fuera del modelo, resuelve la credencial y hace el request. El modelo recibe el resultado, nunca la key.

// El modelo ve esta herramienta. No tiene ningún secreto dentro.
const sendInvoice = {
  name: "send_invoice",
  description: "Envía una factura a un cliente por id",
  input_schema: {
    type: "object",
    properties: { customerId: { type: "string" }, amountCents: { type: "integer" } },
    required: ["customerId", "amountCents"],
  },
}

// El secreto se resuelve aquí, en TU código, después de que el modelo lo pide.
async function runSendInvoice(args, ctx) {
  const cred = await vault.lease({
    agent: ctx.agentId,
    scope: "billing:invoice.write",
    ttlSeconds: 300,
  })
  return billingClient.sendInvoice(args, cred.token)
}

El modelo produjo la intención. Tu código produjo el efecto. La credencial nunca cruzó la frontera del lenguaje, así que ninguna inyección de prompt puede sacar algo que el modelo nunca tuvo. Este es el cambio con mayor retorno que puedes hacer, y casi no cuesta nada una vez que tu capa de herramientas es el lugar donde viven las credenciales.

03 · De vida corta, acotada, por agente

Una key estática carga poder ilimitado hasta que alguien se entera de que se filtró. Reemplázala por credenciales débiles a propósito: tres propiedades que solo sirven de verdad cuando van juntas.

• De vida corta. Saca un lease por lo que dura una sola tarea, medido en minutos. Para cuando alguien pudiera aprovechar un token de cinco minutos filtrado, ya no le sirve de nada.
• Acotada. El token del snippet de arriba puede escribir un tipo de factura. No puede leer la tabla de clientes, no puede emitir reembolsos, no puede tocar otro servicio. El alcance es el radio de daño, puesto por escrito.
• Por agente. El agente de investigación y el de facturación tienen identidades distintas. Cuando algo se porta mal, sabes cuál agente fue y puedes revocar solo ese, sin tumbar la flota entera.

Por qué la combinación es lo que importa

La combinación pesa más que cualquier propiedad por separado:

1. De vida corta pero sin acotar: un token robado puede hacer de todo, durante cinco minutos. Siguen siendo cinco minutos feos si ese "de todo" incluye mover dinero.
2. Acotada pero eterna: una key estrecha que nunca muere, acumulando exposición en silencio dentro de logs y backups durante años.
3. Por agente pero amplia y eterna: solo te dice con precisión cuál identidad sobredimensionada fue la que abusaron.

Quieres las tres, por identidad. Esa es la diferencia entre un incidente y una línea de log.

En Agent Orchestra, donde conectas muchos agentes en un mismo flujo de forma visual, esta es justo la parte fácil de hacer mal. Un nodo que "solo necesita leer una hoja" termina con la misma credencial amplia que el nodo que mueve dinero, porque era un clic menos de trabajo. El diseño correcto logra que pedir exactamente el alcance que necesitas sea más fácil que estirar la mano hacia el amplio.

04 · Rotación que no te despierta a las 3am

La rotación es donde mueren las buenas intenciones. El equipo acuerda que las keys deben rotar, pone un recordatorio trimestral y después nunca lo hace, porque rotar rompe cosas, y romper producción un viernes para tachar una casilla no es la idea de diversión de nadie.

Rotar rompe cosas cuando el secreto es un único valor referenciado en todas partes. Lo cambias y cada consumidor que clavó el literal viejo se cae al mismo tiempo. El arreglo es convertir la rotación en un evento normal que el sistema ya da por hecho.

1. Emite credenciales con versión. Los consumidores piden la "actual", no un literal clavado.
2. Cuando rotas, la versión nueva entra en vigor y la vieja pasa a una ventana de gracia en la que ambas son válidas.
3. Los leases de larga vida emitidos con la versión vieja siguen funcionando hasta que expiran solos.
4. Pasada la ventana de gracia, la versión vieja se revoca. Lo que siga usándola ya estaba roto; ahora te enteras, en tu horario, no a las 3am.

Como los agentes sacan leases cortos, la mayoría vuelve a sacar uno en minutos y toma la versión nueva sin que tengas que hacer nada. Rotar deja de ser una migración y se vuelve un martes cualquiera.

Acá la propiedad de vida corta paga un segundo dividendo: la ventana de gracia puede ser corta porque nada retiene una credencial por mucho tiempo. Un sistema montado sobre keys estáticas necesita una ventana de gracia larga y nerviosa. Uno montado sobre leases de cinco minutos casi no necesita ninguna.

05 · Trazas de auditoría que de verdad puedas leer

Tarde o temprano vas a tener que responder una pregunta bajo presión: qué agente usó qué credencial, para hacer qué, y cuándo. Si no puedes responder eso rápido, no tienes seguridad, tienes fe.

La regla es simple: registra el lease, no el secreto. Cada lease guarda la identidad del agente, el alcance solicitado, el id de la tarea o ejecución, y un timestamp. Nunca el valor del token. Ese registro es la llave que une "un agente hizo algo" con "se usó una credencial".

// Una línea estructurada por lease. Sin token dentro.
log.info("vault.lease", {
  agentId: ctx.agentId,
  runId: ctx.runId,
  scope: "billing:invoice.write",
  ttlSeconds: 300,
  ts: new Date().toISOString(),
})

Cuando salta una alerta, esto es lo que te permite acotar el incidente en minutos en vez de adivinar. Filtras por agente, ves exactamente qué alcances tenía y revocas su identidad. El daño ya está limitado por el mínimo privilegio que armaste en la sección 03; la traza de auditoría solo te permite demostrarlo y frenarlo rápido.

Una nota práctica: mantén estas líneas estructuradas y aburridas. La tentación es registrar de más, argumentos completos, payloads, resultados, y así es como los datos de un cliente, o peor, el mismísimo secreto que tanto cuidaste de mantener fuera del prompt, terminan en tu almacén de logs. Registra la metadata del acceso, no el contenido.

06 · Las concesiones, sin maquillaje

Esto es más maquinaria que una sola key en una variable de entorno, y ese costo es real. Fingir lo contrario es justo como terminas armando un gestor de secretos para un script de una sola vez.

• Latencia. Un lease por tarea agrega un ida y vuelta. Cachea dentro de una misma ejecución, nunca entre ejecuciones, y mantén el gestor cerca de los agentes. En nuestro VPS único detrás de Traefik, el gestor es un salto local, así que el overhead son unos pocos milisegundos. Por internet público no sería así: tenerlo todo en el mismo lugar está haciendo trabajo real acá.
• Una dependencia nueva. Si el gestor está caído, los agentes no pueden actuar. Trátalo como una base de datos: tiene que estar tan disponible como lo que protege, con la misma disciplina de backup y failover. Cambiaste un riesgo de filtración por una dependencia de disponibilidad, y por lo general ese cambio vale la pena, pero es un cambio que estás haciendo.
• Complejidad para trabajos chicos. Para un script personal que llama a una API tuya, todo esto es exagerado. Usa una variable de entorno y sigue. Estos patrones se ganan su lugar cuando tienes varios agentes, entrada no confiable, o credenciales que llegan a sistemas que odiarías perder.

Ajusta la ceremonia al radio de daño. El error, en ambas direcciones, es el mismo: tratar todas las credenciales por igual. Una API de clima de solo lectura y la key que mueve dinero no merecen la misma ceremonia, y una flota no merece la misma ceremonia que un cron.

Trata cada credencial que un agente pueda alcanzar como si ya estuviera filtrada, y después haz que eso salga barato. Mantén las keys completamente fuera del prompt, saca leases cortos, acota fino, separa identidades, y haz que rotar y auditar sean cosas aburridas. Si logras eso, un secreto filtrado se vuelve un token de cinco minutos para un alcance en un solo agente: una línea de log, no un incidente. Esa es toda la meta: no evitar cada filtración, sino asegurarte de que ninguna te salga cara.