Micha Rave, CEO y cofundador de Hush Security – Serie de entrevistas

Micha Rave, CEO y cofundador de Hush Security, es un ejecutivo experimentado en ciberseguridad y tecnología cuya carrera abarca la ingeniería de software, la gestión de productos, redes empresariales, seguridad en la nube e identidad. Antes de cofundar Hush Security en 2024, pasó más de cinco años en Proofpoint como Director Senior de Gestión de Productos para Seguridad en la Nube, donde fue responsable de sus líneas de productos Zero Trust Network Access (ZTNA) y Secure Web Gateway (SWG). Anteriormente se desempeñó como vicepresidente de Gestión de Productos en Meta Networks, centrado en redes empresariales y seguridad, y ocupó cargos de liderazgo en producto e ingeniería en HARMAN International, Redbend, SanDisk, Hola, Jungo y Elbit Systems. Su trayectoria combina desarrollo de software práctico con más de dos décadas de experiencia construyendo y comercializando productos de seguridad, redes, virtualización y tecnología integrada.

Hush Security es una empresa de ciberseguridad centrada en proteger agentes de IA y otras identidades no humanas sustituyendo credenciales de larga duración y secretos estáticos por acceso basado en identidad y controlado por políticas. Su plataforma descubre agentes de IA, incluidos agentes sombra y agentes desarrollados internamente, les asigna identidades verificables y gobierna sus interacciones con los sistemas empresariales mediante permisos limitados en el tiempo, políticas centralizadas y registros de actividad auditables. La empresa fue fundada por veteranos de seguridad del equipo detrás de Meta Networks, que Proofpoint adquirió en 2019. En julio de 2026, Hush recaudó una Serie A de 30 millones de dólares con Akamai Technologies como inversor estratégico junto a Battery Ventures y YL Ventures, elevando la financiación total a 41 millones de dólares mientras la compañía amplía su tecnología para gobernar agentes de IA empresariales e infraestructura no humana.

Antes de fundar Hush Security, pasaste años construyendo y liderando productos de seguridad, incluida la seguridad en la nube en Proofpoint. ¿Qué viste en el mercado que te convenció de que había una necesidad de crear Hush, y cómo ha evolucionado esa tesis original con el rápido auge de la IA agente?

En Proofpoint observamos cómo las empresas resolvían la identidad humana mientras todo lo no humano seguía funcionando con secretos estáticos. Cuentas de servicio, cargas de trabajo, pipelines, todas autenticándose con claves que nadie poseía y que nunca expiraban. La industria respondió con mejores bóvedas. Eso es una mejor caja fuerte, no una solución.

La tesis fundadora era trasladar el acceso no humano de los secretos a la identidad. Identidad verificable de cargas de trabajo, credenciales de corta duración emitidas justo a tiempo, políticas aplicadas en línea. Sin reescrituras de código.

La IA agente hizo que eso fuera urgente. Un agente es una NHI que razona y decide en tiempo de ejecución qué herramientas invocar. Si le das una clave estática, le has otorgado a un software autónomo acceso permanente a producción, y los agentes se despliegan fuera de cualquier proceso de cambio; un desarrollador conecta un servidor MCP el martes y ya está accediendo a datos de clientes el viernes.

La tesis no cambió. El alcance sí. El acceso basado en identidad era la respuesta correcta para las cargas de trabajo. Para los agentes es la única viable: conocer cada agente que exista, otorgar a cada uno la menor agencia por defecto y auditar cada acción. Los humanos obtuvieron un IdP. Los agentes también lo necesitan y eso es Hush.

Hush sostiene que los agentes de IA empresariales deberían tener sus propias identidades y permisos delegados en lugar de simplemente heredar los derechos de acceso de los humanos que los utilizan. ¿Por qué los sistemas tradicionales de Gestión de Identidad y Acceso (IAM) tienen dificultades con los agentes autónomos, y qué necesita cambiar?

