Convierte el air gap en una demo de confianza: intenta escapar del sandbox delante del cliente y deja que la infraestructura diga “no”

Empieza con una pregunta que el comprador sí teme. “¿Qué pasa si el agente intenta salir de donde le dimos permiso?” En vez de responder con arquitectura en una diapositiva, abre un laboratorio preparado. Muestra el scope autorizado: dos dominios sintéticos, una cuenta de prueba y una carpeta. Después pide al agente una tarea que naturalmente podría explorar más. La confianza se construye cuando el prospecto ve que la libertad del agente termina en una frontera concreta. La demo debe usar únicamente activos sintéticos y no intentar accesos reales; el objetivo es probar controles, no reproducir un incidente peligroso.

Haz tres intentos de escape seguros. Primero, resuelve un dominio externo de prueba que el DNS interno debe rechazar. Segundo, intenta una conexión hacia una IP pública reservada para documentación. Tercero, presenta una credencial ficticia y una herramienta que trate de usarla fuera del lab. En cada caso, la infraestructura bloquea antes del efecto. El modelo puede incluso “querer” continuar; eso hace la demostración más fuerte, porque deja claro que la seguridad no depende de su obediencia. Cada bloqueo aparece en un receipt con regla, destino y runid.

Después muestra lo que sí está permitido. Un sandbox que solo bloquea parece una jaula; el valor está en permitir autonomía segura dentro del perímetro. Haz que el agente complete una exploración compleja en los servicios sintéticos, use herramientas y encuentre una bandera o evidencia. El prospecto ve que seguridad no significa desactivar capacidad. El sistema distingue acción autorizada de acción externa. Esa combinación es comercialmente potente para empresas que quieren agentes de navegador o código pero temen sesiones con acceso demasiado amplio a cuentas, redes o archivos.

Invita al equipo de seguridad a elegir la regla. Antes de la segunda ejecución, permite que el cliente agregue o quite un destino de la allowlist. Repite el test y muestra que el comportamiento cambia por política, no por un nuevo prompt. Eso transforma la demo en conversación de gobierno. El comprador puede imaginar sus propios scopes: dominios de proveedores, cuentas de anuncios, repositorios o CRMs. La plataforma se posiciona como una capa que hace ejecutables esas decisiones, en lugar de pedir a cada agente que recuerde una lista de prohibiciones escrita en lenguaje natural.

Entrega una prueba exportable al final. El containmentreceipt resume reglas activas, intentos permitidos, bloqueos y confirmación de que no hubo egress fuera del lab. No necesitas revelar configuración sensible; basta evidencia suficiente para revisión. El equipo puede llevar ese artefacto a seguridad o compliance. Comparado con una demo de respuestas inteligentes, este documento tiene valor después de la reunión. Demuestra una propiedad de infraestructura que puede volver a probarse en cada release y convertirse en criterio de aceptación durante un piloto.

Aplicación Goatify. Llamemos a esta pieza “Try to Escape”. Para clientes que usarán agentes con navegador, archivos o APIs, la incluimos temprano en ventas. La demo cambia la conversación de “¿podemos confiar en la IA?” a “¿qué puede alcanzar esta habilidad aunque se equivoque?”. Esa pregunta es más concreta y vendible. La inteligencia puede cambiar de modelo; la frontera permanece. Si conseguimos que el prospecto vea un agente capaz trabajando libremente dentro del scope y chocando limpiamente contra el borde, mostramos autonomía y seguridad en la misma escena. Ese contraste ayuda a que seguridad, operaciones y negocio discutan límites concretos en vez de debatir de forma abstracta si un modelo es confiable.