Por qué los agentes en la sombra son una bomba de relojería para la gobernanza

Toda empresa que ha llevado la IA más allá del piloto tiene el mismo problema silencioso: los agentes se multiplican más rápido de lo que nadie puede nombrarlos. Un equipo conecta un modelo a una herramienta para ahorrarse una tarde. Un script recibe una clave de servicio para poder leer un CRM. Seis semanas después, hay software leyendo registros de clientes, llamando a APIs internas y gastando dinero — y nadie puede decir quién es su dueño, qué tiene permitido tocar ni si alguna de sus acciones quedó registrada.

Los llamamos agentes en la sombra. No son maliciosos. Son el resultado natural de una capacidad potente que se encuentra con una organización sin un runtime que la gobierne. Y como cualquier sistema sin supervisión que toca datos reales y ejecuta acciones reales, son una bomba de relojería — el fallo no se ve hasta que sale caro.

Qué hace peligroso a un agente en la sombra

Un agente no es un chatbot. Lee datos, elige herramientas y ejecuta acciones en su nombre — mueve dinero, cambia registros, envía mensajes a clientes. El peligro se acumula en tres ejes que la seguridad de aplicaciones tradicional nunca vigila:

• Sin identidad. El agente se ejecuta con una clave prestada o una cuenta de servicio de alcance amplio, así que no tiene dueño, ni propósito de negocio, ni caducidad, ni nivel de riesgo asociado.
• Sin control de gasto. Nada limita cuántas llamadas a modelos o invocaciones de herramientas puede acumular antes de que alguien note la factura — o el incidente de límite de tasa.
• Sin registro. Cuando actúa, la acción no deja ningún rastro con detección de manipulación. Si un regulador, un auditor o un equipo de respuesta a incidentes pregunta qué hizo y por qué, la respuesta honesta es: no lo sabemos.

Un agente en la sombra es el único empleado que puede mover dinero, leer todos los registros de clientes y actuar mil veces por hora — sin credencial, sin jefe y sin registro de lo que hizo.

La gobernanza es una propiedad del runtime, no un documento de política

El instinto es escribir una política: "todos los agentes deben estar registrados". Pero un PDF no impide que un agente no registrado emita un token a las 2 de la madrugada. La gobernanza solo funciona cuando se aplica en la propia ruta de ejecución — cuando decide el runtime, no un comité, si una acción se ejecuta.

Ese es el principio de diseño detrás de Cortex. Toda acción de un agente atraviesa ocho puertas fail-closed antes de poder llegar a un modelo o a una herramienta. Denegar es lo predeterminado. Un agente sin identidad gobernada nunca obtiene una credencial; uno caducado se detiene antes de ejecutarse con un código real, no con un aviso que pasa de largo en un log:

POST /v1/agent-identities/<id>/tokens
  -> 403 IDENTITY_EXPIRED

# sin identidad gobernada, no hay token.
# sin token, no hay ejecución. denegar es lo predeterminado.

De la proliferación al inventario

Lo primero que da un runtime gobernado es justo lo que un parque en la sombra no puede dar: un inventario. En Cortex, cada agente es una identidad empresarial de primer nivel con un dueño, un departamento, un propósito de negocio, un nivel de riesgo, una caducidad y un conjunto explícito de modelos, herramientas y entornos permitidos. Las identidades se recertifican por ciclos; el Control Tower informa de cuántas existen, cuántas tienen la revisión vencida y cuántas ya han caducado.

Ese inventario no es papeleo — se aplica. Una identidad cuya lista de modelos permitidos excluye un modelo es rechazada en tiempo de ejecución con 403 MODEL_NOT_ALLOWED. Una suspendida no puede ejecutarse. La lista de agentes que puede ver es, por construcción, la lista de agentes que pueden ejecutarse.

Desactívela antes de que estalle

El planteamiento honesto es este: los agentes en la sombra no son un riesgo futuro, son un riesgo presente, y el coste de no hacer nada sube cada semana a medida que aparecen más. No se puede gobernar lo que no se ve, y no se puede demostrar lo que nunca se registró. Un runtime gobernado resuelve ambas cosas en el mismo punto — el momento de la ejecución — dando a cada agente una identidad, un presupuesto, un conjunto de guardrails y un registro con detección de manipulación de todo lo que hizo. Esa es la diferencia entre un parque que se administra y una bomba sobre la que se está sentado.