DeepSeek V4 Pro no es una frontera de seguridad: el arnés también cuenta

Las organizaciones que desplieguen agentes basados en DeepSeek V4 Pro deberían evaluar una configuración completa de modelo–arnés–tarea–entorno, y no el modelo de forma aislada.

Que un modelo esté disponible a través de la web, una aplicación móvil, una API, la Responses API de OpenAI o una integración con Codex puede demostrar compatibilidad de interfaz. Pero no demuestra que los prompts, las herramientas, los permisos, la memoria, los reintentos o los efectos secundarios funcionen igual en todos esos entornos.

La regla operativa es clara: solo debe aprobarse una configuración concreta y fijada después de que esa misma configuración supere su propia evaluación de seguridad.

El arnés define al agente efectivo

Un agente es más que el modelo que genera sus respuestas. El arnés —la capa que coordina sesiones, herramientas y ejecución— determina cómo recibe instrucciones, consulta datos, gestiona errores y puede modificar sistemas externos.

Entre las diferencias con impacto en seguridad pueden estar:

• los prompts de sistema y los adaptadores de compatibilidad;
• las definiciones e implementaciones de las herramientas;
• los permisos, sus alcances y los controles de aprobación;
• las raíces del sistema de archivos y el acceso de red;
• el origen de las credenciales y la identidad utilizada;
• la ejecución de subprocesos y de código generado;
• la lógica de reintentos, tiempos de espera y concurrencia;
• el estado de sesión, los resúmenes, las cachés y la memoria persistente.

Por eso, el mismo backend de DeepSeek V4 Pro puede tener un perfil de riesgo distinto cuando se conecta a otro arnés o entorno de ejecución. Un esquema de API compatible es una propiedad de integración, no una certificación de seguridad.

Qué muestran los resultados de AgentS4D —y qué no muestran—

AgentS4D evaluó configuraciones completas de ejecución, no respuestas aisladas del modelo. El benchmark utilizó 328 casos con riesgos inyectados en cuatro arneses y cinco backends de modelos, para un total de 6.560 ejecuciones en sandbox. Registró 4.461 ejecuciones inseguras, el 68,0 %, y 4.344 ejecuciones, el 66,22 %, que fueron simultáneamente inseguras y consideradas completas. 13

El hallazgo central es incómodo pero importante: una ejecución puede completar la tarea y, aun así, ser insegura. El agente puede entregar el archivo solicitado mientras realiza un cambio prohibido, expone o manipula mal datos sensibles, sortea un control previsto o provoca otro efecto secundario peligroso.

Estas cifras no deben presentarse como la tasa de incidentes de DeepSeek V4 Pro en producción. La evaluación empleó casos diseñados deliberadamente para introducir riesgos, dentro de un sandbox controlado, y agrupó resultados de varias combinaciones de modelo y arnés. En producción cambiarán la mezcla de tareas, los controles, la exposición a contenido adversarial, los activos disponibles y la definición de daño. El benchmark demuestra que la seguridad del entorno debe medirse directamente; no predice lo que ocurrirá en cada despliegue. 135

Reducir la magnitud máxima de un error

Los controles de seguridad deben limitar las consecuencias incluso si el modelo o una herramienta se comportan de forma inesperada.

Usar identidades independientes y privilegios mínimos

Cree identidades separadas para cada agente, entorno y organización usuaria. Evite las credenciales implícitas de empleados, el acceso de administrador en producción y los secretos reutilizables de alcance amplio. Cada identidad debe limitarse a los recursos y operaciones necesarios para un trabajo específico.

Restringir sistemas de archivos y redes

• Monte únicamente una raíz de trabajo dedicada.
• Haga inaccesibles las rutas no relacionadas; no se limite a ocultarlas.
• Permita solo destinos, métodos, puertos y, cuando sea relevante, volúmenes de salida de red previamente autorizados.
• Separe las capacidades de lectura, borrador, escritura en pruebas y escritura en producción.
• Guarde los secretos en un intermediario seguro o en un sistema de tokens de corta duración.
• Nunca coloque credenciales de larga duración en prompts, archivos del espacio de trabajo, variables de entorno o resultados de herramientas.

Las acciones de alto impacto —como borrar datos, publicar contenido, efectuar pagos, cambiar accesos, desplegar software o enviar comunicaciones externas— deben pasar por una comprobación de políticas en la capa de ejecución o requerir una aprobación explícita.

Revisar toda la cadena de ejecución

Las herramientas propias son solo una parte de la superficie de ataque. Los procesos secundarios, comandos de shell, código generado, instalación de paquetes, servidores de herramientas remotos, plugins y código de habilidades también pueden producir efectos externos.

La misma política debe aplicarse a todos esos caminos. En particular, hay que impedir que el shell o el código generado eludan los controles de sistema de archivos, red, autorización, registro y aprobación.

Diseñar herramientas que se hagan cumplir fuera del modelo

Una llamada a una herramienta generada por el modelo debe tratarse como una solicitud no confiable. El servidor de la herramienta —no el modelo— debe hacer cumplir las reglas de autorización y seguridad.

Conviene utilizar esquemas estrechos, con controles como:

• valores enumerados y límites de longitud;
• rutas normalizadas e identificadores explícitos de recursos;
• listas de destinos autorizados;
• límites de paginación y del tamaño de los resultados;
• validación de argumentos fuera del modelo;
• autorización en el servidor para el usuario, la organización, el objetivo y la operación concretos.

