Hazle una pregunta sencilla a tu responsable de ingeniería. No «¿funciona el agente?», eso lo sabe cualquiera. Pregunta esto: ¿qué credenciales tiene el agente ahora mismo y quién aprobó cada una?
En la mayoría de las empresas, esa pregunta genera un silencio. Luego alguien dice que tendrá que revisarlo. Y al final se descubre que el agente heredó una cuenta de servicio creada hace dieciocho meses para una migración de datos. Se usó porque ya tenía los permisos de escritura que el agente necesitaba y nadie quería abrir un ticket con infraestructura.
No es un escenario hipotético. Es la forma habitual en que los agentes obtienen accesos en empresas reales que trabajan con plazos reales.
Lo interesante no es el incidente. Es a quién le pasó
OpenAI tuvo que revisar hace poco su seguridad interna después de que uno de sus propios agentes se comportara de forma imprevista y afectara a un tercero del ecosistema open source. El detalle forense importa menos que la forma de la respuesta. Se restringieron permisos. Se rotaron credenciales. Se añadió monitorización. Todo ello después del hecho.
Piensa en lo que significa. Hablamos de una organización con más conocimiento sobre modelos que nadie en el planeta. Si el problema hubiera sido la capacidad del modelo, lo habrían detectado. No lo hicieron, porque el problema no era el modelo.
El problema estaba en la capa de abajo. Accesos más amplios de lo que la tarea exigía. Credenciales que sobrevivieron a su propósito. Y ninguna forma limpia de reconstruir qué hizo el agente, en qué orden y con qué autorización.
Llevamos tiempo defendiendo lo mismo: primero estabilizar, después mejorar y al final añadir IA. Resulta más convincente cuando lo demuestra otro. Si pones un agente encima de una base que no entiendes del todo, pagas dos veces: una por el agente y otra por reconstruir la base que tiene debajo.
Si ya has lanzado, ese orden no es un reproche. Es una lista de tareas.
Los agentes fallan en silencio. Ahí está todo el problema
Este es el modelo mental que cambia la forma de ver el asunto.
Una integración rota hace ruido. Devuelve un 500, la cola de reintentos se acumula, alguien recibe una alerta y lo arregla. El fallo se anuncia solo.
Un agente con demasiados accesos no falla. Tiene éxito. Envía correctamente un correo a un segmento que no querías. Actualiza correctamente 4.000 registros en lugar de 40. Cierra correctamente un ticket de compliance que debería haber revisado una persona. Cada línea de log dice 200 OK. Cada métrica parece sana. El sistema hace exactamente lo que se le permitió hacer.
Te enteras semanas después, por un cliente.
Por eso la monitorización habitual sirve de poco aquí. Tasas de error, percentiles de latencia, disponibilidad: nada de eso detecta una acción autorizada ejecutada por el motivo equivocado. Tus paneles miden si la máquina funciona. No miden si acertó.
Y los equipos más expuestos son los que van más adelantados. Si tienes agentes ejecutando flujos de onboarding, revisión de compliance o procesos de contratación, has entregado las llaves de esos procesos a un sistema probabilístico. Son justo los ámbitos donde equivocarse con seguridad sale caro. Y donde un fallo silencioso puede sobrevivir un trimestre entero antes de que alguien lo note.
Las tres cosas que nadie auditó
Casi todos los incidentes con agentes se explican por alguna de estas. Normalmente por las tres.
Permisos heredados en lugar de concedidos. Los agentes se construyen rápido, a menudo por un solo ingeniero que necesitaba acceso para avanzar. El camino más corto es reutilizar una cuenta de servicio existente con permisos generosos. Nadie lo documenta porque nadie tomó una decisión digna de documentar. Reutilizaron una clave.
Credenciales sin caducidad y sin dueño. El acceso humano tiene un ciclo de vida natural. La gente entra, se incorpora, se va y se le retiran los accesos. El acceso de máquina no tiene ese ritmo. Un token emitido en marzo para un prototipo sigue siendo válido en diciembre, sigue teniendo permiso de escritura y ya no pertenece a nadie.
Falta de trazabilidad. Esta es la que convierte un incidente en una crisis. Cuando algo va mal, necesitas responder rápido a tres preguntas: qué hizo, qué entrada le llevó a decidir eso y qué lo habría detenido. Si tus logs solo guardan el resultado, sin la cadena de razonamiento ni las llamadas a herramientas, no puedes responder a ninguna. Estarás adivinando delante de un consejo.
Fíjate en que ninguno de estos es un problema de IA. Son problemas de gestión de accesos que la IA volvió urgentes. Los agentes simplemente ejecutan miles de operaciones por hora sin cansarse y sin preguntar a un compañero si aquello tiene sentido.
La parte incómoda: «human in the loop» no es un control de seguridad
El consejo estándar es mantener a una persona aprobando las acciones del agente. Suena responsable. En producción se degrada en menos de un mes.
Una persona que revisa 400 decisiones al día no revisa nada. Pulsa «aprobar». No es un defecto de carácter, es cómo funciona la atención. El paso de aprobación se convierte en teatro. Y lo que es peor: crea un registro falso, porque cada acción lleva ahora un nombre humano al lado y eso hace que el rastro de auditoría engañe.
La revisión humana funciona cuando es poco frecuente y relevante. Diez decisiones al día, cada una realmente distinta. No funciona como red de seguridad general.
El control que de verdad aguanta es arquitectónico. Limita lo que el agente puede hacer, para que los casos en los que se equivoque sean soportables aunque nadie los detecte a tiempo. El alcance vence a la supervisión.
Qué construir en su lugar
Dale al agente capacidades, no credenciales
El agente nunca debería tener una clave de larga duración. Debería pedir a un intermediario permiso para ejecutar una acción concreta y recibir algo estrecho y de vida corta.
// The agent never sees the database URL or the API key. // It asks for a capability, scoped to one task, that expires. type Capability = { action: "email.send" | "record.update" | "ticket.close"; scope: { resource: string; maxItems: number }; taskId: string; // ties every use back to one unit of work expiresAt: number; // minutes, not months }; async function requestCapability( agentId: string, action: Capability["action"], scope: Capability["scope"], taskId: string ): Promise<Capability> { const policy = await policyFor(agentId, action); if (!policy.allowed) throw new PolicyDenied(agentId, action); if (scope.maxItems > policy.maxItems) { throw new PolicyDenied(agentId, `${action}: batch too large`); } return issue({ action, scope, taskId, expiresAt: Date.now() + 5 * 60_000 }); }
Este diseño te regala dos cosas. El radio de impacto queda limitado por maxItems, así que el fallo de «40 registros se convirtieron en 4.000» pasa de improbable a imposible. Y cada acción lleva un taskId, que es lo que hace posible la siguiente sección.
Que el registro de herramientas deniegue por defecto
La mayoría de los frameworks de agentes te permiten registrar herramientas y pasárselas todas al modelo. Eso significa que añadir una herramienta para un flujo concreto la habilita en silencio para todos los flujos. La superficie de permisos crece cada sprint y nadie la revisa.
Invierte la lógica. Cada herramienta se declara con los permisos que necesita y cada rol de agente recibe una lista explícita de lo permitido.
const TOOLS = { "crm.readContact": { scopes: ["crm:read"], reversible: true }, "crm.updateContact": { scopes: ["crm:write"], reversible: false }, "email.sendBulk": { scopes: ["email:send"], reversible: false }, } as const; const ROLE_ALLOWLIST: Record<string, (keyof typeof TOOLS)[]> = { "onboarding-agent": ["crm.readContact", "crm.updateContact"], "support-triage": ["crm.readContact"], }; // Irreversible tools require an explicit, per-role opt-in. // Adding a tool is a code change, reviewed like any other.
Ese indicador reversible importa más de lo que parece. Clasifica las acciones del agente en las que puedes deshacer y las que no. Equivocarse en lecturas y borradores es barato. Enviar dinero, escribir a clientes o borrar cualquier cosa, no. Cada clase merece controles distintos. Tratarlas igual es lo que lleva a un proceso de revisión demasiado pesado para las lecturas y demasiado ligero para los pagos.
Registra la decisión, no solo el resultado
Los logs de aplicación registran lo que ocurrió. Con agentes necesitas también lo que se consideró.
{ "task_id": "onb_9f2c", "agent": "onboarding-agent", "step": 4, "model": "gpt-x-2026-07", "input_digest": "sha256:8c1a…", "retrieved_context": ["doc:policy_uae_v3", "record:emp_2291"], "tool_call": { "name": "crm.updateContact", "args_digest": "sha256:44b9…" }, "capability": { "action": "record.update", "maxItems": 1, "expires_at": 1786…}, "outcome": "applied", "reverted_by": null }
Solo escritura, sin ediciones. Conservado. Consultable por task_id. La prueba para saber si tu registro es suficiente es simple: ¿puedes reconstruir una tarea completa del agente, de principio a fin, solo con el log, seis semanas después? Si la respuesta implica abrir el panel del proveedor del modelo y leer prompts en crudo, no tienes un rastro de auditoría. Tienes migajas.
Esta es la versión práctica del argumento de Tu agente de IA no leyó el manual. Una política escrita en una página de Notion es un deseo. Una política escrita como comprobación de capacidades es un control.
Da por hecho que la ventana de contexto es una vía de ataque
Un agente que lee tu código, tu sistema de tickets o tu bandeja de entrada está ejecutando instrucciones escritas por gente que no sabe que está escribiendo instrucciones. Un ticket de soporte puede contener texto que el modelo interprete como una orden. También un README. También un mensaje de commit.
Esto no se resuelve del todo con ingeniería de prompts. Lo que sí puedes hacer es limitar el daño: asegúrate de que los permisos del agente no vayan más allá de lo que exige la tarea. Es la misma disciplina de todo lo anterior. Ya tratamos la parte de acceso de lectura en Muse Code de Meta puede leer todo tu código, y la lógica vale para cualquier herramienta con alcance amplio sobre sistemas que no has saneado.
La prueba que no te cuesta nada
Antes de encargar nada, haz esto. Te llevará una tarde.
Enumera todas las credenciales que tienen tus agentes ahora mismo. No las del documento de diseño: las que están vivas en producción. Para cada una, apunta tres cosas: qué permite, cuándo se emitió y el nombre de quien la aprobó.
Después mira el resultado. Si alguna fila no tiene dueño, es un hallazgo. Si alguna credencial es más antigua que el agente que la usa, es un hallazgo. Si el alcance es más amplio que la tarea más pequeña que ejecuta el agente, es un hallazgo. Y si la sala se queda en silencio cuando preguntas quién aprobó una clave concreta, has encontrado lo más importante de la lista.
Para ese ejercicio no necesitas consultores. Hazlo sin nosotros.
Lo que aporta una revisión de madurez en serio es lo que viene después: si tu trazabilidad aguantaría las preguntas de un regulador, qué fallos son reversibles y cuáles no, y en qué orden arreglar las cosas para no reconstruir el agente dos veces.
La lección del retrofit de OpenAI no es que los agentes sean peligrosos. Es que el riesgo de los agentes vive por debajo del modelo: en los permisos, las credenciales y los logs. La capa menos vistosa del stack y la primera que se salta cuando la demo es el viernes. Los equipos que despliegan agentes con seguridad no son los que tienen mejores prompts. Son los que decidieron qué podía romper el agente antes de darle las llaves.
Reserva una Auditoría Gratuita
