OpenAI DevDay 2026: todas las novedades del stack de agentes

OpenAI DevDay 2026, celebrado el 29 de septiembre, presentó agentes Dots siempre activos, el modelo GPT-6.1 Sol, Codex Cloud, compatibilidad con MCP Events y una plataforma de plugins más amplia, entre más de 20 anuncios. En conjunto, convierten ChatGPT y Codex en un stack de agentes que actúa en sistemas conectados y sitúa los permisos y las entradas no confiables en el centro de la seguridad de aplicaciones.

Los anuncios de OpenAI DevDay apuntan a un cambio en la forma de operar del software de IA. Ahora, un modelo puede formar parte de un flujo de trabajo más largo: recibir un objetivo, reunir contexto de aplicaciones conectadas, usar un navegador o un entorno de programación y continuar cuando llega trabajo nuevo. El resumen de DevDay abarca novedades para consumidores, desarrolladores y empresas, pero el hilo común es un agente que puede actuar en distintos sistemas. Algunos anuncios son lanzamientos nuevos, otros amplían productos existentes y varios son avances preliminares.

Esto permite automatizaciones útiles. También convierte los permisos, las entradas no confiables y las pruebas de lo que realmente hizo un agente en cuestiones centrales de la seguridad de aplicaciones.

Ilustración original de Plexicus del stack de agentes anunciado; no es una captura de un producto de OpenAI.

Agentes persistentes y trabajo conectado

Dots son los agentes siempre activos de OpenAI. Cada dot tiene un ordenador en la nube, un navegador, contexto persistente y acceso a aplicaciones conectadas, sujeto a los permisos y aprobaciones configurados. OpenAI describe la investigación proactiva como trabajo de fondo de solo lectura; otras acciones dependen de los permisos más amplios del dot. Esta distinción importa: observar un problema nuevo, preparar un cambio y ejecutar ese cambio no deberían depender del mismo permiso.

OpenAI también ha descrito dots especializados con identidades organizativas y acceso dedicado. Esta es una línea piloto, no una flota empresarial disponible de forma general. Si tu equipo está considerando agentes persistentes, cada identidad debería tener un responsable definido, acceso limitado y un registro de sus acciones. Un modelo de amenazas por capas como OWASP MAESTRO para IA agéntica ayuda a ubicar cada control.

GPT-6.1 Sol aporta otra pieza del stack. OpenAI lo posiciona para programación, uso del ordenador y flujos de trabajo más largos (documentación del modelo). Un menor coste por tarea puede hacer viables las ejecuciones repetidas de agentes, pero un modelo capaz no demuestra que su salida sea segura ni que sus acciones estén autorizadas.

Modelos más rápidos e infraestructura privada

OpenAI también amplió Ultrafast, un nivel prémium de velocidad. En DevDay indicó hasta 300 tokens por segundo para GPT-6 Astra Ultrafast, y que GPT-6.1 Sol Ultrafast llegará más adelante (resumen de DevDay). Son cifras de rendimiento de OpenAI, no una predicción para todas las cargas de trabajo. La velocidad importa porque un agente puede realizar decenas de pasos secuenciales de razonamiento y uso de herramientas. Reducir la latencia de cada paso puede hacer que el flujo de trabajo parezca interactivo. No elimina la necesidad de comprobar el resultado.

Los anuncios de privacidad responden a otra limitación. Zero Data Retention with Private Safety Processing se describe para clientes de API que cumplen los requisitos y necesitan un procesamiento de seguridad automatizado sin que OpenAI conserve las instrucciones y respuestas; la arquitectura puede usar almacenamiento en la nube gestionado por el cliente. Private Inference se presentó como una función futura, con computación confidencial y controles verificables en el diseño propuesto. Antes de considerar una versión preliminar como una garantía vigente sobre el tratamiento de datos, los equipos deberían revisar el servicio y el contrato que realmente tienen disponibles. Esto es relevante cuando los agentes pueden leer código fuente, mensajes internos y datos de clientes.

De las sesiones de programación al trabajo de software continuo

Codex Cloud ofrece a los agentes de programación entornos reutilizables en la nube. Junto con la revisión de código y Codex Security Cloud, apunta a un flujo de trabajo en el que los agentes inspeccionan un repositorio, proponen cambios, ejecutan comprobaciones y revisan hallazgos de seguridad sin depender del portátil abierto de un desarrollador.

El límite de seguridad abarca el repositorio y los sistemas que lo rodean: código fuente, dependencias, secretos, CI, incidencias y pull requests. Un parche generado por un agente sigue necesitando que se revise el comportamiento que modifica; nuestro análisis de las vulnerabilidades en pull requests generadas por IA explica por qué. Una prueba superada dice algo sobre los casos probados; no demuestra que todas las rutas de autorización o todos los endpoints expuestos sean seguros.