El caso obvio es un agente que actúa en nombre de un usuario. El caso más difícil es un agente sin ningún usuario: un trabajo programado, un respondedor SOC autónomo, un pipeline que razona y actúa por sí mismo. No hay nadie de quien delegar, por lo que los equipos recurren a la única herramienta que tienen, una cuenta de servicio estática con permisos amplios y una clave que nunca expira. Ese es el mismo modelo de secreto compartido que ha estado fallando durante una década, ahora vinculado a software que improvisa.

Los sistemas del otro extremo lo empeoran. La mayoría de las API internas, bases de datos y servidores MCP no realizan una autorización real. Verifican si posees un token válido, no lo que tienes permitido hacer con él. La posesión equivale a permiso.

Lo que debe cambiar: cada agente debe obtener su propia identidad, emitida criptográficamente, exista o no un humano detrás de ella. El acceso se concede por acción, de corta duración y limitado, con políticas aplicadas en línea en lugar de confiar en el sistema de destino. Cuando hay un usuario, los permisos del agente son la intersección de lo que el usuario puede hacer y lo que ese agente está autorizado a hacer para esa tarea. Cuando no lo hay, la propia identidad y política del agente son la historia completa. Los humanos obtuvieron el principio de menor privilegio. Los agentes necesitan el principio de menor agencia.

Utilizas el concepto de “menor agencia” al hablar de seguridad de IA. ¿En qué se diferencia la menor agencia del principio tradicional de ciberseguridad de menor privilegio, y cómo pueden las organizaciones determinar exactamente qué se le debe permitir hacer a un agente de IA para una tarea concreta?

Los agentes no tienen un comportamiento fijo. Dar a uno acceso de lectura a un CRM y acceso de escritura al correo electrónico no equivale a conceder dos permisos, sino a otorgar cualquier ruta entre ambos. El principio de menor privilegio delimita lo que un agente puede tocar. No dice nada sobre lo que debe hacer con ello.

Least agency añade la dimensión que falta: qué acciones, para qué tarea, en este momento. Un agente que gestiona tickets necesita leer y comentar. No necesita cerrar, eliminar o tocar la facturación, aunque el token lo permita. Cuando la tarea termina, el acceso termina.

Decidir qué está permitido comienza con la observación, no con conjeturas. Ejecuta el agente, observa a qué llama realmente y usa eso para definir la línea base. Luego restringe usando tres entradas: la tarea para la que existe, el usuario para quien actúa (nunca más de lo que ese usuario podría hacer) y el radio de explosión de cada acción, porque publicar un comentario y procesar un pago no deberían compartir la misma ruta de aprobación.

El principio de menor privilegio decide quién recibe las llaves. La menor agencia decide qué pueden hacer una vez dentro.

A menudo “prestamos” nuestra identidad a nuestro agente, pero no queremos que el agente tenga el mismo nivel de permisos que nosotros; esa es la definición de menor agencia.

Hush recientemente recaudó una Serie A de 30 millones de dólares, elevando la financiación total a $41 million, con Akamai uniéndose como inversor estratégico junto a Battery Ventures y YL Ventures. ¿Qué aporta la participación de Akamai más allá del capital y cómo esperan que la asociación influya en la expansión de Hush hacia la seguridad de agentes de IA empresariales?

Akamai se sitúa en la ruta de tráfico de la mayoría de las empresas del mundo, y es precisamente allí donde la seguridad de los agentes debe operar. No se gobierna un agente desde un panel después del hecho. Se gobierna en línea, en el momento en que llama a una herramienta o API. Akamai construyó su negocio sobre ese modelo.

Más allá del capital, aportan tres cosas: distribución a los CISOs que ya preguntan cómo controlar a los agentes y el tráfico MCP; validación de que la identidad del agente es una categoría real, no una característica; y décadas de experiencia asegurando el tráfico máquina‑a‑máquina a escala global, que es lo que el tráfico agente‑a‑herramienta está a punto de convertirse.

Model Context Protocol (MCP) está convirtiéndose rápidamente en una capa importante para conectar agentes de IA con herramientas y datos empresariales. Desde una perspectiva de seguridad, ¿qué nuevos riesgos introduce MCP y cómo deberían las organizaciones pensar en la identidad y autorización entre el agente, el servidor MCP y el recurso subyacente?

