Oligo capta 60 millones para blindar agentes de IA: por qué la seguridad en runtime deja de ser opcional

El dato no es la ronda. El dato es el motivo de la ronda.

Oligo ha levantado 60 millones de dólares en agosto de 2026 para extender su seguridad en runtime a aplicaciones con agentes de IA. La cifra importa, claro. Más aún en un mercado donde cada semana alguien promete “proteger la IA” con una mezcla variable de PowerPoint y fe. Pero lo relevante aquí no es el tamaño del cheque, sino la tesis que lo sostiene: ya no basta con escanear código, priorizar CVEs y esperar a que el equipo de ingeniería parche cuando pueda. Si una aplicación con agentes toma decisiones, llama herramientas, accede a datos y dispara acciones sobre sistemas reales, la defensa tiene que ver lo que ocurre mientras ocurre. No después.

Eso coloca a Oligo en una intersección interesante: cloud-native security, application runtime, agentic AI y, de rebote, cumplimiento regulatorio. Porque la conversación sobre agentes de IA ha estado demasiado tiempo secuestrada por la productividad. Automación, copilots, tool use, orchestration. Muy bien. Ahora llega la parte menos glamourosa: quién monitoriza esas acciones, quién las bloquea sin tumbar el servicio y quién responde cuando un prompt acaba provocando una llamada a sistema que nadie esperaba.

La compañía, fundada en 2022, dice tener 129 empleados y un total de 140 millones de dólares captados tras una Serie B de 50 millones cerrada en enero de 2025 y esta nueva ronda anunciada el 13 de agosto de 2026. Su CEO, Nadav Czerninski, sostiene que el viejo margen entre publicación de un parche y explotación práctica se ha desplomado hasta volverse, en sus palabras, “negativo”. El tono puede sonar dramático. El problema no lo es menos.

Para equipos de seguridad y compliance, la noticia tiene una lectura más útil que el habitual desfile de inversores: la seguridad de agentes pasa de laboratorio a presupuesto. Y eso obliga a revisar controles, trazabilidad y gobierno técnico ahora, no cuando el auditor pregunte dentro de seis meses por qué el agente de soporte tenía permiso para invocar una función que tocaba datos sensibles en producción.

No es otra herramienta de IA: es un síntoma de que el modelo de defensa se ha quedado viejo

Durante años, el patrón fue bastante estable. Descubres una vulnerabilidad, la clasificas, evalúas exposición, programas el parche, despliegas y cruzas los dedos para que el exploit no llegue antes. Nunca fue perfecto, pero había cierto margen operativo. Ese margen se ha deteriorado con rapidez por al menos tres razones.

La primera es técnica. La explotación se ha acelerado. Basta mirar la dinámica de los últimos años con vulnerabilidades de alto impacto en librerías, frameworks y software perimetral: análisis de patch diff, weaponization rápida y explotación antes de que muchas organizaciones completen sus ventanas de cambio. No hace falta inventar un apocalipsis nuevo. Ya hemos visto ciclos muy cortos con Log4Shell en diciembre de 2021, MOVEit Transfer en mayo de 2023 y múltiples fallos edge en 2024 y 2025 donde el parche existía, pero la exposición real seguía abierta por inventario incompleto o dependencias ocultas.

La segunda es arquitectónica. El software moderno ya no es un bloque coherente que un equipo conoce de punta a punta. Es una cadena de dependencias, librerías, contenedores, servicios gestionados, APIs y componentes de terceros. Saber que existe una CVE en tu SBOM ayuda. Saber si tu aplicación ejecuta de verdad la función vulnerable ayuda bastante más. Oligo se apoya precisamente en esa promesa: distinguir vulnerabilidades presentes de vulnerabilidades ejecutables, observando llamadas reales en runtime.

La tercera razón es la irrupción de agentes de IA con capacidad de actuar. No hablamos de un chatbot que responde texto y ya. Hablamos de aplicaciones que reciben un prompt, consultan memoria, seleccionan herramientas, invocan funciones, llaman APIs, recuperan secretos, acceden a bases de datos o modifican objetos en otros sistemas. Ese salto de “generar” a “hacer” cambia el perfil de riesgo. Mucho.

En un entorno tradicional, la cadena entre input y acción solía estar bastante acotada en el código de negocio. En uno agentic, parte de la decisión puede estar mediada por un modelo, una capa de orquestación y un conjunto dinámico de herramientas. El mapa de control se complica. Y cuando el mapa se complica, el compliance deja de ser una bonita carpeta y vuelve a convertirse en disciplina operativa.

