Bloquea acciones de agentes de IA en el endpoint

Aplicación

Todo lo demás solo observa.

ZYBE rechaza la acción antes de que se ejecute.

Cada llamada a herramienta que un agente de IA va a hacer se evalúa en el endpoint, en el propio momento previo a la acción del agente, según tus reglas. Si una regla dice que no, el comando no arranca, el archivo no se abre y el servidor no responde. Al modelo se le explica por qué y se le pide que no lo intente por otra vía. Sin proxy, sin gateway, sin tráfico que inspeccionar: el propio agente aplica la decisión, y por eso se mantiene sin conexión y en todos los portátiles a la vez.

Cómo funciona, con dibujos

Qué se aplica en cada agente

Qué se detiene

Doce tipos de acción, rechazados en el endpoint

Cada una es una regla. Ponla en Report, Ask o Block, por perfil, por grupo de endpoints, por agente.

Dónde se aplica

Doce agentes bajo reglas, y el resto rechazado sin más

Cada agente con un hook previo a la acción ejecuta el hook de ZYBE. Las apps sin hook actúan a través de servidores MCP, y estos pasan por el shim de ZYBE. La consola muestra un estado por agente y por endpoint, calculado a partir de las llamadas que llegaron de verdad: Blocking, Recording, Seen, Silent, o Not allowed para un producto que la empresa ha rechazado.

Agente

Cómo le llega el rechazo

Hook, en la configuración gestionada

Hook

Hook, gestionado en instalaciones para todo el equipo

Hook, más la política gestionada

Hook, en el archivo compartido de hooks de Gemini

Hook de shell en su configuración

Un plugin de ZYBE dentro de su gateway

Sus servidores MCP pasan por el shim de ZYBE

Sus servidores MCP pasan por el shim

Rechazado sin más: el endpoint le quita el permiso para ejecutarse

La última fila no tiene hook, así que una regla no puede evaluar llamada a llamada. La empresa decide si el producto está permitido o no, y el endpoint lo aplica. La consola nunca da un agente por bloqueado solo porque haya un archivo en su sitio.

Con las palabras del agente

Así se ve un rechazo

Sesiones reales, agentes reales, a los que se pidió instalar un paquete que el espacio de trabajo había contenido. Todos se detuvieron, citaron el motivo y no volvieron a intentarlo.

Una amenaza abierta en la consola: la salida inyectada, el comando que siguió, el resumen y la corrección

La cadena, en la consola: las instrucciones llegaron en una página descargada, el siguiente comando de esa sesión y qué hacer.

El cuarto estado

Not allowed: cuando no hay puerta, el endpoint rechaza la app

Algunas apps actúan en la nube de su proveedor o en la web, sin nada en el portátil delante de lo que poner un hook. En esos casos, la empresa decide si la app está permitida o no, y el endpoint aplica la respuesta: le quita el permiso para ejecutarse, la cierra si está abierta y le devuelve el permiso en cuanto la empresa vuelva a permitirla. Escribe el nombre del producto una vez en Rules y todos los endpoints lo rechazan en menos de un minuto. Instalada, rechazada y visible como Not allowed en cada endpoint. Nadie más hace esto en el endpoint.

Nada sale

Se evalúa en el equipo, no en la nube de otro

El comando, la ruta, la página y el prompt se leen en el endpoint y nunca se envían. A la consola llegan la regla que coincidió, la decisión, el agente y un hash. Esa es la diferencia con un gateway que inspecciona tu tráfico: ZYBE ve lo que hace el agente y tus conversaciones siguen siendo tuyas.

Instálalo en un equipo

Lo que sale del equipo