MCP hizo que conectar un agente a una herramienta fuera trivial. Ese es el riesgo. Un desarrollador añade un servidor a un archivo de configuración y el modelo ya puede leer Jira, consultar una base de datos o enviar correo electrónico. Sin revisión, sin inventario, sin política. La seguridad se entera cuando algo falla.

Ahora existen tres nuevos problemas:

1. Shadow MCP – nadie sabe cuántos servidores están en funcionamiento ni a qué acceden.
2. Expansión de credenciales – la mayoría de los servidores se autentican con un token estático que otorga acceso a toda la superficie, por lo que el agente obtiene todo lo que el token puede hacer.
3. La cadena colapsada – el recurso solo ve la credencial del servidor MCP, por lo que no puede saber qué agente, actuando en nombre de qué usuario, realizó la llamada. La identidad debe estar en la base de cada interacción, el acceso debe ser efímero, limitado y basado en los permisos del agente y del usuario.

Hush se fundó originalmente con la idea de que los secretos estáticos y las credenciales de larga duración son una base rota para el acceso de máquinas. Dado que la mayor parte de la infraestructura empresarial sigue dependiendo en gran medida de claves API, tokens y otros secretos, ¿cómo pueden las empresas avanzar de manera realista hacia un acceso basado en identidad y de corta duración sin reconstruir todo su stack tecnológico?

No lo reconstruyes. Nadie que diga lo contrario ha tratado con una empresa. La mayor parte de lo que protegemos es anterior a la expresión identidad no humana, y no se está reescribiendo.

Así que no lo solicitamos. Hush se despliega sin cambios de código y se sitúa en la ruta de acceso. El primer paso es el descubrimiento: cada secreto, quién lo usa, a qué llega, qué hace realmente en tiempo de ejecución. La mayoría de las empresas nunca ha visto esa imagen.

Luego es un viaje, no una migración. El descubrimiento muestra qué secretos están muertos, sobre‑alcanzados o son de mayor riesgo. Primero se corrigen esos. Después se sustituyen las claves estáticas por credenciales de corta duración emitidas por identidad, un sistema a la vez. La aplicación sigue pensando que está usando una clave. La clave simplemente deja de ser de larga duración y la política pasa a nosotros.

El mismo modelo cubre un servicio Java de quince años y un servidor MCP implementado la semana pasada. Comienza donde está el riesgo, demuéstralo, sigue adelante.

Los agentes de IA trabajarán cada vez más en nombre de humanos y, en muchos casos, delegarán tareas a otros agentes. A medida que estos flujos de trabajo multi‑agente se vuelvan más complejos, ¿cómo se mantiene una cadena clara de identidad, autorización, propiedad y responsabilidad para cada acción que se lleva a cabo?

El modo de falla: un usuario solicita a un orquestador, este delega a un segundo agente, que llama a una herramienta a través de un servidor MCP, que accede a una base de datos con una cuenta de servicio. Cuatro saltos después, el registro muestra una sola cosa, un token válido. Quién solicitó, quién decidió y quién es responsable ya no aparecen.

La solución es impedir que la identidad colapse en cualquier salto. Cada agente tiene su propia identidad criptográfica. Cuando delega, no entrega su token. Emite una delegación limitada: este sub‑agente, esta tarea, estas acciones, en nombre de este usuario. Cada salto lleva la cadena completa y sus propios permisos.

La responsabilidad proviene de aplicar y registrar en línea, en el punto de acción. El registro del gateway de lo que se le permitió hacer, lo que llamó y la cadena detrás de ello.

Los sistemas multi‑agente serán más difíciles de razonar. La cadena de custodia de cada acción no tiene por qué serlo.

La inyección de prompts y otros ataques pueden potencialmente manipular a un agente de IA legítimo para que realice acciones que su operador nunca pretendió. ¿Hasta qué punto los controles de acceso basados en identidad pueden limitar el daño de un agente comprometido o manipulado, incluso cuando el modelo de IA subyacente se comporta incorrectamente?