Qué cambia realmente cuando un agente puede llamar herramientas

La expresión “agentic AI” se ha manoseado hasta perder algo de sentido, así que conviene bajar a tierra. Una aplicación con agentes suele combinar varios elementos: un modelo fundacional, un framework de orquestación, un catálogo de herramientas o funciones, reglas de contexto, conectores a sistemas empresariales y algún mecanismo de memoria o recuperación documental. El riesgo no está en una sola pieza. Está en la combinación.

Un prompt malicioso o ambiguo puede intentar desviar el comportamiento del agente. Una herramienta expuesta con permisos excesivos puede convertir un error de interpretación en una acción dañina. Una función legítima, llamada en un contexto no previsto, puede provocar fuga de datos, manipulación indebida o movimientos laterales. Y una integración con terceros puede agravar el problema porque la visibilidad se fragmenta.

Por eso la frase del CEO de Oligo sobre observar “del prompt a la acción” merece atención. Si una plataforma es capaz de correlacionar prompt, tool call, function call y system call, puede construir una trazabilidad mucho más útil que la telemetría clásica. No solo ve que hubo una llamada al sistema operativo; puede intentar explicar qué secuencia lógica llevó a ella.

Ese matiz es clave por tres motivos.

Primero, mejora la detección. No toda llamada a una herramienta es sospechosa. Lo sospechoso es la combinación entre contexto, herramienta elegida, parámetros y efecto final. Un agente que consulta un CRM para responder una duda de cliente entra dentro de lo esperado. Un agente que, a partir de una instrucción indirecta embebida en un documento, invoca una función administrativa o extrae datos a un destino no previsto, ya es otra historia.

Segundo, mejora la capacidad de bloqueo fino. Muchas defensas tradicionales bloquean a un nivel demasiado alto: el proceso, el contenedor, la conexión, la API entera. El problema es que en producción eso puede romper el servicio. Oligo dice poder bloquear ataques sin tumbar la aplicación. Si eso se verifica en la práctica, es una propuesta fuerte porque el negocio no compra seguridad que deje fuera de juego a la operación cada vez que huele algo raro.

Tercero, mejora la investigación posterior. Si el equipo de seguridad puede reconstruir la secuencia exacta desde la instrucción inicial hasta la llamada efectiva sobre un sistema, acorta tiempos de contención y reduce discusión estéril entre desarrollo, seguridad y producto. Y quien haya estado en una war room sabe que media crisis consiste en eso: gente muy cara intentando averiguar qué demonios ha pasado.

La ventana de parcheo se está encogiendo. En algunos casos, ya llegó tarde

Czerninski sostiene que el tiempo entre parche y explotación se ha vuelto “negativo”. La frase está formulada para titulares, pero apunta a una realidad operativa: cuando una corrección pública deja demasiado rastro técnico, actores ofensivos pueden inferir con rapidez dónde estaba el fallo y construir explotación antes de que una parte del mercado aplique la actualización. La secuencia “sale el parche, luego evaluamos” ya no siempre funciona.

Esto no significa que parchear importe menos. Al contrario. Significa que parchear por sí solo ya no basta para cubrir el hueco temporal entre exposición y remediación efectiva. Ahí entra la seguridad compensatoria en runtime.

El argumento se vuelve especialmente sólido en software con mucha dependencia open source. Si una librería vulnerable está presente pero la función afectada no se ejecuta nunca, el riesgo práctico puede ser bajo y la priorización cambia. Oligo afirma que “muchas veces, el 90% de las vulnerabilidades no son explotables porque no se ejecuta la función vulnerable”. Esa cifra conviene tomarla como declaración comercial hasta ver metodología pública, pero la lógica subyacente es correcta: exposición instalada no equivale automáticamente a exposición explotable.

La consecuencia práctica para un CISO es bastante menos abstracta de lo que parece. Si puedes demostrar que una vulnerabilidad crítica no está siendo invocada en producción, puedes priorizar con más criterio. Si además puedes bloquear el intento de explotación mientras el parche se valida, reduces riesgo sin imponer un cambio urgente que quizá rompa otra cosa. El sueño de cualquier comité de cambios, básicamente.

Ahora bien, en entornos de agentes aparece una complicación adicional: la superficie de explotación no se limita a una librería vulnerable. También incluye el uso emergente de herramientas. Una tool call aparentemente inocua puede encadenarse con otras funciones y terminar en una acción de alto impacto. Eso exige políticas de ejecución y observación contextual, no solo scanners de dependencias.

