Obsidian Security frena a los agentes de IA antes de actuar

Obsidian Security pone el control donde antes no había nada

Un agente de IA puede tener credenciales válidas, usar una herramienta aprobada y aun así ejecutar una acción que le cueste millones a la empresa. Esa frase, de Hasan Imam, CEO de Obsidian Security, resume el hueco que la compañía intenta cerrar con su nuevo Runtime Policy Decision Engine, presentado el 10 de noviembre de 2026 y difundido en un comunicado reproducido por Business Wire.

La propuesta es concreta: evaluar cada acción que un agente quiere ejecutar en una aplicación empresarial antes de que ocurra, y decidir si se permite, se bloquea o se somete a aprobación humana. Para un founder que ya tiene agentes tocando datos de clientes en producción, la pregunta deja de ser teórica y pasa a ser operativa: ¿sabes qué puede hacer tu agente hoy, más allá de a qué puede entrar?

¿Por qué el control de accesos tradicional ya no alcanza?

Los sistemas de gestión de identidad responden una pregunta binaria: si una persona o una cuenta puede entrar a un sistema y consultar determinados recursos. El problema aparece cuando un agente opera con esos mismos permisos pero con un criterio distinto al humano que los originó.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La propia compañía describe el escenario: exportar registros de clientes a un destino externo o ejecutar un cambio destructivo en medio de una tarea rutinaria. Ninguna de esas dos acciones requiere credenciales robadas. Ocurren dentro de la sesión legítima de un agente autorizado.

Obsidian plantea la distinción en términos que cualquier equipo de producto entiende: una cosa es tener permiso para leer información y otra muy distinta es tener autorización para moverla, modificarla o compartirla. Los modelos de permisos heredados de la era SaaS no separan esas dos cosas con suficiente granularidad.

¿Cómo decide el motor si una acción pasa o se detiene?

El sistema no evalúa la solicitud aislada. Cruza la acción propuesta con políticas centralizadas y con contexto sobre quién está detrás del agente, su situación laboral, los permisos que tiene en la aplicación de destino y las clasificaciones de datos que definió el propio cliente.

La pieza que sostiene ese contexto es una arquitectura que la empresa llama Knowledge Graph, que relaciona personas, cuentas, aplicaciones, tokens y derechos de acceso en un modelo único, con relaciones que registran cambios en el tiempo. Ese enfoque permite detectar algo que una revisión cuenta por cuenta no ve: un token o un derecho heredado que le abre al agente recursos que su rol aparente no justifica.

Hay un detalle que conviene subrayar: la calidad de la decisión depende de la calidad del contexto. Si tu organización no etiquetó qué datos son sensibles, el motor no puede distinguir un archivo ordinario de un expediente crítico. La política es tan buena como la clasificación que la alimenta.

Policy Decision API y MCP Security Proxy: dónde se aplica la decisión

La arquitectura separa dos cosas que suelen confundirse: decidir y ejecutar. Un punto de aplicación pausa la operación, envía los detalles para evaluación y recibe un veredicto con su razón. Después, el componente conectado deja pasar la acción o la detiene.

La Policy Decision API extiende ese esquema a pasarelas administradas por el cliente, entornos de ejecución de agentes y flujos de trabajo propios. Es decir, una empresa puede conservar su infraestructura y pedirle a Obsidian una decisión contextual, siempre que el componente local aplique el veredicto antes de que la operación avance. Si ese punto de aplicación no existe, la política no se ejecuta.

El MCP Security Proxy opera en otra capa. Se coloca entre los clientes de IA y las aplicaciones empresariales que exponen herramientas vía Model Context Protocol, de modo que el cliente no se conecta al servidor MCP de la aplicación sino a un punto de acceso gobernado. El diseño también busca que el cliente de IA no almacene directamente el token de la aplicación: el usuario autoriza por el flujo de consentimiento del proveedor y recibe un token emitido por el proxy, vinculado a su cuenta y a su espacio de trabajo.

La compañía aclara un punto importante para cualquier equipo de seguridad: el proxy revisa llamadas y registra si las permite o bloquea, pero opera dentro de los permisos existentes de la persona. No añade privilegios mediante una cuenta de servicio compartida.

¿Qué cubre realmente y dónde están los límites?

Aquí está la parte que un comprador debe leer dos veces. El anuncio amplía descubrimiento y gobernanza para Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow y Workday, y suma política en tiempo de ejecución para OpenAI Codex, junto a controles ya existentes para herramientas de codificación.

Pero descubrir un agente dentro de una aplicación no equivale a interceptar todas sus acciones en tiempo de ejecución. Son tres capacidades distintas: el descubrimiento dice qué herramientas existen y a qué pueden acceder; la gobernanza reduce permisos innecesarios o revela configuraciones riesgosas; la política en tiempo de ejecución decide qué debería poder hacer un agente autorizado en un momento concreto.