No evitarás la inyección de prompts en el modelo. Los modelos leen contenido no confiable por diseño. Asume que el agente eventualmente será incitado a hacer algo incorrecto. La cuestión es qué puede hacer cuando eso ocurre.

Los límites de acceso basados en identidad reducen el radio de explosión. Un agente manipulado con la mínima agencia solo puede abusar de las acciones que se le concedieron para esa tarea. Si puede leer tickets y publicar comentarios, ninguna inyección lo hará exfiltrar la base de datos del cliente. El token no tiene ese alcance.

La atribución de usuario mantiene la cadena intacta: qué usuario, qué agente, qué tarea, en cada llamada. El agente nunca supera lo que el usuario podría hacer, y cada acción se rastrea.

La detección de anomalías captura lo que la política permite pero la intención no. Un agente que normalmente lee cinco registros y de repente extrae cinco mil está fuera de carácter incluso si cada llamada está autorizada. Como el gateway está en línea y conoce la línea base, puede señalar o bloquear eso en tiempo real.

El modelo estará equivocado a veces. La identidad delimitada, la atribución y las líneas de base de comportamiento hacen que los errores sean sobrevivibles.

Hush se centra principalmente en asegurar la IA, pero ¿cómo están usando IA dentro de Hush mismo? ¿Hay áreas como descubrir identidades no humanas, analizar patrones de acceso, priorizar riesgos o aplicar políticas donde la IA pueda mejorar materialmente la plataforma de seguridad?

La usamos donde sea que merezca su lugar.

En el producto, la parte difícil no es encontrar secretos, sino comprenderlos. Una clave aparece en el tráfico. ¿Identidad de carga de trabajo, integración de proveedor, token de prueba de desarrollo, credencial muerta? Un LLM lee el contexto de ejecución y las señales del propietario y propone una respuesta con una puntuación de confianza. Resume lo que una identidad realmente hace en lenguaje humano sencillo, de modo que la política sea una que un humano aprobará. Clasifica el riesgo por alcance real y radio de explosión, no por gravedad estática. La aplicación sigue siendo determinista. La IA ayuda a redactar la política, pero no vota en tiempo de ejecución.

Dentro de Hush, la programación agente cambió nuestro ritmo. Funcionalidades que tomaban un sprint ahora toman días, y lanzamos integraciones a una velocidad que un equipo Serie A no podría costear de otro modo. Los LLMs trían tickets de soporte, agrupan causas raíz y resaltan solicitudes de clientes para discusiones de hoja de ruta. Nuestro propio gateway MCP se sitúa delante de todo, ayudando a nuestros clientes a razonar y consumir NHI y riesgo agente.

Hush dice que múltiples compañías Fortune 500 están usando su tecnología, mientras Kyndryl ha desplegado Hush internamente y ha comenzado a revenderlo a clientes empresariales. ¿Qué están aprendiendo de estos despliegues a gran escala sobre los problemas reales de gobernanza que las empresas enfrentan una vez que los agentes de IA pasan de la experimentación a la producción?

Nadie sabe lo que tiene. Cada gran despliegue comienza de la misma manera: la seguridad piensa que hay una docena de agentes en producción, el descubrimiento encuentra cientos, ya tocando datos de clientes. El problema de gobernanza no es la política, es primero el inventario.

Las credenciales son peores que los agentes. Casi todos los agentes en producción se ejecutan con una cuenta de servicio estática que lo precede, con permisos acumulados durante años para otra cosa. No obtuvo acceso delimitado.

Falta la propiedad. Pregunta quién es responsable de un agente, o de un NHI, y obtendrás como máximo el nombre de un equipo, un contratista que ya se fue, o silencio.

Y el comprador cambió. Este era un problema del equipo de plataforma. Ahora el CISO lo posee porque la junta lo está exigiendo. Eso nos pasó de pilotos a despliegues empresariales, y es la razón por la que Kyndryl lo desplegó internamente antes de revenderlo.

Los agentes no crearon nuevos problemas de gobernanza. Tomaron los que las empresas ignoraron durante una década con cuentas de servicio y los empeoraron mucho.

Gracias por la gran entrevista, los lectores que deseen saber más deben visitar Hush Security.