Del EDR al ADR, y ahora hacia la seguridad de aplicaciones agentic

Durante la última década, el mercado de ciberseguridad ha ido escalando la misma idea a distintas capas: primero observar, luego correlacionar, después bloquear. Lo vimos con EDR en endpoint, con CDR en cloud, con CNAPP y con distintas variantes de XDR que prometían visibilidad unificada. La tesis de Oligo encaja en esa evolución, pero aplicada al comportamiento interno de la aplicación.

La empresa venía posicionándose en Application Detection and Response y runtime para cloud-native. La novedad de 2026 es el giro hacia aplicaciones con IA y agentes. No porque el runtime inspection sea nuevo, sino porque el objeto inspeccionado ha cambiado. Ya no basta con saber qué función del binario o qué librería se ejecuta. Hay que entender qué modelo interviene, qué herramienta se selecciona, con qué parámetros y qué comportamiento final emerge.

Aquí hay una tensión interesante. Cuanta más visibilidad pides, más preguntas aparecen sobre rendimiento, privacidad y gobernanza del dato. Ver prompts, tool calls y ejecución profunda puede ser potentísimo para seguridad. También puede convertirse en una pesadilla si nadie define límites claros sobre qué se captura, cuánto tiempo se retiene, quién accede y cómo se separan datos sensibles de telemetría útil.

Es decir: la seguridad de agentes no es solo un problema de detección. También es un problema de diseño de control. Y ahí muchas organizaciones siguen verdes, por más que sus demos de IA estén muy lustrosas.

Lo regulatorio entra por la puerta lateral, pero entra

La noticia viene de Estados Unidos y no es una pieza regulatoria en origen. Aun así, quien crea que esto no afecta al cumplimiento europeo se está contando un cuento bastante cómodo.

Si una entidad financiera de la UE usa agentes de IA en procesos internos o de cara al cliente, la resiliencia operativa y la trazabilidad dejan de ser optativas. DORA, aplicable desde el 17 de enero de 2025, exige un marco sólido de gestión del riesgo TIC y capacidad de detección, respuesta y recuperación. No hace falta que DORA mencione “agentes” para que el problema le pertenezca.

Hay tres puntos donde el cruce es especialmente claro.

El primero es DORA art. 6 y siguientes sobre el marco de gestión del riesgo TIC. Si el negocio integra agentes en aplicaciones críticas o importantes, esos componentes deben entrar en inventario, arquitectura de control, pruebas y monitorización. El viejo truco de tratar la IA como un experimento de innovación al margen del core cada vez aguanta menos.

El segundo es DORA art. 17 sobre detección de actividades anómalas e incidentes relacionados con las TIC. Si un agente ejecuta una acción inesperada o abusiva, la entidad debe poder detectarla y clasificarla con criterios operativos. Traducido: si tu telemetría solo ve que “algo pasó en un contenedor”, vas tarde. Necesitas contexto suficiente para saber si el origen fue una tool call desviada, un prompt injection, una escalada interna o una explotación clásica de librería.

El tercero es DORA art. 28 y siguientes sobre gestión del riesgo de terceros TIC. Muchas implementaciones agentic dependen de modelos externos, APIs de terceros, plataformas de orquestación y conectores SaaS. La cadena contractual y de supervisión se complica. Si además usas un proveedor de seguridad en runtime para monitorizar esos flujos, surge otra capa: debes entender qué datos observa, dónde los procesa y qué obligaciones contractuales asume.

En paralelo, NIS2 también pisa el terreno aunque con un alcance sectorial distinto. El art. 21 de la Directiva (UE) 2022/2555 exige medidas técnicas, operativas y organizativas adecuadas para gestionar riesgos, incluyendo gestión de incidentes, seguridad de la cadena de suministro y evaluación de la eficacia de las medidas de ciberhigiene. Si tu arquitectura de agentes abre nuevas rutas de acceso a sistemas o datos, esa evaluación debe reflejarlo. No vale seguir pasando el mismo checklist de 2024 con el logo cambiado.

