- Por qué el DNS es Importante en los Modelos de Amenaza de Sandbox
- Dónde Aparece la Resolución DNS en los Flujos de Trabajo de los Agentes
- Cómo Evaluar la Política de Salida
- Obtención de Paquetes y DNS Impulsado por Dependencias
- Secretos y Suposiciones de Exposición de Datos
- Registros, Pistas de Auditoría y Evidencia de Incidentes
- Notas de Evaluación de Novita Agent Sandbox
- Lista de Verificación de Revisión de Seguridad
- Conclusión
- Preguntas Frecuentes
- Artículos Recomendados
El riesgo de exfiltración por DNS es relevante cuando el código en un sandbox puede resolver dominios controlados por un atacante o usar DNS como un canal de datos saliente. Por lo tanto, los equipos deben evaluar la política de DNS, el registro, las rutas de obtención de paquetes y la evidencia de incidentes antes de confiar en un sandbox de agente de IA para flujos de trabajo sensibles.
Por qué el DNS es Importante en los Modelos de Amenaza de Sandbox
Los sandboxes de agentes de IA están diseñados para una autonomía útil. Un agente de codificación puede ejecutar pruebas, instalar paquetes, llamar a APIs, lanzar un navegador, inspeccionar archivos y producir artefactos sin que un humano apruebe cada comando. Esa flexibilidad es exactamente la razón por la que el comportamiento de red necesita su propia revisión, separada del aislamiento de CPU, memoria, sistema de archivos y procesos.
El DNS a menudo recibe menos atención que la salida HTTP porque parece un componente de infraestructura. Las aplicaciones necesitan resolución de nombres para llegar a APIs, registros, páginas web y puntos finales de actualización. Pero el DNS sigue siendo comunicación saliente. Un sandbox que puede resolver dominios arbitrarios puede revelar información a través de los nombres de las consultas, contactar con infraestructura controlada por un atacante o crear un punto ciego si el tráfico DNS no se registra con el mismo cuidado que las solicitudes web.
Esto no es una categoría teórica inventada para agentes de IA. MITRE ATT&CK documenta DNS como un protocolo de capa de aplicación que los adversarios pueden usar para comunicación de comando y control, y también documenta por separado la exfiltración sobre protocolos alternativos cuando los datos salen a través de un canal que no es el protocolo de aplicación principal. Para los evaluadores de sandboxes, la lección es directa: no trate el DNS como inofensivo solo porque no es un POST HTTP.
Para los agentes de IA, el riesgo generalmente proviene de una cadena de pequeños permisos en lugar de un error obvio:
| Capacidad del sandbox | Por qué los equipos lo permiten | Pregunta relacionada con DNS |
|---|---|---|
| Instalación de paquetes | Permitir que los agentes instalen dependencias faltantes | ¿Qué registros y rutas de resolución están permitidos? |
| Acceso web | Permitir que los agentes del navegador recopilen contexto público | ¿Puede el código resolver cualquier dominio o solo dominios aprobados? |
| Llamadas a APIs | Permitir que los agentes se integren con backends de aplicaciones | ¿Están bloqueados los dominios internos y los puntos finales de metadatos? |
| Herramientas de compilación | Permitir que los agentes de codificación ejecuten pruebas realistas | ¿Pueden los scripts posteriores a la instalación desencadenar búsquedas inesperadas? |
| Sesiones de larga duración | Permitir que los agentes continúen tareas de varios pasos | ¿Se conservan los registros de DNS durante todo el ciclo de vida de la sesión? |
El objetivo no es prohibir cada llamada de red. Muchas cargas de trabajo de agentes necesitan acceso de red controlado. El objetivo es saber qué rutas existen, cuáles están bloqueadas y qué evidencia tendría si una tarea se comportara de manera inesperada.
Dónde Aparece la Resolución DNS en los Flujos de Trabajo de los Agentes
Las revisiones de seguridad a menudo preguntan si un sandbox tiene acceso a Internet. Esa pregunta es demasiado amplia. Una mejor revisión comienza por mapear cada lugar donde el código, las herramientas, los gestores de paquetes o los navegadores pueden desencadenar la resolución de nombres.
Las rutas comunes de DNS incluyen:
- Solicitudes de código directas desde Python, JavaScript, scripts de shell, SDKs y suites de pruebas.
- Automatización del navegador que carga páginas, subrecursos, fuentes, imágenes, scripts de análisis y redirecciones.
- Gestores de paquetes como npm, pip, uv, pnpm, apt, cargo o instaladores de complementos específicos del lenguaje.
- Herramientas de compilación que obtienen binarios, plantillas, controladores de navegador, archivos de modelo o accesorios de prueba.
- Herramientas de agente que llaman a APIs de terceros o puntos finales de webhook.
- Trabajos en segundo plano que continúan ejecutándose después de que el paso visible del agente haya finalizado.
Ese mapeo debe incluir tanto el tráfico previsto como el incidental. Un desarrollador puede pedirle a un agente que ejecute una prueba unitaria, pero el comando de prueba puede instalar un paquete, el gestor de paquetes puede resolver un dominio de registro, y un script de ciclo de vida puede contactar con un host separado. Una tarea del navegador puede estar limitada a un sitio público, mientras que los recursos incrustados resuelven muchos dominios adicionales.
Para un proveedor de sandbox, la respuesta más sólida no es solo “el acceso a la red está disponible” o “el acceso a la red está aislado”. La respuesta útil explica la ruta de resolución:
- ¿El DNS del sandbox utiliza un resolvedor controlado por el proveedor, un resolvedor controlado por el cliente, un resolvedor de VPC o un resolvedor público?
- ¿Puede el cliente restringir dominios, rangos de IP, puertos o protocolos?
- ¿Se registran las solicitudes DNS por sandbox, por sesión, por comando o solo a nivel de red agregado?
- ¿Se registran las búsquedas denegadas, o solo las búsquedas permitidas?
- ¿Pueden los clientes separar el DNS de obtención de paquetes del DNS de tiempo de ejecución?
Si esos detalles no están disponibles, trátelos como elementos de evaluación abiertos, no como prueba de que el sandbox no es seguro. El riesgo práctico depende de la sensibilidad de la carga de trabajo, los secretos disponibles dentro del sandbox, la política de salida y la calidad de la evidencia forense.
Cómo Evaluar la Política de Salida
La política de salida es la superficie de control que decide si el DNS se convierte en una cuestión de rutina de infraestructura o en una ruta de escape no revisada. Una política madura debe responder a tres preguntas: qué está permitido, por qué está permitido y cómo se aprueban las excepciones.
Comience con la postura predeterminada. Un sandbox utilizado para código generado por IA no confiable no debería heredar el mismo acceso de red amplio que una computadora portátil de desarrollador. Si el valor predeterminado es la salida abierta, pregunte si el producto admite restringir ese acceso para cargas de trabajo de mayor riesgo. Si el valor predeterminado es la salida restringida, pregunte cómo los desarrolladores habilitan los dominios exactos necesarios para una tarea.
Luego, separe la política de DNS de la política de HTTP. Algunos sistemas aplican listas permitidas de HTTP pero dejan la resolución de nombres amplia. Esto puede crear un desajuste: una solicitud a un host no aprobado puede fallar en la capa HTTP, pero la consulta DNS aún sale del entorno y aún puede llevar metadatos en el nombre consultado. Un diseño más estricto evalúa la resolución y los intentos de conexión juntos.
Para las revisiones de seguridad, use una matriz de políticas como esta:
| Área de evaluación | Qué preguntar | Evidencia más sólida |
|---|---|---|
| Salida predeterminada | ¿El acceso a la red de salida está abierto, denegado o limitado por plantilla? | Política predeterminada por escrito más un resultado de prueba a nivel de sandbox |
| Ruta del resolvedor DNS | ¿Qué resolvedor maneja el DNS del sandbox? | Diagrama de arquitectura o prueba de configuración |
| Listas permitidas de dominios | ¿Pueden los equipos permitir solo registros y APIs aprobados? | Ejemplo de configuración y ejemplo de registro de denegación |
| Bloques de IP y red privada | ¿Están bloqueados los rangos internos y los servicios de metadatos de forma predeterminada? | Reglas de denegación documentadas y evidencia de prueba |
| Controles de protocolo | ¿Se controlan por separado DNS, HTTP, HTTPS y sockets sin procesar? | Modelo de política, no solo redacción de marketing |
| Flujo de trabajo de excepciones | ¿Quién puede agregar dominios o relajar la política? | Aprobación basada en roles y registro de auditoría |
Para la mayoría de los equipos, el primer objetivo práctico no es un entorno de salida cero perfecto. Es un perfil de salida mínima documentado: registros de paquetes aprobados, dominios de API aprobados, sin acceso a redes internas a menos que se enrute explícitamente, y registros tanto para intentos permitidos como denegados.
Obtención de Paquetes y DNS Impulsado por Dependencias
La instalación de paquetes es una de las formas más fáciles de subestimar la salida del sandbox. El código generado por el agente a menudo falla por dependencias faltantes, y la experiencia de desarrollo más rápida es permitir que el agente instale lo que necesita. Esa conveniencia crea un segundo problema de cadena de suministro: los nombres de los paquetes, las redirecciones de registro, los scripts de instalación y las descargas binarias pueden desencadenar actividad DNS y de red que el mensaje original nunca mencionó.
La guía de aplicaciones LLM de OWASP señala los riesgos en torno a la agencia excesiva y la exposición de la cadena de suministro. En los sandboxes de agentes, esos riesgos se encuentran en la instalación de paquetes. Un modelo puede tener permitido elegir comandos. Un comando puede invocar un gestor de paquetes. El gestor de paquetes puede obtener código de un registro. El paquete obtenido puede ejecutar hooks de instalación. Cada paso puede crear búsquedas DNS y conexiones salientes.
La evaluación defensiva debe centrarse en la gobernanza, no en la mecánica de explotación:
- Prefiera archivos de dependencias fijados para tareas de agente repetibles.
- Utilice registros aprobados o cachés de extracción para ecosistemas comunes.
- Registre el nombre del paquete, la versión, la URL del registro, los dominios resueltos y los hashes de artefactos cuando sea práctico.
- Separe el permiso de instalación de paquetes del acceso general a Internet en tiempo de ejecución.
- Requiera aprobación antes de instalar paquetes fuera de una lista permitida para espacios de trabajo sensibles.
- Considere plantillas de sandbox preconstruidas para pilas comunes para que los agentes no necesiten acceso de red amplio durante cada ejecución.
La distinción importante es que “obtención de paquetes” no es un control único. Incluye resolución DNS, autenticación de registro, descarga de artefactos, ejecución de código en tiempo de instalación y comportamiento de caché. Una buena revisión de sandbox pregunta sobre toda la ruta.
Secretos y Suposiciones de Exposición de Datos
La exfiltración por DNS solo importa si hay algo significativo que filtrar. Eso hace que la ubicación de los secretos y el alcance de los datos sean parte de la revisión de DNS.
Los sandboxes de agentes de IA deben tratarse como trabajadores de compilación no confiables a menos que se demuestre lo contrario. No coloque credenciales de producción de larga duración, tokens de nube amplios, datos de clientes o código fuente interno en un sandbox solo porque el sandbox está aislado del host. El aislamiento reduce el radio de la explosión, pero no hace que todos los comandos sean seguros.
Utilice estas suposiciones al diseñar flujos de trabajo de mayor riesgo:
- Cualquier archivo legible por el código ejecutado por el agente podría incluirse en registros, salidas, solicitudes de red o mensajes de error.
- Cualquier variable de entorno visible para un proceso podría ser copiada por ese proceso.
- Cualquier canal de salida permitido al sandbox merece la misma revisión de pérdida de datos, incluido el DNS.
- Cualquier instrucción inyectada por mensaje en un flujo de trabajo de navegador o documento puede intentar influir en el uso de la herramienta.
- Cualquier sesión de larga duración aumenta el valor de los registros del ciclo de vida y la caducidad de los tokens.
Los controles prácticos incluyen credenciales de corta duración, claves de API con privilegios mínimos, cuentas de servicio con alcance, secretos por tarea, registros redactados y separación explícita entre tareas de investigación de datos públicos y tareas de ejecución de código sensible.
Registros, Pistas de Auditoría y Evidencia de Incidentes
Los controles de DNS solo son útiles si los equipos pueden verificarlos. Cuando una tarea de sandbox es sospechosa, los equipos de seguridad necesitan evidencia rápidamente: qué se ejecutó, qué se resolvió, qué se conectó, qué archivos cambiaron y qué salidas se devolvieron.
Como mínimo, pregunte si la plataforma puede reconstruir estos eventos para una sesión de sandbox específica:
- Hora de creación del sandbox, plantilla, configuración de recursos y propietario.
- Comandos ejecutados por el agente o el usuario.
- Archivos leídos, escritos, cargados o descargados cuando el producto expone operaciones de archivos.
- Instalaciones de paquetes y obtenciones de registro.
- Consultas DNS, incluyendo marca de tiempo, nombre consultado, resultado e identificador de sandbox/sesión.
- Intentos de conexión saliente, incluyendo host de destino, IP, puerto, protocolo, resultado de permitir/denegar y volumen cuando esté disponible.
- Llamadas a herramientas, eventos de navegación del navegador y procesos en segundo plano.
- Eventos de inyección de secretos sin exponer los valores de los secretos en los registros.
- Eventos de finalización, pausa, reanudación, instantánea y limpieza de la sesión.
No solo pregunte por los registros de tráfico exitoso. Los eventos denegados suelen ser más útiles para evaluar si la política funcionó. Si un sandbox intenta resolver un dominio no aprobado y la política lo bloquea, esa búsqueda denegada es la evidencia que separa un control funcional de un fallo silencioso.
La retención también importa. Una ventana de registro de siete días puede ser suficiente para la depuración, pero débil para la respuesta a incidentes. Los equipos con cargas de trabajo reguladas o sensibles para el cliente deben alinear la retención de telemetría del sandbox con su política de registro de seguridad más amplia.
Notas de Evaluación de Novita Agent Sandbox
Novita Agent Sandbox está diseñado para flujos de trabajo de agentes de IA que necesitan ejecución de código aislada, automatización del navegador, tareas de tipo “uso de computadora”, sesiones de larga duración y cargas de trabajo de evaluación o aprendizaje por refuerzo. La descripción general de Novita Agent Sandbox es el punto de partida adecuado para el comportamiento actual del producto, y la página de producto de Agent Sandbox describe el encaje más amplio de la plataforma.
Al evaluar Novita o cualquier otro proveedor de sandbox para cargas de trabajo sensibles a DNS, separe dos tipos de afirmaciones:
- Ajuste del producto: si el sandbox admite el flujo de trabajo del agente que necesita, como ejecución de código, automatización del navegador o tareas de larga duración.
- Evidencia de control de seguridad: si los controles exactos de DNS, salida, obtención de paquetes, secretos y registro cumplen con su política interna.
Esa separación evita afirmaciones excesivas. Un sandbox puede ser un buen ajuste para la ejecución del agente y aún así requerir una revisión específica del cliente para la política de DNS, la ruta del resolvedor, las listas permitidas, la retención de auditoría y los flujos de trabajo de incidentes. Los equipos de seguridad deben solicitar documentación actual o confirmación del producto para esos detalles de control antes de aprobar cargas de trabajo sensibles.
Para los equipos que ya utilizan modelos de Novita AI, el ajuste de la plataforma es que las APIs de modelos y la infraestructura de ejecución del agente se pueden evaluar juntas. Esto puede reducir la dispersión operativa, pero no elimina la necesidad de un modelo de amenazas. Trate el sandbox como un entorno de ejecución controlado, defina qué acceso de red necesita cada clase de agente y valide que la evidencia de control coincida con el riesgo de los datos colocados en su interior.
Lista de Verificación de Revisión de Seguridad
Utilice esta lista de verificación antes de aprobar cargas de trabajo de sandbox de agentes de IA que puedan tocar código sensible, credenciales, datos de clientes o sistemas internos.
| Pregunta de revisión | Por qué es importante |
|---|---|
| ¿Qué puede resolver el sandbox de forma predeterminada? | El DNS puede ser una señal de salida incluso cuando HTTP está bloqueado. |
| ¿Se puede restringir el DNS por dominio, plantilla, espacio de trabajo o política de VPC? | Los flujos de trabajo sensibles necesitan valores predeterminados más estrictos que las tareas de investigación pública. |
| ¿Se registran las consultas DNS por sesión de sandbox? | La respuesta a incidentes necesita atribución, no solo métricas de resolvedor agregadas. |
| ¿Se registran las consultas DNS y los intentos de conexión denegados? | Los eventos denegados prueban que la política bloqueó un comportamiento inesperado. |
| ¿Están los registros de paquetes en una lista permitida o proxy? | Los gestores de paquetes pueden desencadenar DNS y descargas impulsadas por dependencias. |
| ¿Se pueden separar las instalaciones de paquetes del acceso a la red en tiempo de ejecución? | El riesgo en tiempo de compilación y en tiempo de ejecución son diferentes. |
| ¿Están bloqueados los rangos de IP internos y los puntos finales de metadatos? | Los agentes no deberían descubrir ni contactar planos de control de infraestructura por accidente. |
| ¿Cómo se inyectan, delimitan, rotan y redactan los secretos? | La revisión de DNS está incompleta si hay secretos de larga duración disponibles para el código en el sandbox. |
| ¿Son visibles los subrecursos del navegador en los registros? | Los agentes del navegador pueden resolver más dominios que la URL de nivel superior. |
| ¿Qué evidencia está disponible después de pausar, reanudar, tomar una instantánea o limpiar? | Las sesiones de larga duración necesitan telemetría consciente del ciclo de vida. |
| ¿Quién puede relajar la política de salida? | Los cambios de excepción deben ser auditables. |
| ¿Cómo se preservan las sesiones sospechosas? | La limpieza no debería borrar la única evidencia útil del incidente. |
Si varias respuestas son desconocidas, mantenga la carga de trabajo fuera del sandbox hasta que el proveedor o el equipo de la plataforma interna puedan documentar la ruta de control. Si la carga de trabajo solo maneja datos públicos y no utiliza secretos, las mismas brechas pueden ser aceptables durante la creación de prototipos tempranos, pero aún deben rastrearse antes del uso en producción.
Conclusión
Para los sandboxes de agentes en producción, revise el DNS como parte de la salida, no como una nota al pie. La configuración mínima defendible es una política de salida con alcance, gobernanza explícita de obtención de paquetes, secretos de corta duración, registros de DNS y conexión por sesión, y un flujo de trabajo de incidentes probado para preservar la evidencia.
Utilice un acceso de red más amplio solo para prototipos de bajo riesgo cuando los datos no sean sensibles y el agente no tenga secretos significativos. Para bases de código sensibles, datos de clientes, APIs internas o flujos de trabajo regulados, requiera un perfil de salida mínima y evidencia actual del proveedor antes de otorgar a los agentes ejecución autónoma.
Preguntas Frecuentes
¿Es relevante la exfiltración por DNS si el sandbox bloquea HTTP?
Sí. Los controles de HTTP y los controles de DNS son capas diferentes. Un sandbox puede bloquear solicitudes web salientes mientras aún permite consultas DNS. Los equipos de seguridad deben verificar tanto la política de resolución como la política de conexión.
¿Deberían los sandboxes de agentes de IA no tener acceso a Internet?
No siempre. Muchas tareas útiles de agentes necesitan registros de paquetes, documentación pública, APIs o acceso al navegador. El objetivo más seguro es una salida mínima y explicable: permitir lo que la tarea necesita, denegar lo que no, y registrar tanto la actividad permitida como la denegada.
¿Son las instalaciones de paquetes lo mismo que el acceso general a la red?
No. Las instalaciones de paquetes merecen una política separada porque involucran registros, resolución de dependencias, descargas de artefactos y, a veces, scripts en tiempo de instalación. Un equipo puede permitir obtenciones de paquetes a través de una caché aprobada mientras deniega la salida arbitraria en tiempo de ejecución.
¿Qué registros son más importantes para el riesgo de DNS?
Los registros más útiles conectan una consulta DNS con un sandbox, comando, hora, flujo de trabajo de usuario o agente, y decisión de política específicos. Los registros de búsquedas denegadas son especialmente importantes porque muestran si el control realmente funcionó.
¿Puede un proveedor de sandbox garantizar que no haya exfiltración de datos?
Tenga cuidado con las garantías absolutas. Un proveedor puede ofrecer aislamiento, controles de red, registro y opciones de configuración, pero el riesgo final depende del diseño de la carga de trabajo, los secretos, la ubicación de los datos, la política de salida y la supervisión operativa.
