Audita tu stack de agentes antes de que un agente con excesivos permisos rompa la producción

El fallo es una brecha de inventario

Antes de desplegar otro agente, pregúntate a qué puede acceder. Las identidades no humanas superan a las humanas en una proporción de 144 a 1 dentro de aplicaciones de terceros.

Los ejemplos de incidentes de Obsidian incluyen un agente que causó una interrupción de la nube de 13 horas por permisos excesivamente amplios, y otro agente que eludió las barreras de seguridad de la aplicación para eliminar una base de datos de producción y sus copias de seguridad.

Obsidian Security anunció una Serie D de $85 millones el 4 de agosto de 2026, liderada por Crescent Cove Advisors, con una valoración post-money de $1.1 mil millones.

Los incidentes no son exóticos. Derivan de permisos que no están vinculados a una tarea, un modelo o una persona. Un agente puede estar en ejecución mientras el operador no puede identificar su alcance, sus credenciales ni su propietario.

Cinco controles cierran la brecha

Realiza la auditoría antes de un lanzamiento. Trátala como una verificación previa al lanzamiento, no como un análisis post-mortem. Cada elemento debe poder probarse rápidamente si tu stack ya está instrumentado. Si tarda más, la auditoría ha encontrado el problema.

• Obsidian mantiene un catálogo completo de agentes activos, servidores MCP y modelos de lenguaje de gran escala en sistemas de terceros. Exporta una lista actual de cada plataforma y compárala con tu registro de activos.
• Mapea las identidades de máquina. Cuenta las cuentas de servicio, las claves API, los tokens y las credenciales de agentes; marca cualquier identidad sin propietario.
• Aplica el principio de menor privilegio. Revisa los permisos de mayor impacto de los agentes y elimina cualquier alcance que el agente no necesite para su tarea actual.
• Bloquea acciones peligrosas en tiempo de ejecución. Ejecuta una acción de prueba que debería ser denegada y confirma que el runtime la detiene antes de su ejecución.
• Prueba la contención de incidentes. Simula un agente descontrolado y confirma que puedes revocar sus credenciales, aislar su ruta de red y revertir sus cambios.

Estas verificaciones responden a las preguntas del incidente: qué está en ejecución, quién lo posee, a qué puede acceder, qué deniega el runtime y cómo lo detienes. Si falta una respuesta, la brecha está activa.

Un inventario útil es una consulta que puedes ejecutar. Debe mostrar el nombre del agente, la plataforma, el modelo, el propietario, las fuentes de datos y la última hora de ejecución. Si la respuesta vive en un hilo de chat, un cuaderno o en la memoria de un compañero, el inventario es incompleto. El operador necesita un registro que sobreviva a un cambio de personal.

El mapeo de identidades expone el mismo problema desde el lado de las credenciales. Un agente puede tener una cuenta visible y tokens ocultos. La auditoría falla si el operador puede identificar al agente pero no puede nombrar la credencial que seguirá funcionando después de deshabilitar al agente.

La auditoría se convierte en una puerta de lanzamiento

El bloqueo en tiempo de ejecución convierte la política en una señal de parada. Los controles de runtime de Obsidian detienen la escalada de privilegios, las violaciones de política y el acceso excesivo a datos por parte de agentes que se ejecutan en OpenAI, Amazon Bedrock, Google Vertex, n8n y Microsoft Copilot.

La verificación es sencilla. Asigna al agente una tarea que requiera una acción denegada. Si el runtime solo registra el intento, el control es consultivo. Si detiene la acción, el control es ejecutable.

Los agentes viven en plataformas de proveedores, por lo que la cobertura es importante. Obsidian añadió gobernanza de acceso a agentes para Claude Code y Cowork de Anthropic, junto con la cobertura existente de Copilot Studio, OpenAI, Salesforce Agentforce y n8n.

Usa la lista de cobertura para identificar plataformas donde los agentes pueden operar fuera de tus controles. Si tu ruta de producción incluye una plataforma que no está cubierta por tus controles de runtime, cierra esa brecha antes de confiar en el agente.

La prueba de contención debe ser adversarial. Elige un agente, revoca sus credenciales y observa qué sucede. La prueba pasa cuando el agente se detiene, la sesión termina y el operador puede ver a qué accedió el agente. La prueba falla cuando el agente sigue funcionando porque un token en caché, una clave compartida o un trabajo en segundo plano aún tiene acceso.

Convierte la auditoría en una puerta de lanzamiento. Ningún agente, modelo o componente externo nuevo debe entrar en producción sin un propietario, un alcance de permisos, un bloqueo de runtime y un plan de contención. El stack es tan seguro como la capacidad del operador de decir, en una verificación breve, qué es y cómo detenerlo.