Y luego está GDPR, que aparece en cuanto los prompts, logs o tool calls contengan datos personales. El art. 5 exige minimización; el art. 25 obliga a protección de datos desde el diseño y por defecto; el art. 32 pide medidas apropiadas de seguridad; el art. 33 impone notificación de brechas en 72 horas cuando proceda. Si capturas telemetría profunda para seguridad, necesitas base jurídica, controles de acceso, retención definida y, según el caso, evaluación de impacto. La observabilidad total es tentadora. También puede ser excesiva si nadie pone freno.

Hay un detalle más que suele escaparse en estas conversaciones: el AI Act europeo. En 2026, las obligaciones ya no son una abstracción de PowerPoint. Aunque el reglamento distingue entre categorías de riesgo y no regula “agentes” como tal, cualquier uso que encaje en sistemas de alto riesgo o afecte a transparencia, supervisión humana, calidad de datos, logging o gestión de riesgos arrastra deberes concretos. El logging no es un adorno para compliance. Es la diferencia entre poder reconstruir una decisión o quedarte mirando una salida del modelo como quien consulta los posos del café.

El verdadero valor no está en bloquear exploits, sino en decidir mejor qué riesgo existe de verdad

La parte más interesante del posicionamiento de Oligo no es el marketing de “bloqueamos sin detener la app”, aunque ese mensaje sea el que vende. Lo más valioso, si funciona como prometen, está en la priorización basada en ejecución real.

Los equipos de seguridad llevan años ahogados en vulnerabilidades. El volumen de CVEs publicadas en la NVD y otras fuentes no deja de crecer, y la economía del parcheo nunca ha seguido el mismo ritmo. La cuestión ya no es cuántas vulnerabilidades tienes. La cuestión es cuáles son explotables en tu contexto específico, con tus rutas de ejecución, tus librerías cargadas y tus patrones reales de uso.

En aplicaciones agentic, ese problema se vuelve más incómodo. Porque el contexto no solo depende del código, sino de cómo el agente usa herramientas en tiempo real. Un mismo componente puede ser inocuo en una aplicación y peligroso en otra según permisos, prompts, workflows y accesos laterales.

Eso cambia incluso la conversación con auditoría interna y con el comité de riesgos. En lugar de limitarse a un reporte de “tenemos X vulnerabilidades críticas abiertas”, un equipo maduro debería poder responder algo más fino: cuáles están presentes, cuáles se ejecutan, cuáles son alcanzables desde entradas no confiables, cuáles afectan a aplicaciones críticas y qué control compensatorio existe mientras se remedia. Ese lenguaje ya no es solo técnico; es gobernanza de riesgo de verdad.

Si Oligo u otros proveedores consiguen ofrecer esa evidencia de manera fiable, el impacto puede ser relevante en dos frentes. Uno, reducción de fatiga operativa. Dos, decisiones de riesgo más defendibles frente a reguladores, auditores y consejo. No elimina la responsabilidad, pero al menos evita que toda priorización parezca una mezcla de intuición y resignación.

El ángulo incómodo: visibilidad profunda sí, pero ¿a qué coste?

No conviene tragarse sin masticar la promesa comercial. La inspección profunda en runtime suena magnífica hasta que aparecen las preguntas feas.

La primera es rendimiento. Monitorizar ejecución en tiempo real, con detalle suficiente para correlacionar prompt, tool call, function call y system call, puede introducir overhead. Los proveedores suelen insistir en que su tecnología es “non-intrusive”. Bien. Eso hay que medirlo en cargas reales, no en una demo amable. Si una entidad va a desplegar este tipo de control sobre aplicaciones críticas, debe exigir pruebas de impacto por tipo de workload, lenguaje, entorno de contenedor y volumen de transacciones.

La segunda es precisión. Bloquear sin tumbar la aplicación es el santo grial, pero la selectividad tiene un precio: necesitas detecciones afinadas. Un falso positivo en un agente que interviene en atención al cliente, fraude, pagos o soporte interno puede degradar servicio o crear comportamientos erráticos difíciles de explicar. Y si el sistema se vuelve demasiado conservador para evitar errores, el valor defensivo se reduce. Esa tensión entre eficacia y fricción no desaparece porque haya una ronda de financiación de por medio.

La tercera es privacidad y confidencialidad. Si observas prompts y tool calls, puedes estar capturando secretos, datos de clientes, contenido sensible o propiedad intelectual. En sectores regulados, eso obliga a segmentar muy bien qué se registra, quién puede consultarlo y cómo se protege. También complica transferencias internacionales de datos si el proveedor procesa telemetría fuera del EEE o usa subencargados adicionales.