La aprobación humana tiene alcance aún más acotado. Según la documentación de la compañía, está disponible para políticas de Claude Code que se ejecutan antes de una operación. Quien combine varios agentes tiene que verificar integración por integración qué controles admite cada una, en lugar de asumir una respuesta uniforme.

El anuncio menciona además una colaboración con Cloudflare y su MCP Server Portal, con la intención de combinar la posición de una pasarela en el recorrido del tráfico con el contexto de identidad, aplicaciones y datos de Obsidian. La efectividad práctica, otra vez, depende de que la acción pase por una integración compatible y por un punto de aplicación capaz de hacer cumplir la decisión.

Un detalle útil para equipos pequeños: Obsidian documenta un modo de prueba que detecta coincidencias con políticas sobre tráfico real antes de empezar a bloquear. Los registros incluyen el agente, la persona que inició la actividad, la herramienta, los argumentos enviados, el resultado y la regla que coincidió.

¿Por qué este anuncio llega justo ahora?

Obsidian no es una startup improvisando sobre el tema. En agosto de 2026 cerró una ronda Serie D de US$85 millones con una valoración post-money de US$1.100 millones, liderada por Crescent Cove Advisor con participación de Greylock Partners y Menlo Ventures, según reportó SiliconANGLE. En esa misma entrevista, Imam dijo que más de 14 clientes pagaban más de US$1 millón anual y más de 100 superaban los US$100.000 al año, y que más del 65% de sus clientes empresariales ya habían dado acceso a agentes de IA a datos dentro de aplicaciones SaaS de terceros.

El mercado, además, se está poblando rápido. TechCrunch reportó en septiembre de 2026 que un vistazo a perfiles públicos de Crunchbase y PitchBook revela al menos dos docenas de empresas vendiendo algún tipo de seguridad para agentes de IA, y que sus promesas suenan notablemente parecidas: grafos de conocimiento, monitoreo continuo, seguridad en tiempo de ejecución, revisión de MCP. En esa misma nota, Reco anunció US$55 millones adicionales sobre una Serie B de US$30 millones cerrada en febrero, y su CEO contó que en un cliente Fortune 100 encontraron 21.000 agentes que la empresa no sabía que existían.

El otro extremo del problema es la identidad. Mintive levantó US$7 millones liderados por Cowboy Ventures —US$11 millones acumulados— para darle a cada agente una identidad propia con permisos acotados, según Unite.AI. El diagnóstico que plantea es el mismo que describe Obsidian: un empleado puede tener acceso a muchos sistemas por la amplitud de su rol, y un agente que hereda esas credenciales adquiere un alcance mucho mayor que el de su tarea inmediata.

¿Qué significa esto para tu startup?

No necesitas un contrato enterprise para aplicar la lógica de fondo. Estas son las acciones que sí puedes ejecutar esta semana.

Haz un inventario de permisos efectivos, no declarados. Toma cada agente en producción y anota no lo que debería poder hacer, sino lo que sus tokens y derechos heredados le permiten alcanzar. La diferencia entre ambas listas es tu superficie de riesgo real.
Separa lectura de movimiento. Define explícitamente qué agentes pueden leer datos de clientes y cuáles pueden exportarlos, modificarlos o compartirlos. Son permisos distintos y casi nunca se configuran como tales.
Empieza en modo observación. Antes de bloquear, corre tus reglas en seco sobre tráfico real y revisa qué habrían detenido. Un bloqueo mal calibrado rompe un flujo de negocio en producción un viernes por la tarde.
Verifica el punto de aplicación antes de comprar. Pregunta, integración por integración, si la acción pasa por el punto de control y si la aprobación humana está soportada. Un panel de descubrimiento no es un control de ejecución.
Clasifica tus datos. Si no marcaste qué es sensible, ninguna política contextual podrá protegerlo. Es el trabajo aburrido que hace funcionar todo lo demás.

Conclusión

El mensaje de fondo del anuncio de Obsidian Security es que la seguridad de agentes se está moviendo del inventario a la ejecución. Saber qué agentes existen fue el primer capítulo; decidir qué pueden hacer en el instante en que actúan es el segundo, y es bastante más difícil porque exige contexto de identidad, de permisos y de valor del dato al mismo tiempo.

Para un founder, la lectura práctica es incómoda pero clara: si tu agente opera con las credenciales de un empleado, heredó también sus excesos. La cobertura fragmentada que admite el propio anuncio —aprobación limitada a ciertos flujos, enforcement dependiente de integraciones compatibles— confirma que no existe una bala de plata. Existe, eso sí, una disciplina que puedes empezar a construir hoy: saber qué puede hacer cada agente, separar los permisos que de verdad importan y probar las reglas antes de activarlas.