Todo el sector acaba de aceptar que su agente no debería ver sus claves. Y las están ocultando en el lugar equivocado.

Esta semana Anthropic publicó una línea discreta en el registro de cambios de Claude Code: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. En términos sencillos: cuando Claude Code se ejecutaba en modo headless (como ocurre en CI y en las canalizaciones automatizadas de agentes), las herramientas de autenticación que deberían haber permanecido ocultas se exponían al modelo: la IA podía ver los nombres de las herramientas de autenticación, sus parámetros e, incluso, interactuar con ellas. En el agente de programación más usado del mundo —133k estrellas— la capa de credenciales se filtraba hacia el último lugar donde la querría: el propio contexto del modelo.

Se corrigió. Pero la corrección es la noticia pequeña. La grande es por qué todo harness de agentes que se tome en serio está librando de repente la misma batalla.

Tres harness, una semana, el mismo instinto

Mire lo que se publicó en una única ventana de 24 horas:

• Claude Code corrigió la fuga del auth-stub descrita más arriba y reforzó la verificación de autenticación en MCP [1].
• Hermes (v0.17.0) incorporó «Managed Scope»: secretos fijados por el administrador e inmutables para el usuario, bloqueados en el sistema de archivos de modo que el operador del agente no pueda sobrescribirlos; además, redacción de secretos en las volcados de depuración y bloqueo de configuraciones MCP con forma de exfiltración antes de que se lancen [2].
• Codex (v0.141.0) envolvió el tráfico de ejecución remota en canales Noise cifrados y empezó a enrutar los plugins según su modo de autenticación [3].

Tres rivales, tres enfoques, una conclusión compartida: el harness debe ser propietario de los secretos, y el agente nunca debe ver las claves en bruto. Cuando los competidores convergen así en la misma semana, no es una moda. Es una categoría que por fin admite para qué sirve.

El siguiente problema es la dispersión de credenciales

Ahí está el problema. Cada una de esas correcciones vive dentro del harness. Y el fallo de Claude Code lo delata: cuando la autenticación vive en el harness, justo al lado del modelo, «el agente nunca debe verla» deja de ser un hecho y se convierte en una propiedad que hay que seguir diseñando y en la que, de vez en cuando, se falla —en modo headless, donde nadie está mirando—. No basta con declararla una vez. Hay que defenderla, versión tras versión.

Pero el problema de fondo no es una fuga concreta: es lo que ocurre cuando cada harness, cada proveedor y cada caso de uso publica su propia solución. Acaba con una bóveda dentro de Claude Code, otra dentro de Hermes, otra dentro de Codex, un grupo de OAuth por aquí, un archivo de secretos por allá: un almacén de credenciales separado por cada herramienta que ejecuta. Eso es dispersión de credenciales, y es el siguiente problema, no uno resuelto.

La dispersión es el fallo aunque ningún silo se filtre. Sus secretos se copian en cada uno para que funcione: más copias, más lugares de donde robarlas. La rotación debe hacerse N veces, a mano, y la que olvide es la que le quema. Y nadie puede responder a la única pregunta que de verdad importa: qué agente usó qué clave, contra qué, cuándo, porque la respuesta está repartida entre una docena de almacenes que no se hablan entre sí. No puede levantar una bóveda nueva para cada proveedor y cada flujo de trabajo. Eso no escala. Es justo lo que se rompe.

Las claves no pertenecen al harness en absoluto

La corrección que nunca tendrá que publicar es aquella en la que el agente no llega a tener la autenticación en ningún momento. Coloque las credenciales en una autoridad que esté fuera de todo harness: no una bóveda por proveedor, sino una por debajo de todas ellas. El agente —en Claude Code, en Codex, en Hermes, da igual— solicita una acción con nombre y recibe una credencial acotada y efímera inyectada exactamente para esa acción, obtenida en vivo y desaparecida después. No hay ningún auth-stub en el contexto del modelo que pueda exponerse por accidente, porque la autenticación nunca estuvo en el harness. No hay dispersión, porque hay un almacén en lugar de uno por herramienta: rote una vez, no N. Y cada acceso queda en una única pista de auditoría en vez de dispersarse entre una docena de silos incapaces de responder quién usó qué. (Mantener el secreto fuera del lugar donde se ejecuta el código está casi en lo alto de las reglas que debería cumplir una herramienta de credenciales — el sector acaba de pasar una semana descubriéndolo.)

Y esta es la parte que constituye un límite de seguridad, no una comodidad: la credencial no puede vivir en el mismo sistema que el agente. Si los coloca juntos, comparten un radio de impacto: una inyección de prompt, un servidor MCP envenenado, un volcado de depuración compartido, el próximo fallo de auth-stub, y lo que alcance al agente alcanzará consigo las claves. Por eso la visibilidad es ya la brecha: en el momento en que un secreto cae en un lugar donde el agente puede verlo, debe tratarlo como filtrado y rotarlo, tal como todo equipo cuidadoso trató aquel auth-stub de Claude Code el día en que se publicó. Mantenga la credencial a distancia de brazo, en un sistema al que el agente solo puede pedir —nunca leer, nunca poseer— y un agente totalmente comprometido seguirá sin poder exfiltrar lo que nunca estuvo a su alcance. Puede solicitar una acción. No puede irse con la clave. La distancia es la defensa; una bóveda en proceso no la tiene a ningún precio.

Esa es la línea que traza Clavitor. Todo el campo acaba de demostrar el principio: el agente no debería ver las claves. Simplemente no creemos que tenga que volver a demostrarlo dentro de cada harness que ejecuta, ni que lo que guarda sus claves deba ser lo mismo que un atacante acaba de comprometer.

Reconozcamos el mérito a los equipos de harness: secretos fijados por el administrador, repetidores cifrados y valores predeterminados que fallan cerrado son ingeniería real y buena. Pero una corrección semanal para una fuga que reaparece sin cesar no es una arquitectura: es un síntoma. La arquitectura consiste en que las claves no estén ahí para filtrarse.

Cuando tres competidores parchean la misma herida en la misma semana, la herida es el diseño. El agente no debería ver sus claves: así que deje de guardarlas donde puede verlas.

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

Fuentes

[1] Claude Code v2.1.183 — «Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode» — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (secretos fijados por el administrador), redacción de secretos, bloqueo de configuraciones de exfiltración — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — canales de repetición Noise cifrados, enrutado de plugins por modo de autenticación — https://github.com/openai/codex/releases