La Codex CLI renovada añade control por voz, una vista /agents y mejoras para seguir y reanudar varias tareas de agentes (resumen de DevDay). El cambio operativo importante es que una persona puede supervisar varios agentes a la vez. Por eso, la responsabilidad sobre cada tarea y la procedencia de cada cambio de código importan más que la interfaz con la que se inicia.

La experiencia de escritorio de Code Review incorpora resúmenes, diffs, preguntas y revisión en la nube al flujo de trabajo del desarrollador. La revisión automática en la nube depende de que el repositorio esté conectado y configurado. Codex Security Cloud puede analizar los repositorios conectados cuando se solicite o según un calendario, investigar hallazgos y preparar correcciones mientras el equipo local está desconectado. Son opciones útiles para acortar el ciclo de feedback, pero los hallazgos siguen necesitando pruebas de alcanzabilidad e impacto: esa es la brecha que Deep Code Analysis pretende cerrar. Las correcciones propuestas deben volver a probar el comportamiento que modifican, como se explica en nuestro playbook de remediación autónoma.

La guía de uso del ordenador de Agents API añade otra interfaz. Cuando un agente puede hacer clic en aplicaciones, una página visible se convierte en contexto para la tarea y también puede transmitir instrucciones maliciosas. Limita las sesiones del navegador a su propósito, restringe aquello a lo que pueden acceder y exige una revisión antes de realizar cambios importantes.

La Agents API más amplia reúne orquestación, uso de herramientas, gestión de contexto, conexiones MCP y sandboxes en una sola superficie de desarrollo. OpenAI aloja el navegador para el uso del ordenador, pero la aplicación del desarrollador sigue controlando el acceso a los sitios y el flujo de trabajo circundante. La Decisions API, anunciada en vista previa limitada, adopta un enfoque más acotado: los desarrolladores le dan un conjunto finito de respuestas permitidas y el modelo elige entre ellas (resumen de DevDay). Las salidas limitadas pueden ayudar con el enrutamiento o la clasificación, pero una respuesta elegida por el modelo no debería autorizar por sí sola una operación sensible.

El resumen de DevDay también destaca Amazon Bedrock Managed Agents powered by OpenAI. Se trata de una ampliación de una colaboración anterior con AWS, no de una tecnología que apareciera por primera vez en DevDay. AWS describe identidad, memoria, capacidad de cómputo, controles de seguridad y registros de auditoría de los agentes dentro de su infraestructura. Las empresas que lo adopten aún deben vincular esos controles con sus propios permisos y procesos de revisión.

MCP Events añade una vía de entrada

OpenAI está añadiendo compatibilidad con la especificación propuesta de MCP Events. En lugar de consultar un servicio periódicamente, ChatGPT puede suscribirse a eventos de un servidor MCP. OpenAI documenta la entrega de webhooks firmados, identificadores de eventos, filtros, comprobaciones de autorización y protecciones contra bucles de retroalimentación.

Un evento puede ser útil: un nuevo informe de error podría iniciar una investigación y un borrador de corrección. Pero el contenido del evento se origina fuera del límite de instrucciones del agente. Un informe falsificado o redactado con intención maliciosa debe seguir siendo un dato de la tarea, incluso si llega por un webhook válido. La autenticación demuestra qué servicio envió el evento; no convierte cada frase del contenido en una instrucción segura.

Ilustración original de Plexicus de un flujo de trabajo con MCP Events; no es una captura de un producto de OpenAI.

Los plugins y sus extensiones de interfaz amplían esta vía. Un plugin puede ofrecer herramientas, datos y superficies interactivas a un agente. Revisa los permisos solicitados, el proveedor, el tratamiento de datos y las acciones de escritura como harías con cualquier otra integración de software (guía de seguridad de plugins de OpenAI).

La documentación de plugins de OpenAI describe ahora paquetes que combinan skills, un servidor MCP, una interfaz y conexiones externas. Plugin Extensions puede ofrecer barras laterales, paneles, editores, formularios y contexto compartido con una conversación. Plugin Creator y un proceso de envío renovado buscan facilitar la creación y publicación; OpenAI describe un directorio compartido entre ChatGPT y Codex. Un canal de distribución más amplio también aumenta la importancia de verificar el software y los permisos que hay detrás de un cómodo botón de instalación.

Sites puede alojar plugins compatibles, así que una página compartida con IA puede ofrecer capacidades conectadas a varias personas. La página puede ser común, pero los datos y las acciones de cada usuario deben seguir sujetos a sus propios permisos. Para los desarrolladores, esta es una opción de alojamiento de aplicaciones. Para los equipos de seguridad, es otro lugar donde revisar el límite entre el contexto compartido y la autoridad individual (resumen de DevDay).

