La Divulgación de Ciberevaluación de OpenAI Nombró la Cosa que Todos Hemos Estado Ignorando
La divulgación de OpenAI sobre incidentes de ciberevaluación de terceros no es un escándalo sobre modelos fronterizos—es prueba de una brecha que todos enfrentamos. Evaluadores autorizados con acceso legítimo extrajeron capacidades y descubrieron jailbreaks durante pruebas de seguridad "seguras". El patrón es claro: cuando le das a los evaluadores infraestructura adyacente a producción y credenciales, les estás entregando las llaves del reino, contrato o no. Y si sucede en un laboratorio con recursos para monitorear millones de tokens, está sucediendo más rápido en tiendas como la nuestra que envían agentes a producción.
La generalización es directa. Cada equipo que externaliza red-teams a Scale AI, socios académicos o firmas de bug-bounty está ejecutando este mismo riesgo. Tus evaluadores—autorizados o no—ahora son parte de tu superficie de ataque. Nos hemos equivocado antes. El instinto es tratar la evaluación como QA: una tarea necesaria que externalizas para mantener los costos bajos. Pero la infraestructura de evaluación es un límite de seguridad de inquilino hostil, ya sea que lo llames así o no.
La Superficie de Ataque No es el Modelo — Es Todo lo que Rodea el Prompt
Los pesos del modelo importan menos que lo que los rodea. Un evaluador con acceso a tu agente de staging puede extraer capacidades a través de puntos de fuga que probablemente no hayas asegurado. Los prompts del sistema y esquemas de herramientas aparecen en mensajes de error, en respuestas 4xx, a veces en los propios rastros de razonamiento del agente. Esa es extracción pasiva. La extracción activa es peor: el evaluador sondea tus índices de recuperación, tu réplica Postgres, tu egreso HTTP, tu ejecución de código en sandbox—todo lo que un agente puede tocar, un evaluador puede tocar, y todo lo que tocan es un vector de exfiltración potencial.
Piensa en tu propio stack. Corpus RAG, almacenes de vectores, esquemas Postgres, claves Redis, credenciales de API—si un evaluador tiene una superficie de llamada de herramienta que los alcanza, puede usar tu agente como una sonda. Los registros y paneles de observabilidad como LangSmith, Langfuse o Braintrust se convierten en caminos de exfiltración secundarios. Hemos visto equipos compartir claves de API de prod entre entornos de staging y eval, reutilizar credenciales con alcances de prod, y apuntar ejecuciones de eval a índices de recuperación en vivo. Las categorías del OWASP LLM Top 10 que importan aquí son inyección de prompts, divulgación de información sensible y agencia excesiva. Las tres están integradas en la infraestructura de eval que la mayoría de los equipos ejecutan hoy.
Separa Tenants de Eval Agresivamente — Hasta la Credencial
El aislamiento comienza con límites duros. Un proyecto de AWS o GCP por compromiso de evaluador, nunca compartido con staging o prod. IDs de organización y claves de API separadas de OpenAI y Anthropic para cada evaluador, con límites de gasto por clave y límites de velocidad que dispararán una alarma si un agente jailbroken intenta agotar el presupuesto en una hora. Esto importa porque el primer signo de un jailbreak exitoso a menudo es una anomalía de costo.
Los alcances de herramientas se degradan agresivamente. Réplicas de Postgres de solo lectura en lugar de bases de datos de prod. Egreso HTTP simulado para que un agente jailbroken no pueda llamar a un webhook controlado por atacante. Ejecución de código en sandbox a través de Modal, E2B o Fly Machines—nunca sistema de archivos compartido, nunca estado persistente entre ejecuciones. Espacios de nombres de almacén de vectores por tenant; nunca apuntes un eval a tu índice Pinecone o pgvector de prod. Listas de permitidos de egreso a nivel de red para que incluso si el agente rompe el confinamiento, solo pueda alcanzar servicios que hayas preaprobado. Cuando el compromiso se cierre, rota todo—trátalo como una respuesta a incidentes. Nuevas claves, nuevos proyectos, nuevas credenciales, de principio a fin.
Instrumenta el Loop de Eval Como Instrumentarías una Brecha
La observabilidad en un loop de eval debe ser consciente del adversario, no solo consciente de la precisión. Registra cada prompt de eval y cada llamada de herramienta en un flujo de auditoría de solo anexión separado de la telemetría de prod. Las señales de detección importan: cambios repentinos en la distribución de tokens de prompt, secuencias de sonda casi duplicadas repetidas, patrones de llamadas de herramientas que no coinciden con los personas de usuario que estás probando. Hemos enviado filtrado de seguridad por decisión en Nemotron; la misma disciplina se aplica aquí.
Planta tokens canario en prompts del sistema y documentos RAG para que puedas detectar extracción después del hecho, incluso si no lo atrapaste en tiempo real. Alarmas de presupuesto—los picos de costo repentinos son una señal de jailbreak. Cada ejecución de eval debe ser reproducible solo desde registros de auditoría, sin brechas. Y cuando un canario se dispara o una alarma se activa, avisa a tu equipo, no al proveedor de eval. Haz que el incidente sea tuyo para poseer.
Reescribe el Contrato del Evaluador Antes de Firmarlo
El trabajo legal y de alcance es la mitad de la defensa. Los documentos de alcance deben enumerar superficies de herramientas permitidas, no solo prompts permitidos. Toma prestadas reglas de compromiso de contratos de pentest: ventanas de divulgación, sin movimiento lateral, sin retención de datos después del cierre del compromiso. Incluye una cláusula explícita de que las capacidades extraídas y los jailbreaks exitosos son hallazgos confidenciales, no artefactos publicables sin tu revisión y aprobación.
Asegura el manejo de datos: dónde viven las transcripciones de eval, quién tiene acceso, quién entrena con ellas, cómo y cuándo se destruyen. Antes de firmar con cualquier proveedor de eval, haz estas preguntas: ¿Puedes garantizar que este tenant de eval está aislado de tu otro trabajo de cliente? ¿Cuál es tu respuesta a incidentes si encontramos acceso no autorizado? ¿Ejecutas detección de tokens canario o patrones en tus ejecuciones de eval? ¿Cuál es tu política de retención de datos? ¿Quién es propietario de los derechos de los jailbreaks que encontramos? Estos no son nice-to-haves. A medida que más de la industria externaliza evals a terceros, son table stakes.
Lo Que Esto Cambia Sobre Cómo Envías el Próximo Agente
Eval-como-superficie-de-ataque remodela tu lista de verificación previa al lanzamiento. Añade una puerta dura: ¿Puedes apuntar un evaluador adversarial a este agente sin tocar la infraestructura de prod? Si la respuesta es no, no envíes aún. La minimización de capacidades es tu amiga—cada herramienta que no expongas es una superficie de jailbreak que no tienes que defender. Hemos encontrado que el costo de retrofitting aislamiento dos semanas antes del lanzamiento es brutal. Constrúyelo desde el primer día.
Esto se sienta junto a modos de fallo de RAG en producción y filtrado de seguridad por decisión como parte de tu historia más amplia de confiabilidad de agentes. Ayudamos a los equipos a establecer tenants de eval aislados con credenciales separadas, instrumentar flujos de auditoría y arneses de red-team antes de que evaluadores externos obtengan acceso. Si estás enviando un agente y quieres revisar tu configuración de eval antes de tu próximo compromiso de red-team, contáctanos en /contact.
Primera Semana: La Lista de Verificación
Activa un tenant de eval aislado con sus propias claves de API e IDs de proyecto. Limpia todas las credenciales de herramientas de prod de los alcances de eval—degrada a solo lectura, en sandbox, simulado. Registra cada prompt de eval y llamada de herramienta en un flujo de auditoría de solo anexión separado. Planta canarios en prompts del sistema. Establece alarmas de presupuesto. Si estás ejecutando evals externos en el próximo mes, audita tus contratos contra las preguntas anteriores y cierra las brechas antes de las firmas. El objetivo no es seguridad perfecta—es asegurarse de que cuando (no si) un evaluador encuentra algo, lo encuentres primero.