La cuarta es gobernanza de modelos y herramientas. Puedes monitorizar mucho y seguir mal diseñado. Si el agente tiene acceso excesivo a herramientas, un runtime guardrail será un cinturón de seguridad, no un sustituto del volante. La seguridad de agentes empieza bastante antes de la ejecución: diseño de permisos mínimos, separación de funciones, validación de parámetros, allowlists de acciones, context isolation y revisión humana donde el impacto lo exija.

En otras palabras: el runtime no arregla una arquitectura descuidada. La compensa hasta cierto punto. Y eso, aunque menos sexy que el discurso de “AI protection”, es justo lo que los compradores deberían recordar.

Qué deberían preguntarse ahora los CISOs y responsables de compliance

La noticia de Oligo sirve como excusa perfecta para una revisión interna seria. No hace falta comprar esta plataforma en concreto para entender la lección. Si tu empresa ya tiene agentes en producción, o está a semanas de ponerlos, hay preguntas que ya tendrían que estar respondidas.

La primera: ¿sabemos cuántas aplicaciones con IA están realmente en producción? El propio Czerninski apunta a un fenómeno que muchos equipos están viendo: clientes sorprendidos por la cantidad de aplicaciones con IA y agentes ya desplegadas. Esa sorpresa no tiene ninguna gracia. Indica shadow AI, integración descentralizada y gobierno técnico débil. Si el inventario está roto, el resto también.

La segunda: ¿qué herramientas puede invocar cada agente y con qué permisos? Aquí no basta con saber que existe una integración con Slack, Salesforce, ServiceNow, GitHub o una base de datos. Hay que mapear operaciones permitidas, autenticación utilizada, posibilidad de escritura, rutas de escalado y segregación por entorno. Un agente con credenciales demasiado amplias es un incidente esperando a coger turno.

La tercera: ¿podemos reconstruir una acción desde el prompt hasta el efecto final? Si mañana un agente borra un registro, cambia un ticket, expone un documento o dispara un pago erróneo, ¿hay trazabilidad suficiente para saber por qué pasó? Si la respuesta es “tenemos algunos logs”, la respuesta real es no.

La cuarta: ¿la telemetría de seguridad captura datos personales o confidenciales? Si sí, ¿qué base jurídica y qué controles de minimización existen? El cruce entre observabilidad, GDPR y secreto empresarial va a generar fricciones reales en 2026. Quien lo resuelva después del despliegue pagará el peaje en retrabajo y en discusiones con legal.

La quinta: ¿qué control compensatorio existe entre detección de vulnerabilidad y parche efectivo? En entornos donde la explotación se acelera, esperar a la ventana de cambio sin más es una apuesta demasiado optimista. Necesitas aislamiento, mitigación, WAF, reglas de comportamiento o seguridad en runtime. La herramienta concreta puede variar. La necesidad ya no tanto.

La sexta: ¿el comité de riesgos entiende la diferencia entre IA generativa y agentes con capacidad de acción? Muchas organizaciones siguen mezclándolo todo bajo la etiqueta “IA”. Error. Un asistente que resume documentos no tiene el mismo perfil que un agente que consulta sistemas, crea objetos o toma decisiones con efectos externos. Gobernarlos igual es una forma elegante de no gobernarlos.

Para banca, seguros y fintech, esto va más allá de la moda

En el sector financiero, el atractivo de los agentes es obvio: automatizar operaciones, reforzar atención al cliente, acelerar due diligence, mejorar soporte al empleado, ayudar en fraude o compliance, y reducir tiempos en procesos con demasiada fricción manual. Todo muy razonable. El problema es que la infraestructura financiera tiene poca tolerancia al comportamiento imprevisible.

Un agente con acceso a sistemas de back office, repositorios documentales, herramientas de ticketing o bases de datos de clientes puede convertirse en multiplicador de eficiencia. También en multiplicador de impacto si algo sale mal. Y aquí DORA aprieta precisamente donde duele: identificación de funciones críticas, pruebas de resiliencia, gestión de terceros TIC e incident reporting. No hace falta un ciberataque hollywoodiense; basta una cadena de decisiones automatizadas mal gobernada para generar un incidente operativo serio.

Además, muchas entidades financieras españolas y europeas están intentando casar varias exigencias a la vez: despliegue de IA útil, control de terceros, trazabilidad suficiente para auditoría y limitación de costes. Esa cuadratura del círculo favorece a proveedores que prometen una sola capa de visibilidad para cloud-native y agentic apps. Tiene lógica. La cuestión es si esa capa puede integrarse de verdad con SIEM, SOAR, inventario de activos, gestión de vulnerabilidades y gobierno del dato sin crear otro silo brillante.