Space convierte el stack en trabajo compartido

ChatGPT Space es el espacio de OpenAI para páginas, archivos, hojas de cálculo, presentaciones y agentes. Pages permite que personas y agentes editen juntos un documento que puede usar contexto conectado y actualizarse con el tiempo. Las diapositivas colaborativas se presentaron como una función futura, con generación, edición, comentarios y exportación. Una página compartida que se actualiza desde herramientas resulta útil, pero sus fuentes de datos, instrucciones de actualización y audiencia deben estar visibles para sus responsables.

Teams y Team Tasks incorporan el trabajo programado o iniciado por eventos a un entorno organizativo compartido. OpenAI también planea @ChatGPT en Slack y Microsoft Teams, donde un agente podrá participar en un canal o hilo con herramientas aprobadas y los permisos pertinentes de los usuarios (resumen de DevDay). Esto reduce la fricción entre conversar y actuar. También plantea una pregunta directa: ¿a quién pertenecen los permisos de una solicitud en una conversación grupal?

El plugin Meetings puede convertir una conversación grabada en notas y tareas en la aplicación de macOS y después iniciar trabajos de seguimiento. OpenAI afirma que el audio de la reunión se elimina cuando las notas están listas. Aun así, los equipos deberían considerar el consentimiento, cuánto tiempo conservar las notas resultantes y si una sugerencia verbal debe convertirse en una tarea ejecutable. Los perfiles compartibles facilitan descubrir determinados trabajos; los controles de uso compartido del espacio de trabajo siguen definiendo quién puede verlos.

Identidad, planes y distribución

Sign in with ChatGPT permite a usuarios que cumplen los requisitos usar el consumo de su plan en aplicaciones de terceros participantes, con controles para asignar una cuota a cada aplicación (ayuda de OpenAI). Así, ChatGPT se convierte tanto en una opción de inicio de sesión como en una fuente portátil de consumo. La revisión de seguridad es conocida: identifica al tercero, comprueba los accesos concedidos y ten claro cómo revocarlos.

Pro 500 es el nuevo plan individual de alto consumo, con acceso a Astra Ultrafast cuando sea compatible. OpenAI Marketplace permite que empresas que cumplen los requisitos destinen parte de su compromiso comercial a software de socios aprobado. Ambos se anunciaron en el resumen de DevDay. Cambian la forma de comprar capacidad de agentes e integraciones, pero no eliminan la necesidad de evaluar las herramientas que reciben datos de la organización.

Qué deben verificar los equipos de AppSec tras OpenAI DevDay

El riesgo principal surge de una cadena de capacidades razonables por separado: un agente lee un mensaje, consulta un repositorio, usa un navegador y después modifica una incidencia o abre una pull request. El daño depende de en qué momento se da autoridad a contenido no confiable y de lo que el agente pueda hacer a continuación.

Ilustración original de Plexicus sobre la superficie de ataque de un agente; no es una captura de un producto de OpenAI.

Para cada flujo de trabajo, los equipos de seguridad deberían comprobar:

• Identidad y alcance: qué credenciales posee cada agente, qué puede leer o cambiar y cuándo caduca su acceso.
• Límites de entrada: si las páginas recuperadas, los mensajes, las cargas de eventos y los resultados de herramientas siguen siendo datos no confiables (la inyección de prompts ocupa la primera posición en los OWASP Top 10 para aplicaciones LLM).
• Controles de acción: qué escrituras requieren aprobación humana y si la aprobación corresponde exactamente a la acción y al destino previstos.
• Trazabilidad: si los registros vinculan un evento con la decisión del agente, las llamadas a herramientas, el cambio resultante y su revisor.
• Validación: si un hallazgo es alcanzable y explotable dentro del alcance autorizado, por ejemplo mediante un AI Swarm Pentest, y si se volvió a probar la corrección.

El anexo de seguridad de GPT-6.1 Sol de OpenAI informa de resultados de evaluaciones de ciberseguridad y describe salvaguardas de despliegue. Son resultados de benchmarks comunicados por el proveedor bajo condiciones de evaluación específicas, no una medida de lo segura que será cada implementación de agentes. La aplicación, los permisos, las integraciones y los controles humanos siguen determinando la exposición real.

La pregunta duradera de AppSec tras DevDay es práctica: a medida que los agentes operan durante más tiempo y en más sistemas, ¿pueden los equipos demostrar qué acciones estaban permitidas, qué evidencias las respaldaban y si el software resultante es seguro? La verificación basada en pruebas debe abarcar todo el flujo de trabajo, desde el evento entrante hasta el cambio final.

Preguntas frecuentes