Usted repartió el trabajo entre trece agentes. Paperclip no repartió la clave.

Usted hizo lo moderno. En lugar de un único agente grande, montó una flota: uno para clasificar tickets, otro para redactar textos, otro para dirigir el flujo de diseño, una docena de ellos, cada uno con su función y su configuración. Da sensación de mayor seguridad. Un radio de impacto menor. Más mínimo privilegio.

Después, un análisis de seguridad recorrió las configuraciones de un framework de agentes con 71.000 estrellas llamado Paperclip y descubrió que doce de sus trece agentes llevaban las mismas credenciales: un token idéntico, pegado en texto plano en la configuración de cada agente [1]. Una clave de API de Anthropic estaba codificada en duro y en claro en la configuración de un agente de diseño. Un token de bot destinado a un agente podía ser leído por agentes que no tenían nada que ver con él.

Trece puertas. Una sola clave, copiada en doce de ellas. Róbela del agente más débil y tendrá las otras once.

Qué ocurrió realmente

Paperclip asigna a cada agente una configuración de servidor MCP: el archivo que indica al agente a qué herramientas y servicios puede acceder y cómo autenticarse en ellos. En algún momento, los secretos acabaron directamente en esos archivos como texto literal: un JWT de n8n, un token de portador, una clave de API de Anthropic. Sin referencias. Sin inyección en tiempo de ejecución. Escritos a mano y, como levantar el siguiente agente es copiar y pegar, duplicados en toda la flota.

El análisis marcó tres cosas. Los tokens compartidos en texto plano entre doce agentes (clasificados como HIGH). La clave de Anthropic en claro en la configuración de un agente de diseño (clasificada como CRITICAL). Y un token de bot con un ámbito de acceso para el que nunca estuvo destinado: un fallo claro de mínimo privilegio [1]. En su descargo, el equipo de Paperclip reaccionó rápido: migró a referencias de credenciales, aplicó redacción de la configuración en lecturas entre agentes y empezó a imponer la sincronización de vinculación [2]. La dirección correcta.

Esto no es descuido de Paperclip

Merece la pena detenerse en esta parte. Paperclip hizo lo que hace casi todo framework. Poner un secreto en un archivo de configuración es cómo se ha autenticado el software durante treinta años. Funcionaba porque había una aplicación, una configuración y un operador que sabía dónde estaba la clave.

La época cambió bajo ese hábito. Un sistema multiagente no es una aplicación con una configuración: es una docena de procesos, cada uno con un archivo, cada uno copia del anterior. El texto plano en la configuración era un atajo tolerable cuando había un solo lugar por donde pudiera filtrarse. Con trece, ese mismo atajo significa que una filtración son trece filtraciones; y «¿qué agente hizo eso?» no tiene respuesta, porque el token del registro pertenecía a todos ellos.

Las referencias de credenciales, la corrección que publicó Paperclip, son realmente mejores. Pero conviene fijarse en lo que cambian y en lo que no. Una referencia sigue resolviéndose a un secreto real en el lugar donde se ejecuta el agente; el agente, o cualquier cosa que lo comprometa, puede seguir leyendo el valor resuelto. Y el propio gestor de incidencias del framework ya muestra el siguiente modo de fallo: una referencia que se desincroniza de su vinculación, de modo que la configuración parece rellenada mientras la validación falla en silencio [3]. El secreto se movió una capa hacia atrás. No salió del edificio.

No es solo Paperclip

La misma semana, la misma causa raíz, repositorios distintos. Se registró una incidencia en un agente de programación muy utilizado por imprimir valores crudos de .env —contraseñas, tokens, claves de API— directamente en su salida de chat. Se descubrió que otro ejecutor de agentes pasaba todo el entorno del proceso padre a los subprocesos, de modo que cada clave de proveedor era visible para un proceso hijo [4]. Un hook de voz escribía transcripciones, credenciales incluidas, en un /tmp legible por todos [5]. Equipos independientes, modelos de amenaza independientes, una suposición compartida: que no pasa nada porque el secreto viva donde el agente puede verlo. Todo el argumento que tiene que hacer un atacante es que sí pasa.

Diseñado para esto, de forma deliberada

Clavitor parte de la suposición contraria: el agente nunca posee la credencial. Solicita una acción; la petición se intercepta, se autentica contra un secreto que el agente no puede leer y se ejecuta. No hay configuración en la que pegar un token, porque no hay token en la configuración. Nada que copiar en trece agentes, porque el entorno del agente nunca contiene lo que merece la pena robar.

Cada agente solo alcanza aquello para lo que fue nombrado, no todo el almacén, de modo que un token de bot no puede acabar siendo legible por un agente que nunca lo pidió. Y cada acción queda registrada a nombre del actor concreto que la realizó, nunca de un token compartido que doce agentes tenían en común: así «¿cuál de ellos hizo eso?» tiene respuesta.

El límite honesto: esto no hace que un agente sea inhackeable. Un agente comprometido puede seguir haciendo, en el momento, las cosas para las que estaba autorizado. Lo que no puede hacer es largarse con la clave y convertirse en los otros doce, porque no hay ninguna clave en sus manos que llevarse.

La lección no es «rotar el token»

Paperclip rotará los tokens, terminará la migración y cerrará las incidencias. Bien, así debe ser. Pero la rotación no es la lección. La lección es que, en cuanto tiene una flota de agentes en lugar de una aplicación, «el secreto vive en la configuración» deja de ser un atajo y se convierte en un multiplicador. Un multiplicador no se corrige haciendo el secreto un poco más difícil de leer. Se corrige asegurándose de que el secreto nunca estuvo en manos del agente.

Hemos escrito las reglas que, según nosotros, debería cumplir una herramienta de credenciales en la era de los agentes: entre ellas, que el secreto nunca viva donde se ejecuta el código y que un agente solo alcance aquello para lo que fue nombrado. Contraste las suyas con ellas: clavitor.ai/rules.

Clavitor (@clavitorai) es la bóveda de credenciales creada para agentes de IA, y contra ellos. clavitor.ai

Fuentes

[1] Framework de agentes Paperclip — hallazgos sobre higiene de credenciales (CFG-H1 tokens compartidos en texto plano, CFG-C1 clave de Anthropic codificada en duro, CFG-H2 token de bot con ámbito incorrecto): https://github.com/paperclipai/paperclip

[2] Paperclip — imponer la sincronización de vinculación de secretos del agente en los flujos del ciclo de vida (integrado): https://github.com/paperclipai/paperclip/pull/8307

[3] Paperclip — las entradas de entorno secret_ref pueden desincronizarse de las filas de secret_bindings; la configuración aparece rellenada pero la validación falla en silencio (#8309): https://github.com/paperclipai/paperclip/issues/8309

[4] Chetter — runBatchAgent hereda todo el entorno del ejecutor, exponiendo las claves de API del proveedor al subproceso (#56): https://github.com/flatout-works/chetter/issues/56

[5] Hook de voz de Claude Code — transcripciones completas (credenciales incluidas) escritas en un /tmp legible por todos (#58): https://github.com/rodlaneedu-hash/claude-code-voice-hook/issues/58