Separe las herramientas de planificación o vista previa de las herramientas que producen efectos. Para operaciones destructivas o difíciles de revertir:

• exija una vista previa y una confirmación o un token de aprobación;
• prefiera el borrado lógico, la cuarentena o flujos reversibles;
• exija claves de idempotencia;
• defina qué sucede si se repite la misma solicitud;
• devuelva comprobantes persistentes para que un reintento no repita el efecto.

Estas medidas son necesarias porque una llamada JSON con formato válido puede contener un objetivo no autorizado, una ruta peligrosa, un alcance excesivo o una operación que debería requerir revisión humana.

Definir el estado y la memoria antes del despliegue

El estado puede trasladar riesgos entre turnos, tareas, usuarios y entornos. Las organizaciones deben documentar y hacer cumplir el ciclo de vida de los mensajes, archivos subidos, archivos del espacio de trabajo, resúmenes, resultados de herramientas, cachés y memoria persistente.

Como mínimo, hay que especificar:

• Aislamiento: separar el estado por usuario, organización, tarea y entorno; no permitir el intercambio implícito entre sesiones.
• Retención: definir el tiempo de vida, el cifrado, los controles de acceso y las reglas de eliminación.
• Restablecimiento: ofrecer un procedimiento documentado para borrar el contexto, la memoria, el estado del espacio de trabajo, las credenciales y las cachés entre ejecuciones.
• Reintentos y tiempos de espera: fijar cantidades y presupuestos máximos; los reintentos deben conservar la idempotencia y no ampliar privilegios silenciosamente.
• Concurrencia: establecer bloqueos y reglas para resolver conflictos en archivos compartidos, aprobaciones y operaciones externas.

El comportamiento de restablecimiento del estado forma parte de la frontera de seguridad. Si instrucciones antiguas, credenciales o resultados de herramientas pueden reaparecer inesperadamente en una tarea nueva, una actualización del modelo o un cambio de prompt puede modificar el riesgo de maneras que las pruebas centradas solo en respuestas no detectarán.

Tratar todas las fuentes de riesgo como entradas no confiables

La inyección de prompts no tiene que llegar en el mensaje directo del usuario. Las instrucciones peligrosas pueden estar incrustadas en:

• documentos subidos y archivos de repositorios;
• páginas web recuperadas;
• habilidades y plugins externos;
• respuestas de servicios de herramientas;
• memoria persistente;
• resúmenes y contexto almacenado en caché;
• texto proporcionado por el usuario.

Ese material debe analizarse, etiquetarse y citarse como datos. No se le debe permitir cambiar la autoridad del agente, sus políticas, la selección de herramientas, el uso de credenciales o los requisitos de aprobación. Esa separación debe imponerla el entorno de ejecución, no depender únicamente de que el modelo reconozca una instrucción maliciosa.

Lista de comprobación específica del arnés

Antes de aprobar un despliegue, congele y registre la configuración exacta:

1. Modelo y enrutamiento: identificador y versión del modelo, ruta del proveedor, parámetros de inferencia o nivel de esfuerzo y adaptadores de compatibilidad.
2. Comportamiento del arnés: versión del arnés, prompt de sistema, lógica de sesión, reglas de reintento y tiempo de espera, política de subprocesos e implementación de memoria.
3. Herramientas y políticas: definiciones y versiones de herramientas, versiones de políticas, umbrales de aprobación, lógica de autorización y fronteras de confianza de los servidores de herramientas.
4. Permisos: identidades, alcances, raíces del sistema de archivos, destinos de red, fuentes de credenciales y rutas de escritura en producción.
5. Semántica del estado: aislamiento, retención, restablecimiento, comportamiento de caché, concurrencia y límites entre sesiones.
6. Cobertura adversarial: inyección de prompts a través de cada fuente de riesgo, intentos de confusión de autoridad, exposición de credenciales, traversal de rutas, SSRF o abuso de salida de red, respuestas maliciosas de herramientas, duplicación por reintentos, envenenamiento de memoria y elusión de aprobaciones.
7. Evidencia: versiones de prompts y políticas, llamadas y resultados de herramientas, aprobaciones, decisiones de políticas, diferencias del espacio de trabajo, solicitudes salientes, identidad utilizada, artefactos finales, resultado de finalización y resultado de seguridad bajo un identificador de ejecución estable.

Mida finalización y seguridad por separado. Un artefacto final correcto no debe compensar un efecto secundario inseguro: esa es precisamente la lección central de los resultados de AgentS4D. 12

Repetir las pruebas cuando cambie la configuración

El objetivo aprobado es la configuración fijada, no una etiqueta permanente como «agente de DeepSeek V4 Pro». La batería específica debe repetirse después de cualquier cambio importante en:

• el modelo o la ruta del proveedor;
• los parámetros de inferencia o el nivel de esfuerzo;
• el prompt de sistema o el adaptador;
• el arnés o la lógica de sesión;
• las herramientas o los servidores de herramientas remotos;
• las políticas de permisos y aprobación;
• el enrutamiento de credenciales;
• la memoria, los reintentos, los tiempos de espera o la concurrencia;
• los límites de red o del sistema de archivos.

Este enfoque convierte la seguridad del tiempo de ejecución en una decisión de lanzamiento medible, vinculada al entorno exacto que puede producir efectos en el mundo real.