Si no se integra, el resultado será el clásico de la industria: una herramienta más que genera señal, consume presupuesto y obliga al equipo a exportar CSVs para hacer el trabajo serio en otra parte. Nadie necesita otro monumento a la interoperabilidad pendiente.

Lo que esta ronda dice del mercado en 2026

La financiación a Oligo también revela algo sobre la economía de la ciberseguridad este año. Los inversores ya no se impresionan tanto con promesas genéricas de “seguridad para IA”. Buscan categorías con dolor operativo claro. Y el dolor aquí es muy concreto: empresas que ya han metido IA en producción, equipos de seguridad que no ven bien lo que esos sistemas hacen y ventanas de explotación cada vez más cortas.

Que Ballistic Ventures, Canon Capital, Greenfield Partners, Lightspeed Venture Partners, Red Dot Capital y TLV Partners lideren o participen en esta ronda sugiere confianza en una tesis de mercado: la seguridad en runtime vuelve a ganar centralidad, pero ahora ampliada a agentes. No es casualidad. El péndulo ha ido demasiado tiempo hacia prevención estática, postureo de plataforma y gobernanza de IA entendida solo como política documental.

El dinero no prueba que la tecnología funcione como promete. Eso nunca conviene olvidarlo. Pero sí indica que el problema que intenta resolver ya se percibe como urgente y presupuestable. Y en seguridad, cuando algo pasa de “interesante” a “presupuestable”, la conversación cambia de nivel.

También deja otra lectura menos obvia: la frontera entre AppSec, cloud security y AI security se está desdibujando. Los compradores quieren menos compartimentos y más relación causal entre lo que el software hace y el riesgo que genera. Si el mercado evoluciona en esa dirección, veremos más consolidación entre observabilidad, detección de comportamiento y control de ejecución.

Mi lectura: el runtime para agentes no es una categoría de nicho, es una reacción tardía a un despliegue demasiado rápido

La industria ha corrido a desplegar agentes porque la productividad prometida era demasiado tentadora y la presión competitiva demasiado visible. Primero se conectaron modelos. Luego herramientas. Después permisos. Más tarde alguien preguntó cómo se monitorizaba todo aquello. El orden, por decirlo suavemente, no ha sido ejemplar.

Por eso la jugada de Oligo tiene sentido. No porque haya descubierto de repente que la IA necesita seguridad, sino porque pone el foco en el lugar exacto donde duele: la ejecución real. Ahí es donde se materializa el riesgo. Ahí es donde una decisión del agente deja de ser una hipótesis y se convierte en una acción sobre datos, sistemas o procesos.

¿Basta con runtime security? No. Hace falta diseño de permisos, revisión de casos de uso, red teaming específico de agentes, pruebas adversariales, segmentación, gestión de secretos, control contractual de terceros y gobernanza del dato. Hace falta, además, que seguridad y compliance hablen con producto antes del despliegue y no solo cuando el problema ya se ha monetizado en forma de incidente.

Pero negar el valor de esta capa sería absurdo. Si la explotación se acelera y los agentes aumentan la complejidad causal entre input y acción, una defensa que observe ese recorrido tiene mucho sentido. Más aún si puede priorizar exposición real y bloquear sin apagar media plataforma.

La pregunta útil para 2026 no es si la seguridad de agentes será una categoría grande. Ya lo es. La pregunta es quién será capaz de demostrar tres cosas a la vez: visibilidad suficiente, impacto operativo asumible y encaje regulatorio creíble. Cualquiera puede vender detección. Lo difícil es vender control sin convertir la producción en un experimento.

Si eres CISO, responsable de arquitectura o de compliance, aquí va la parte práctica: revisa hoy mismo dónde están tus agentes, qué herramientas tocan, qué permisos usan y qué telemetría te permite explicar sus acciones. Si esa respuesta depende de cinco equipos, tres hojas de cálculo y una esperanza vaga de que “no hagan nada raro”, no tienes un programa de control. Tienes una anécdota esperando fecha.

La ronda de Oligo, en ese sentido, no es solo una noticia de financiación. Es una advertencia de mercado. La IA agentic ya ha salido del laboratorio. Ahora le toca pasar por seguridad. Y, con un poco de suerte, esta vez antes de que llegue el auditor o el incidente.