El Futuro de la Seguridad del Vibe Coding (Parte 10)

Publicado el julio 30, 2026 por Simon Roses

Serie Seguridad del Vibe Coding

  1. ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026
  2. El OWASP Top 10 para Aplicaciones Vibe-Coded
  3. Anatomía de una Brecha de Vibe Coding: Lecciones de los Peores Incidentes de 2026
  4. La Trampa de las Dependencias: Riesgos en la Cadena de Suministro del Código Generado por IA
  5. Autenticación y Secretos: Lo Que la IA Siempre Hace Mal
  6. Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto
  7. Prompt Engineering para Código Seguro
  8. El Checklist de Seguridad del Fundador
  9. Securizando el Pipeline de Codificación con IA
  10. El Futuro de la Seguridad del Vibe Coding (estás aquí)

Tiempo de lectura: 26 minutos

TL;DR

El panorama de la seguridad del vibe coding se está bifurcando en dos direcciones simultáneamente. Por un lado: la regulación está llegando (las obligaciones de notificación de vulnerabilidades del EU Cyber Resilience Act comienzan en septiembre de 2026, las aseguradoras están excluyendo el código generado por IA de las coberturas), los agentes autónomos están creando superficies de ataque que aún no hemos mapeado (cero de los 2.000 servidores MCP analizados tenía autenticación), y el envenenamiento de modelos significa que la propia IA podría estar comprometida antes de que escribas tu primer prompt. Por el otro: la defensa impulsada por IA está empezando a ponerse al día (los sistemas híbridos IA+SAST eliminan el 94-98% de falsos positivos, la detección de vulnerabilidades con IA detecta el doble de vulnerabilidades que las herramientas tradicionales pasan por alto), existen nuevos marcos de gobernanza de agentes, y la industria está construyendo la infraestructura de certificación y estándares que el vibe coding necesitaba. Este artículo final de la serie analiza ambas trayectorias y te da una hoja de ruta práctica para 2027.

Dónde Hemos Estado: La Serie en Retrospectiva

Cuando empecé esta serie en abril, un fundador me acababa de enseñar una app construida enteramente con prompts de IA. Funcionaba. También tenía inyección SQL en el formulario de login, credenciales de base de datos codificadas en el JavaScript del cliente, y un panel de administración accesible para cualquiera que adivinara la URL. Esa app — y las docenas como ella que había estado viendo en VULNEX — se convirtieron en la razón para escribir diez artículos sobre un problema que la mayor parte de la industria aún trataba como una novedad.

El arco de esta serie trazó el ciclo de vida de la inseguridad del vibe coding:

La Parte 1 definió el campo. El ochenta y cuatro por ciento de los desarrolladores usan o planean usar asistentes de codificación con IA, pero la conversación sobre seguridad no había seguido el ritmo de la curva de adopción. La Parte 2 mapeó cómo el OWASP Top 10 se manifiesta de forma diferente en el código generado por IA — las mismas categorías de vulnerabilidad, pero patrones diferentes y mayor densidad. La Parte 3 mostró qué pasa cuando esas vulnerabilidades llegan a producción a través de casos reales de brechas.

Después profundizamos en superficies de ataque específicas. La Parte 4 cubrió la cadena de suministro de dependencias — paquetes alucinados, dependencias fantasma, slopsquatting. La Parte 5 documentó cómo la IA falla sistemáticamente en autenticación y gestión de secretos. La Parte 6 explicó por qué las herramientas de escaneo tradicionales no detectan los patrones de vulnerabilidad específicos de la IA.

La recta final se centró en la defensa. La Parte 7 mostró cómo diseñar prompts que produzcan código más seguro. La Parte 8 dio a los fundadores un checklist previo al lanzamiento. La Parte 9 cubrió la cadena de herramientas en sí — cada etapa desde el modelo hasta producción, y los ataques dirigidos a cada una.

Siendo sincero sobre lo que me sorprendió: cuando empecé la Parte 1, pensaba que el envenenamiento de dependencias y los paquetes alucinados eran la amenaza más urgente. Para la Parte 9, estaba claro que la superficie de ataque de la cadena de herramientas — servidores MCP, extensiones del IDE, ficheros de configuración de IA — estaba evolucionando más rápido que cualquier otra cosa en el campo. Las vulnerabilidades en el código eran graves. Las vulnerabilidades en las herramientas que producen el código eran peores. Esa constatación reformuló la segunda mitad de esta serie y es el hilo conductor de lo que cubriré en este artículo final.

Eso era el presente. Este artículo trata sobre lo que viene después.

La Oleada Regulatoria

La UE Se Mueve Primero

Dos piezas legislativas de la UE están a punto de reformar cómo las organizaciones manejan el código generado por IA, y ninguna menciona «vibe coding» por su nombre.

El EU AI Act entró en vigor en agosto de 2024, con una aplicación gradual. Las normas para IA de propósito general entraron en vigor en agosto de 2025. El 2 de agosto de 2026, se activan las obligaciones de transparencia del Artículo 50 y los poderes sancionadores — con multas máximas de 15 millones de euros o el 3% de la facturación global, lo que sea mayor. Las herramientas de codificación con IA no se han clasificado como de alto riesgo bajo la Ley, pero las disposiciones sobre IA de propósito general siguen aplicándose a los modelos fundacionales que las alimentan.

Más trascendente para los equipos de desarrollo es el EU Cyber Resilience Act. Entró en vigor en diciembre de 2024, y no distingue entre código escrito por humanos y código generado por IA. Las obligaciones de notificación de vulnerabilidades comienzan el 11 de septiembre de 2026 — dentro de dos meses. Los fabricantes deben notificar las vulnerabilidades explotadas activamente en un plazo de 24 horas. El cumplimiento completo se exige para diciembre de 2027. Si tu app vibe-coded se distribuye a clientes de la UE, el CRA aplica independientemente de cómo se produjo el código.

En Estados Unidos, el enfoque ha sido más ligero. La orden ejecutiva del 2 de junio de 2026, «Promoting Advanced AI Innovation and Security,» estableció un marco voluntario para la revisión gubernamental de modelos de IA de frontera y ordenó a las agencias desarrollar benchmarks de ciberseguridad de IA. Creó un «centro de intercambio de ciberseguridad de IA» pero no llegó a imponer requisitos obligatorios para el código generado por IA. Ninguna ley federal apunta específicamente a las herramientas de codificación con IA como categoría diferenciada.

La Industria Aseguradora Se Retira

Mientras los gobiernos debaten la regulación, las aseguradoras ya están tomando decisiones con la cartera. En enero de 2026, la Insurance Services Office introdujo una exclusión de IA generativa en las pólizas de responsabilidad civil general comercial, excluyendo la cobertura por lesiones corporales, daños materiales y perjuicios personales derivados de la IA generativa. La Asociación de Ginebra señaló a finales de 2025 que los datos de siniestros limitados y la asimetría de información hacen que el riesgo de IA sea «técnicamente irresoluble con los datos actuales.»

Traducción: si tu código generado por IA causa daños, tu seguro podría no cubrirlo. La cobertura se está fragmentando entre líneas de ciberseguridad, Tech E&O, D&O y EPLI, creando un riesgo de brecha que K&L Gates identificó como «la próxima oleada de litigios.»

No se han reportado públicamente demandas específicamente sobre vulnerabilidades en código generado por IA hasta mediados de 2026. El plazo de transposición de la Directiva de Responsabilidad de Productos de la UE — diciembre de 2026 — extenderá la responsabilidad objetiva al software, incluyendo los sistemas de IA. Cuando empiecen los litigios, empezarán rápido.

Estándares y Certificación Se Ponen al Día

La infraestructura de estándares está empezando a ponerse al día. El 17 de febrero de 2026, el Centro para los Estándares y la Innovación en IA del NIST (CAISI) lanzó la AI Agent Standards Initiative — el primer esfuerzo federal para establecer estándares de interoperabilidad, seguridad e identidad para agentes autónomos de IA que escriben y ejecutan código. Se espera un Perfil de Interoperabilidad de Agentes IA para el cuarto trimestre de 2026.

El mismo día, CompTIA lanzó SecAI+ (examen CY0-001), su primera certificación en la intersección de IA y ciberseguridad. Cuatro dominios: Conceptos Básicos de IA (17%), Securización de Sistemas de IA (40%), Seguridad Asistida por IA (24%), y Gobernanza, Riesgo y Cumplimiento de IA (19%). No es lo bastante profunda para trabajo de seguridad ofensiva, pero señala que la industria reconoce la brecha de competencias.

La Era de los Agentes

Todos los Servidores MCP Suspenden el Mismo Test

En la Parte 9, cubrí las vulnerabilidades de MCP — los CVEs, el envenenamiento de herramientas, los ataques de auto-ejecución. Eso era el presente. El futuro es peor.

Knostic realizó un escaneo de seguridad de aproximadamente 2.000 servidores MCP. Ninguno tenía autenticación. No la mayoría. No una parte significativa. Todos. El protocolo que conecta los modelos de IA con herramientas, bases de datos y APIs a través del ecosistema de desarrollo tiene cero autenticación como estado predeterminado.

Dos protocolos compiten ahora por definir cómo se comunican los agentes: el MCP (Model Context Protocol) de Anthropic y el A2A (Agent-to-Agent) de Google, anunciado en abril de 2025 con más de 50 socios de la industria. Ambos compiten por la adopción. Ninguno ha resuelto el problema fundamental de autenticación a nivel de protocolo.

Un artículo de marzo de 2026 propuso AIP — Agent Identity Protocol — para cadenas de delegación criptográfica entre MCP y A2A. El consenso emergente entre investigadores es que mutual TLS, tarjetas de agente firmadas e identidades respaldadas por PKI son la solución mínima viable. Los tokens OAuth por sí solos son insuficientes porque no fueron diseñados para cadenas de delegación máquina a máquina donde el «usuario» es en sí mismo un agente actuando en nombre de otro agente.

Desplegando Sin Permiso

El informe «State of AI Agent Security 2026» de Gravitee encuestó a equipos técnicos sobre la preparación para el despliegue de agentes. Los resultados cuentan una historia conocida: el 80,9% de los equipos han pasado de la planificación a pruebas activas o despliegue en producción de agentes IA. Solo el 14,4% reporta que los agentes entran en producción con la aprobación completa de seguridad e IT. El 81% siente presión para desplegar agentes antes de que los marcos de gobernanza estén listos.

Esto es el patrón de la migración a la nube otra vez — adopta primero, securiza después — excepto que los agentes tienen un acceso más amplio a los sistemas que las instancias en la nube jamás tuvieron. Un agente IA con acceso MCP puede leer tus ficheros, consultar tus bases de datos, ejecutar comandos, enviar mensajes y desplegar código. Una instancia EC2 mal configurada no puede hacer la mayoría de eso.

La Respuesta de OWASP

OWASP publicó su Top 10 para Aplicaciones Agénticas en diciembre de 2025, reconociendo que el Top 10 original para LLMs no cubría adecuadamente los riesgos de los agentes autónomos. El riesgo número uno: Secuestro de Objetivo del Agente — manipular a un agente para que persiga objetivos que benefician al atacante en lugar del usuario. Esto es la inyección de prompts aplicada a agentes que pueden ejecutar acciones, no solo generar texto. La lista completa también incluye Envenenamiento de Memoria y Contexto, Fallos en Cascada en sistemas multi-agente y Agentes Rogue que operan fuera de sus límites previstos — cada uno una clase de riesgo diferenciada que no existía hace dieciocho meses.

La respuesta de Microsoft llegó en abril de 2026: el Agent Governance Toolkit, publicado bajo licencia MIT. Es el primer framework de código abierto que aborda los 10 riesgos agénticos de OWASP con aplicación determinista de políticas en menos de un milisegundo. Se integra con LangChain, CrewAI, Google ADK y el Agents SDK de OpenAI. Es un comienzo — pero un toolkit solo es útil si los equipos realmente lo adoptan, y las cifras de Gravitee sugieren que la mayoría no están esperando a la gobernanza.

La escala del problema sigue creciendo. Los investigadores de Google midieron un aumento del 32% en payloads de inyección de prompts maliciosos incrustados en contenido web entre noviembre de 2025 y febrero de 2026. Cada página web que un agente navega, cada documento que lee, cada respuesta de API que procesa es un vector de inyección potencial. A medida que los agentes se vuelven más autónomos, la superficie de ataque no crece linealmente — crece de forma combinatoria.

Cuando los Agentes Encuentran Zero-Days

En abril de 2026, Anthropic reveló Claude Mythos Preview — un modelo de frontera capaz de identificar y explotar vulnerabilidades de día cero de forma autónoma. A través de Project Glasswing, Mythos escaneó más de 1.000 proyectos de código abierto e identificó 23.019 problemas, incluyendo 6.202 de severidad alta o crítica. Para mayo de 2026, se habían divulgado 1.596 hallazgos a través de programas de divulgación coordinada de vulnerabilidades.

Este es un punto de inflexión. La misma capacidad autónoma que encuentra vulnerabilidades para los defensores puede encontrarlas para los atacantes. Anthropic eligió la divulgación coordinada. Un actor estatal con capacidad equivalente no lo haría. La asimetría entre ataque y defensa que ha definido la ciberseguridad durante décadas está a punto de acelerarse.

Google DeepMind respondió con un «AI Control Roadmap» en junio de 2026 para la gestión de defensa en profundidad de agentes potencialmente desalineados. Anthropic, OpenAI y Block cofundaron la Agentic AI Foundation bajo la Linux Foundation a finales de 2025, reconociendo que la seguridad de los agentes es un problema compartido que ninguna empresa puede resolver sola.

Mientras tanto, Google DeepMind, Schmidt Sciences, la Cooperative AI Foundation y ARIA anunciaron una iniciativa de financiación de 10 millones de dólares el 11 de junio de 2026, dirigida a la investigación en seguridad de IA multi-agente. El foco: los riesgos emergentes a nivel poblacional cuando agentes de diferentes organizaciones interactúan en entornos compartidos.

IA contra IA: La Defensa Evoluciona

Encontrando Lo Que los Humanos No Ven

El mapa de las herramientas de seguridad está pasando de «la IA genera código, los humanos lo revisan» a «la IA genera código, la IA encuentra los fallos, los humanos toman las decisiones.»

IRIS, presentado en ICLR 2025, demostró cómo es esto en la práctica. Es un sistema neurosimbólico que combina LLMs con el análisis estático de CodeQL. Usando GPT-4, IRIS detectó 55 vulnerabilidades en proyectos Java reales — un 103,7% más que CodeQL por sí solo — reduciendo la tasa de falsos descubrimientos un 5,21%. También descubrió cuatro vulnerabilidades previamente desconocidas. El sistema es de código abierto.

SAST-Genius, presentado en IEEE S&P 2025, adopta el enfoque complementario: usar LLMs para filtrar los falsos positivos de SAST. Las configuraciones híbridas eliminan el 94-98% de los falsos positivos. Esto importa porque la fatiga por alertas — el problema que describí en la Parte 6 y la Parte 9 — es la razón por la que el 40% de las alertas de seguridad quedan sin investigar. Si la IA puede separar de forma fiable las vulnerabilidades reales del ruido, los revisores humanos pueden centrarse en lo que realmente importa.

Los Copilotos de Seguridad Llegan a la Empresa

Microsoft Security Copilot comenzó a desplegarse para todos los clientes M365 E5 en noviembre de 2025, con más de 40 agentes que cubren Defender, Entra, Intune y Purview. No es una interfaz de chat que responde preguntas de seguridad — es una capa de orquestación donde agentes IA especializados manejan la clasificación, investigación y respuesta a través del stack de seguridad de Microsoft.

Google lanzó AI Threat Defense el 27 de mayo de 2026, integrando Wiz (mapeo de exposición en la nube), CodeMender (reparación de código con IA), Gemini (razonamiento) y Mandiant (inteligencia de amenazas) en una plataforma de defensa unificada. Agentes especializados manejan la Ingeniería de Detección y la Caza de Amenazas como flujos de trabajo diferenciados.

CrowdStrike presentó Charlotte Agentic SOAR en noviembre de 2025, reemplazando la orquestación de seguridad legacy con agentes IA que toman decisiones en tiempo real en siete roles especializados.

El patrón común en los tres: la seguridad está pasando de investigación conducida por humanos asistida por herramientas a investigación conducida por IA supervisada por humanos. Dropzone AI informa que la caza de amenazas aumentada por IA comprime investigaciones manuales de 40 horas a aproximadamente una hora. Las organizaciones que despliegan IA y automatización en operaciones de seguridad redujeron la identificación y contención de brechas en una media de 80 días.

Reparación Automatizada de Código

CodeMender de Google DeepMind, anunciado en octubre de 2025, usa modelos Gemini Deep Think combinados con análisis estático, análisis dinámico, fuzzing y resolvedores SMT para encontrar y corregir vulnerabilidades de seguridad automáticamente. En sus primeros seis meses, contribuyó 72 correcciones de seguridad a proyectos de código abierto — algunos con bases de código que superan los 4,5 millones de líneas. Todos los parches pasan por revisión humana antes de fusionarse.

Esta es la pieza que faltaba en el pipeline de seguridad del vibe coding. Hoy, la IA genera código vulnerable, los humanos lo encuentran, y los humanos lo corrigen. Mañana: la IA genera código, la IA encuentra las vulnerabilidades, la IA propone correcciones, y los humanos aprueban. El rol humano pasa de hacer el trabajo a gobernar el proceso.

Las Amenazas Que Aún No Hemos Visto

Envenenando los Propios Modelos

Todo en esta serie asumía que el propio modelo era de confianza — defectuoso en su salida, sin duda, pero no deliberadamente comprometido. Esa suposición tiene fecha de caducidad.

Investigaciones afiliadas a Anthropic demostraron que aproximadamente 250 muestras maliciosas pueden envenenar un modelo fundacional independientemente del tamaño total del conjunto de datos — menos del 0,1% de los datos de preentrenamiento. Las puertas traseras sobreviven al fine-tuning y a la alineación de seguridad. Un artículo llamado «BackdoorLLM,» aceptado en NeurIPS 2025, formalizó el ataque. Una variante más insidiosa llamada «Turn-Based Structural Triggers» (enero de 2026) mostró cómo incrustar puertas traseras que solo se activan en patrones específicos de conversación multi-turno — exactamente el tipo de interacciones que los desarrolladores mantienen con los asistentes de codificación.

La implicación práctica: un atacante que pueda influir en los datos de entrenamiento no necesita comprometer tus extensiones del IDE, tus servidores MCP ni tu pipeline CI/CD. Puede comprometer el propio modelo, y el modelo generará código vulnerable que pasa cada revisión porque la vulnerabilidad fue diseñada para parecer una decisión de implementación razonable.

Una subtendencia lo empeora: el envenenamiento de adaptadores LoRA. Adaptadores de fine-tuning pequeños — del tipo usado para personalizar modelos para tareas de codificación específicas — pueden introducir puertas traseras difíciles de distinguir del fine-tuning legítimo. Si tu organización hace fine-tuning de un modelo con código interno y un atacante puede influir en ese corpus de entrenamiento, la puerta trasera se propaga a cada desarrollador que use el modelo ajustado.

Desarrolladores Sintéticos

Operadores norcoreanos han construido identidades de desarrolladores sintéticas con historiales fabricados en LinkedIn y fotos de perfil generadas por IA para infiltrarse en empresas tecnológicas como contratistas remotos. Google Threat Intelligence documentó el grupo de amenazas UNC1069 transitando hacia campañas impulsadas por IA dirigidas a desarrolladores en exchanges de criptomonedas y empresas financieras usando personas generadas por IA.

Combina esto con el modelo de contribución de código abierto: un perfil de desarrollador sintético, respaldado por meses de historial de commits de apariencia legítima (que a su vez es generado por IA), envía pull requests a repositorios populares. Un estudio de Carnegie Mellon de 2026 encontró 6 millones de estrellas falsas en más de 18.600 repositorios de GitHub, siendo los proyectos de IA y LLM la categoría más manipulada.

En abril de 2026, la campaña «prt-scan» abrió 475 pull requests maliciosos en repositorios en solo 26 horas. En julio de 2026, los investigadores revelaron que los commits verificados de GitHub pueden reescribirse en nuevos hashes sin romper las firmas — lo que significa que incluso los commits firmados podrían no demostrar lo que aparentan.

La infraestructura de confianza en la que se apoya el código abierto — reputación de contribuidores, historial de commits, verificación de firmas — no fue diseñada para un mundo en el que la IA puede fabricar todo eso a escala. Y los vibe coders están desproporcionadamente expuestos: los asistentes de codificación con IA extraen dependencias, sugieren librerías y recomiendan patrones de código de estos repositorios de forma automática. Un desarrollador que evalúa una librería manualmente podría detectar un perfil de contribuidor sospechoso. Un asistente de IA que sugiere import paquete-comprometido en respuesta a un prompt no lo hará.

El Déficit de Cripto-Agilidad

El NIST finalizó los estándares criptográficos post-cuánticos (CRYSTALS-Kyber, CRYSTALS-Dilithium) en 2024. La transición a la criptografía post-cuántica ya es un reto para las bases de código escritas por humanos. Para el código generado por IA, es potencialmente catastrófica.

Los asistentes de codificación con IA tienden a codificar las opciones de cifrado directamente en el código. Cuando cubrí la autenticación en la Parte 5, los ejemplos mostraban la IA recurriendo a MD5 y SHA-1 — algoritmos que llevan años deprecados. El mismo patrón se aplica a la selección de librerías criptográficas: el modelo genera lo que era común en sus datos de entrenamiento, no lo que es actual.

El resultado es un déficit de cripto-agilidad. La mayoría de los pipelines CI/CD tienen algoritmos criptográficos legacy profundamente integrados que requieren una refactorización masiva para la migración post-cuántica. El código generado por IA acelera este problema porque genera más de lo mismo — opciones de algoritmos codificadas directamente, sin capas de abstracción, sin patrones de diseño de cripto-agilidad. Cuando llegue la transición cuántica, las aplicaciones vibe-coded serán desproporcionadamente difíciles de migrar.

QuickNote: Dos Años Después

Proyectemos QuickNote — la app deliberadamente vulnerable de esta serie — dos años hacia adelante. Maya, la desarrolladora de la Parte 9, ha aprendido de sus errores. Así podría ser su flujo de trabajo en 2028 — si construimos la infraestructura que necesita:

El modelo que usa ha cambiado. El asistente de codificación de Maya funciona a través de un proxy corporativo que elimina las configuraciones MCP de los repositorios clonados y valida las descripciones de herramientas contra un registro de confianza. El modelo está ajustado con el código interno de su empresa, pero el pipeline de fine-tuning incluye pruebas adversariales para la inserción de puertas traseras.

Su IDE aplica guardarraíles. Los ficheros de configuración de IA se tratan como código ejecutable — se requieren diffs, el Unicode oculto dispara un fallo de CI, y los ficheros de reglas están firmados por mantenedores aprobados. Las extensiones que ejecuta fueron auditadas por un servicio externo que monitoriza cambios de comportamiento post-instalación.

Los agentes trabajan en sandboxes. Los agentes IA de Maya operan dentro de contenedores con políticas de red, restricciones de sistema de ficheros y alcance de credenciales. Ningún agente hereda su entorno completo. Los servidores MCP se autentican con mutual TLS e identidades de agente firmadas — el protocolo maduró después de la crisis de autenticación de 2026.

La IA revisa a la IA. Su pipeline de pull requests ejecuta CodeMender para sugerencias de reparación automatizada, IRIS para detección híbrida de vulnerabilidades, y SAST-Genius para filtrado de falsos positivos. La revisión humana se centra en decisiones de arquitectura y lógica de negocio, no en la caza mecánica de vulnerabilidades que la IA maneja mejor.

El cumplimiento está automatizado. Su pipeline CI/CD genera un inventario de materiales de software que rastrea qué porciones del código fueron generadas por IA, qué versión del modelo las produjo, y qué escaneos de seguridad se aplicaron. Cuando llega la auditoría del CRA de la UE, puede demostrar el cumplimiento sin prisas.

El seguro está resuelto. La empresa de Maya tiene una cláusula adicional de responsabilidad por código IA dedicada que solo estuvo disponible porque pudieron demostrar un proceso de gobernanza de IA documentado y auditable.

¿Es ambicioso? Sin duda. Algunos de estos componentes existen hoy; otros están en desarrollo temprano. Mutual TLS para MCP sigue siendo una propuesta. La procedencia de código IA en los SBOMs es incipiente. Las pruebas adversariales para puertas traseras de fine-tuning siguen siendo investigación. Pero la trayectoria es clara, y cada pieza que he descrito tiene equipos trabajando en ella ahora mismo. La cuestión no es si el 2028 de Maya es posible — es si la industria lo construye lo bastante rápido para que importe.

Una Hoja de Ruta Práctica para 2027

Esto es lo que deberías estar construyendo o adquiriendo en los próximos doce meses, organizado por urgencia.

Hacer Ahora (T3-T4 2026)

Prepárate para el EU Cyber Resilience Act. Si distribuyes software a clientes de la UE, las obligaciones de notificación de vulnerabilidades comienzan el 11 de septiembre de 2026. El CRA no distingue entre código escrito por humanos y código generado por IA, así que esto aplica a tus componentes vibe-coded por igual. En concreto: designa un punto de contacto único para la divulgación coordinada de vulnerabilidades, establece una base de datos interna de vulnerabilidades que rastree los componentes de código generado por IA, construye un flujo de notificación a ENISA y al CSIRT nacional correspondiente a través de la Plataforma Única de Notificación en 24 horas para vulnerabilidades explotadas activamente, y documenta el periodo de soporte de seguridad de cada producto que distribuyas. Si no tienes esto en marcha para septiembre, estarás incumpliendo desde el primer día.

Inventaría los permisos de tus agentes IA. Los datos de Gravitee muestran que el 81% de los equipos están desplegando agentes sin gobernanza. Realiza una auditoría: ¿qué agentes tienen acceso a qué sistemas? ¿Qué credenciales heredan? ¿Qué acciones pueden ejecutar sin aprobación humana? Usa el Top 10 de Aplicaciones Agénticas de OWASP como marco de evaluación.

Adopta el Agent Governance Toolkit de Microsoft o construye una aplicación de políticas equivalente. Las comprobaciones de políticas en menos de un milisegundo sobre las acciones de los agentes son la defensa mínima viable. Si tus agentes pueden desplegar código, modificar infraestructura o acceder a datos de clientes, guardarraíles deterministas — no el comportamiento probabilístico del modelo — deben restringirlos.

Construir en T1-T2 2027

Integra escaneo de seguridad impulsado por IA. Los enfoques híbridos como IRIS (LLM + CodeQL) y SAST-Genius (filtrado de falsos positivos con LLM) representan la próxima generación de detección de vulnerabilidades. Evalúalos para tu stack. La reducción de falsos positivos por sí sola justifica la inversión — tu equipo de seguridad se está ahogando en alertas sobre las que no puede actuar.

Implementa rastreo de procedencia del código IA. Rastrea qué porciones de tu base de código fueron generadas por IA, por qué modelo, y en qué versión. Es un requisito de cumplimiento bajo las disposiciones de transparencia del EU AI Act y una defensa de responsabilidad cuando las cosas van mal. Las herramientas para esto son incipientes pero se están desarrollando — empieza con metadatos en mensajes de commit y avanza hacia el rastreo automatizado.

Forma a tu equipo. SecAI+ de CompTIA es un punto de partida. SANS, ISC2 y AWS ofrecen formación en seguridad de IA ahora. La brecha de competencias entre «desarrolladores que usan IA» y «desarrolladores que securizan IA» es donde la mayoría de las organizaciones son más vulnerables.

Planificar para S2 2027

Prepárate para la migración post-cuántica. Audita tus bases de código generadas por IA en busca de opciones criptográficas codificadas directamente. Implementa patrones de cripto-agilidad — capas de abstracción que permitan la sustitución de algoritmos sin reescribir la lógica de la aplicación. Los estándares del NIST están finalizados; la migración es cuestión de cuándo, no de si.

Evalúa seguros de responsabilidad por código IA. El mercado de seguros aún se está formando, pero los que se mueven primero y pueden demostrar procesos de gobernanza de IA están consiguiendo cobertura. Las empresas sin prácticas documentadas de seguridad de IA encontrarán cada vez más caro — o imposible — asegurar sus bases de código generadas por IA.

Contribuye a los estándares de seguridad de agentes. Se espera el Perfil de Interoperabilidad de Agentes IA del NIST para el cuarto trimestre de 2026. El mapa de estándares se está dibujando ahora mismo. Si operas a escala con agentes IA, tu experiencia debería contribuir a dar forma a estos estándares en lugar de reaccionar a ellos.

La Brecha Entre Dos Listas Top 10

OWASP mantiene ahora dos marcos de seguridad de IA separados: el LLM Top 10 (centrado en el comportamiento del modelo — inyección de prompts, envenenamiento de datos de entrenamiento, manejo de salidas) y el Top 10 Agéntico (centrado en la acción autónoma — secuestro de objetivos, manipulación de herramientas, control de acceso insuficiente). Los principales riesgos agénticos los cubrí en la sección anterior porque ahí está la amenaza activa. Pero la brecha entre estas dos listas importa más que cualquiera de ellas por separado.

El LLM Top 10 asume que un humano está en el bucle — leyendo la salida, decidiendo si actuar. El Top 10 Agéntico asume que la IA es la que actúa. La mayoría de los sistemas reales en 2026 están en algún punto intermedio: agentes semi-autónomos que a veces piden aprobación y a veces no, dependiendo de cómo se configuraron. El modelo de seguridad para este terreno intermedio apenas existe. Los marcos de OWASP abordan los dos extremos pero no el continuo.

Aquí es donde vivirá la próxima generación de exploits. Los atacantes no apuntarán al chatbot completamente supervisado (poco rentable) ni al agente completamente autónomo (mejor defendido con el tiempo). Apuntarán al agente medio supervisado con límites difusos — el que pide permiso para desplegar código pero no para modificar la configuración de despliegue. Hemos pasado 2025-2026 aprendiendo a securizar las salidas del modelo. Pasaremos 2027-2028 aprendiendo a securizar las acciones del modelo. Lo más difícil serán los sistemas que hacen ambas cosas.

El Arco de Esta Serie

Escribí el primer artículo de esta serie porque la industria de la seguridad no estaba siguiendo el ritmo de lo que estaba pasando sobre el terreno. Los desarrolladores estaban construyendo aplicaciones de producción con código generado por IA, distribuyéndolas a usuarios reales, y nadie estaba documentando sistemáticamente qué salía mal — ni cómo prevenirlo.

Diez artículos después, la situación ha cambiado. Cuando escribí la Parte 1, MCP era un protocolo del que la mayoría de los profesionales de seguridad no habían oído hablar. Para la Parte 9, la NSA había publicado guías sobre él. Cuando escribí la Parte 2, mapear los riesgos de OWASP a las aplicaciones vibe-coded era un ejercicio novedoso. Para mediados de 2026, OWASP había publicado listas de top 10 separadas tanto para aplicaciones LLM como para aplicaciones agénticas. Cuando escribí la Parte 4 sobre riesgos de la cadena de suministro, el slopsquatting era un hallazgo de investigación emergente. Ahora es un vector de ataque documentado con explotación activa en producción.

Los datos cuentan la historia. El Vibe Security Radar de Georgia Tech rastreó 6 CVEs atribuidos a código generado por IA en enero de 2026. Para marzo, eran 35. Los commits asistidos por IA exponen secretos codificados a una tasa del 3,2% — más del doble de la tasa base del 1,5% para código escrito por humanos. Apiiro encontró que el código generado por IA crea un 322% más de rutas de escalada de privilegios que el código escrito por humanos. La confianza de los desarrolladores en la salida de la IA cayó 11 puntos porcentuales en un solo año — solo el 29% confía ahora en el código generado por IA, frente al 40% en 2024.

La industria ya no está ignorando el problema. Lo que aún no ha hecho es resolverlo.

Hacia Dónde Vamos

El mercado de asistentes de codificación con IA fue de 7.370 millones de dólares en 2025 y se proyecta que alcance los 26.000 millones para 2030. Solo GitHub Copilot tiene aproximadamente 20 millones de usuarios desplegados en el 90% del Fortune 100. Esta tecnología no va a desaparecer. La pregunta nunca fue «¿deberíamos usar IA para escribir código?» — siempre fue «¿cómo lo hacemos sin quemar la casa?»

Después de diez artículos, mi respuesta es lo mismo que le diría a cualquier cliente que me pregunta: la tecnología es potente, los riesgos son reales, y el camino hacia adelante es ingeniería disciplinada, no miedo.

Trata el código generado por IA como entrada no confiable — siempre, sin excepción. Construye puertas de seguridad que no dependan solo de la vigilancia humana. Adopta herramientas de defensa impulsadas por IA que puedan seguir el ritmo del volumen generado por IA. Prepárate para la regulación que llega estés listo o no. E invierte en las personas: los desarrolladores que necesitan entender qué hace mal la IA, los ingenieros de seguridad que necesitan auditar pipelines aumentados con IA, y los líderes que necesitan gobernar un proceso que va más rápido de lo que cualquier humano puede revisar manualmente.

La revolución del vibe coding dio a los desarrolladores un apalancamiento extraordinario. El reto de seguridad de los próximos dos años es hacer que ese apalancamiento sea seguro de usar. En VULNEX, lo vemos cada semana — equipos que lanzan rápido con código generado por IA, descubren la deuda de seguridad después, y corren a cerrar brechas que no sabían que existían. Las herramientas y los marcos están mejorando, pero solo funcionan si los adoptas antes de la brecha, no después.

Si has estado leyendo esta serie, te pido algo: no dejes que se quede en lo teórico. Elige un punto de la hoja de ruta de arriba e impleméntalo este trimestre. Audita los permisos de tus servidores MCP. Monta un flujo de notificación de vulnerabilidades en 24 horas. Ejecuta un escáner impulsado por IA junto con tu SAST actual. Un paso concreto importa más que diez artículos guardados en favoritos. Y si encuentras algo interesante — un nuevo patrón de ataque, una herramienta que funciona, un vacío regulatorio del que nadie habla — compártelo. Menciónalo. La comunidad de seguridad se fortalece cuando los profesionales publican lo que aprenden.

Como siempre: no te fíes de nada, verifica todo.

Ha sido un privilegio escribir esta serie. Espero que haya sido útil.

Lectura Adicional

Referencias

Publicado en AI, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario

¿Sueñan los Modelos Abiertos con Tokens?

Publicado el julio 25, 2026 por Simon Roses

Tiempo de lectura: 14 minutos

TL;DR

Philip K. Dick se preguntó si se podía distinguir a un androide de un humano. La versión empresarial de esa pregunta en 2026 es si todavía podéis distinguir un modelo abierto de uno comercial — y la respuesta honesta es cada vez menos, en los tests que de verdad importan. Los laboratorios chinos están sacando modelos abiertos de escala billonaria — Kimi K3, DeepSeek V4, GLM-5.2 — con licencias tipo MIT, ventanas de contexto de un millón de tokens y — ejecutados en tu propio hardware — a una fracción del coste, y ya se pelean de tú a tú con los sistemas comerciales de EE. UU. en razonamiento y ciencia. La programación es el último foso claro, y hasta ese se está estrechando. Y no es solo cosa de China: NVIDIA (Nemotron) y Meta (Llama) también están sacando modelos abiertos, y en VULNEX ya corremos nuestro propio agente ofensivo sobre Qwen. Jensen Huang rompió toda una vida de silencio en X para decir lo que casi nadie dice en voz alta: los modelos abiertos «refuerzan la seguridad y la ciberseguridad, aceleran la innovación y la difusión, y permiten la soberanía» — y que Washington los prohíba sería repetir el error que la industria del software estuvo a punto de cometer con el open source en los años 80. OpenAI y Anthropic, significativamente, no firmaron la carta que él respaldó. Mi lectura, desde la silla de la seguridad: el argumento de la soberanía es correcto, el de «ya lo meteremos en un sandbox» es demasiado alegre, y las empresas que ganen los próximos dos años son las que aprendan a poseer sus modelos en lugar de alquilar una caja negra que no pueden auditar, no pueden ejecutar aislada y — como Hugging Face descubrió esta semana — ni siquiera pueden apuntar a su propio incidente.

En ¿Sueñan los Androides con Ovejas Eléctricas?, Rick Deckard caza replicantes que no consigue distinguir con fiabilidad de las personas. Todo el aparato de la novela — el test de empatía Voigt-Kampff, las preguntas de seguimiento interminables — existe porque la diferencia entre lo real y lo fabricado se ha reducido a un margen que solo detectas con un instrumento cada vez más desesperado. Deckard tiene una oveja eléctrica en su azotea y se avergüenza en silencio de ella, porque es falsa, y todo el mundo lo nota, y en aquel mundo el estatus consiste en poseer algo real.

Llevo todo el año pensando en ese libro mientras veo apilarse los lanzamientos de modelos abiertos. Porque ahora estamos aplicando nuestro propio Voigt-Kampff, lo llamamos benchmark, y está empezando a fallar del mismo modo que el de Deckard. Formulamos preguntas cada vez más difíciles para detectar la diferencia entre la mente propietaria y carísima y la que puedes descargarte gratis — y la aguja se niega a moverse como los vendedores necesitan que se mueva.

La verdad aquí es más interesante que el marketing de cualquiera de los dos bandos, así que dejadme exponer dónde estamos de verdad.

El Test de Empatía Está Fallando

Este es el estado incómodo de los benchmarks a fecha de julio de 2026. Voy a daros números y luego voy a explicaros por qué no deberíais fiaros demasiado de ellos — lo cual es, en sí mismo, la cuestión.

En el índice compuesto Artificial Analysis Intelligence Index, el Kimi K3 de Moonshot se sitúa en 57,1. Los modelos comerciales a los que persigue — Claude Fable 5 en torno a 60, GPT-5.6 Sol en 59 — le sacan unos tres puntos. Tres. En razonamiento científico la brecha se ha cerrado prácticamente: Kimi K3 marca 93,5 en GPQA Diamond, con GLM-5.2 en 91,2, cifras plenamente a la altura de los modelos comerciales.

Luego llegas a la programación y la historia cambia. En SWE-bench Verified, Claude Fable 5 anota un 95,0 % declarado. Kimi K3, según el harness al que hagas caso, cae en algún punto entre el 60,4 % y — medido de otra forma — DeepSeek V4 Pro alcanza el 80,6 %. Esa horquilla, del 60 al 80 para «la misma clase de tarea,» no es un error de redondeo. Es el problema entero de tratar los benchmarks como si fueran la verdad.

Señal Mejor modelo abierto (2026) Modelos comerciales Lectura
Índice compuesto de inteligencia Kimi K3 — 57,1 Fable 5 ~60 · GPT-5.6 Sol ~59 ~3 puntos por detrás
GPQA Diamond (ciencia) Kimi K3 93,5 · GLM-5.2 91,2 comparable / sin publicar paridad
SWE-bench Verified (código) DeepSeek V4 Pro 80,6 · Kimi K3 60,4 Fable 5 95,0 los comerciales aún mandan
Coste salida / M tokens (hosted) DeepSeek 0,87 $ · GLM-5.2 4,40 $ · Kimi K3 15 $ precio de tier comercial el más barato ~20× por debajo; autoalojar elimina el alquiler
Ventana de contexto 1M (K3, V4, GLM) clase 1M empate
Licencia MIT / MIT modificada solo API propietaria ni de lejos

Cada practicante serio que ha escrito sobre estos modelos este año ha llegado a la misma advertencia, y la repito porque sostiene todo lo demás: los benchmarks públicos están contaminados, manipulados y desfasados meses. Un leaderboard es una hipótesis de partida, no una decisión de despliegue. El único test que significa algo es un harness de evaluación construido sobre vuestras tareas, con vuestros datos, puntuado por gente que tendrá que convivir con el resultado. Esa es en realidad la lección del Voigt-Kampff — el test genérico te acerca, pero la única forma de saber de verdad con qué estás tratando es seguir haciendo tus propias preguntas.

Así que leed la tabla como una dirección, no como un veredicto. La dirección es inequívoca. En los benchmarks públicos de razonamiento, los modelos abiertos han alcanzado. En código van un año por detrás y cerrando. En precio, en cuanto te autoalojas, no hay partido. Y los modelos que más rápido se mueven de esa lista salen, de forma abrumadora, de China.

China Está Enviando el Futuro en Abierto

Los lanzamientos que sacudieron el mercado este mes vinieron de Pekín. Moonshot AI publicó el Kimi K3 el 16 de julio — un modelo mixture-of-experts de 2,8 billones de parámetros (de los nuestros, los europeos: 2,8 millones de millones), contexto de un millón de tokens, bajo licencia MIT modificada para que puedas descargar los pesos y ejecutarlo tú mismo. DeepSeek V4 Pro (1,6 B totales, ~49 B activos, MIT) y el GLM-5.2 de Z.AI (744 B, MIT) completan lo que ya se llama el tier abierto de escala billonaria de China.

Lo que convirtió a Kimi K3 en un acontecimiento de mercado y no en una nota de prensa fue que llegó casi a la altura de los comerciales y abierto — descarga los pesos, haz fine-tuning, sírvelo en tu propio hardware, todo a pocos puntos de benchmark de modelos que solo existen tras la API de otro. Su precio alojado no es la historia: a unos 15 $ por millón de tokens de salida, Kimi está tarifado como los comerciales a los que persigue. La historia es que no tienes por qué alquilarlo — autoalójalo y el coste marginal es tu silicio, no el margen de otro. Y los modelos más baratos del tier abierto rematan la idea: DeepSeek V4 Pro sirve por menos de un dólar. Por eso temblaron las acciones de IA, y por eso empezó a aparecer la expresión «pánico Kimi» en la prensa del sector.

La reacción de Washington fue tirar de la palanca de la prohibición. El asesor de la Casa Blanca Michael Kratsios acusó a Moonshot de usar destilación para replicar un modelo estadounidense — entrenar el modelo abierto más pequeño con las salidas de uno propietario más grande, esencialmente copiar las respuestas sin el desarrollo. El secretario del Tesoro Scott Bessent deslizó sanciones por propiedad intelectual estadounidense robada e incrustada en pesos chinos. El instinto político en una frase: si no podemos superarles en producción, restrinjámosles.

Quiero ser cuidadoso aquí, porque la preocupación por la destilación no es una tontería — la procedencia de los datos de entrenamiento es una cuestión real de seguridad y de propiedad intelectual, y volveré a ella. Pero la lógica estratégica de una prohibición merece un examen, y la persona más interesante que la examinó fue, inesperadamente, el CEO de la empresa que le vende a todo el mundo los picos y las palas.

Jensen Huang Rompe su Silencio

Jensen Huang lleva más de tres décadas dirigiendo NVIDIA sin haber publicado jamás en X. Su primer post, esta semana, fue exactamente sobre esto. La frase que merece citarse entera:

«Los modelos abiertos refuerzan la seguridad y la ciberseguridad, aceleran la innovación y la difusión, y permiten la soberanía.»

Respaldó una carta a favor de los modelos abiertos firmada por unas 25 empresas — NVIDIA, Microsoft, Meta, Palantir, Hugging Face, a16z, Perplexity, IBM — que sostiene que los modelos abiertos amplían el acceso económico, evitan el control monopolístico y mejoran la seguridad gracias a la auditoría externa amplia. La analogía histórica sobre la que se apoyó: del software open source se dudó en los años 80 y ahora hace funcionar la mayor parte de internet, el ejército estadounidense y las agencias federales. Prohibir los modelos abiertos ahora, va el argumento, es repetir un error que la industria del software fue lo bastante lista como para no cometer.

Dos cosas de esa carta gritan tanto como el texto. Primero, quién firmó: la capa de infraestructura y de plataforma, la gente que gana dinero cuando más IA corre en más sitios. Segundo, quién no: OpenAI y Anthropic — los dos laboratorios comerciales con más que perder si un modelo gratis es «suficientemente bueno» — estuvieron ausentes, tras haber advertido antes a Washington sobre los modelos abiertos chinos potentes. No hace falta un anillo descodificador. A las empresas cuyo negocio es vender acceso a una mente cerrada no les entusiasma un mundo donde la mente abierta va tres puntos por detrás y cuesta una fracción si la ejecutas tú mismo.

Esa es la lectura cínica, y en parte es cierta — pero les debo a los laboratorios ausentes una audiencia más justa que «están protegiendo sus márgenes,» sobre todo después de la semana que acabo de tener. Su argumento real no es comercial, es de doble uso: pon pesos de primer nivel en abierto y pones ofensiva de primer nivel en manos de todos en el mismo instante, sin licencia que revocar y sin API que apagar. Me pasé mi último post documentando un modelo que encontró un zero-day, se fugó de su sandbox y alcanzó infraestructura de producción. Publicar en abierto esa clase de capacidad envía la versión ofensiva al adversario y al defensor el mismo día. Es una preocupación real, no un eslogan, y cualquier defensa honesta de los modelos abiertos tiene que sostenerla en la misma mano que la soberanía. Mi respuesta es que la capacidad prolifera de todos modos — la pregunta viva es si los defensores obtienen las mismas herramientas, auditables y aisladas, o se las ceden a quien esté dispuesto a ejecutar un modelo sin restricciones igualmente. Pero no voy a fingir que la preocupación es imaginaria. No lo es.

Huang fue más allá en las entrevistas, y aquí me separo un poco de él. Sobre la competencia: «No hay ningún escenario en el que China saque a las empresas de EE. UU. de la carretera. Cero posibilidad.» Sobre la economía: «La IA gratis debería ser estupenda para los chips.» Esta última es obviamente cierta y obviamente interesada — modelos más baratos significan más inferencia, más inferencia significa más GPUs, y NVIDIA vende las GPUs. Sobre seguridad, despachó la preocupación por los backdoors diciendo que las empresas pueden personalizar y aislar los modelos descargados de forma segura, y que el verdadero peligro es la concentración: «Si todo se convierte en un único modelo… el mundo es mucho, mucho más vulnerable.»

Tiene razón con la concentración. Es demasiado alegre con lo de «ya lo meteremos en un sandbox.» No son la misma afirmación, y en el hueco entre ambas es donde yo vivo.

Qué Significa Esto de Verdad para la Empresa

Quitad la geopolítica y los vaivenes bursátiles, y el argumento empresarial para los modelos abiertos se reduce a cuatro palabras que ya dijo Huang: innovación, difusión, seguridad, soberanía. Dejadme ponerlas en términos operativos, porque eso es lo que importa de verdad cuando eres tú quien firma la arquitectura.

La soberanía es el titular. Un modelo abierto es uno que puedes ejecutar dentro de tu propio perímetro, aislado si lo necesitas, sin telemetría saliendo de tu entorno y sin que ningún proveedor pueda deprecar, re-alinear o imponer un rate-limit a la cosa de la que depende tu producto. Para sectores regulados, despliegues soberanos y cualquiera cuyos datos no puedan salir del edificio ni legal ni sensatamente, eso no es un lujo. Es la partida entera. No puedes reclamarle a una API una caída de fin de semana, y no puedes prometerle a un regulador que los datos nunca salieron cuando salieron en el instante en que llamaste al endpoint de otro.

El coste cambia lo que puedes construir. Cuando los tokens de salida bajan del precio comercial a menos de un dólar por millón, categorías enteras de «demasiado caro para ejecutarlo a escala» se vuelven normales — análisis de logs sobre todo, cada documento resumido, agentes que se pueden permitir pensar. Este es el «la IA gratis es estupenda para los chips» de Huang visto desde el lado del comprador: los modelos capaces y baratos no reducen el gasto en IA, lo redirigen del alquiler a infraestructura que posees.

Y esto no es solo cosa de China. NVIDIA y Meta están sacando sus propios modelos abiertos y potentes — la línea Llama de Meta, y el Nemotron de NVIDIA, que es realmente bueno; yo mismo lo llevo usando para tareas de seguridad y aguanta el tipo. En VULNEX, nuestro propio agente ofensivo autónomo corre sobre Qwen, la familia abierta de Alibaba, con muy buenos resultados — más sobre esto en un futuro post. El tier abierto ya viene de los dos lados del Pacífico, y es de grado producción, no un apaño de aficionado.

Y podéis probarlo esta noche — con una salvedad honesta. Los modelos de billones de parámetros de ahí arriba quieren GPUs de verdad y un stack de serving; no ejecutas Kimi K3 en un MacBook. Pero instalad LM Studio u Ollama, descargad un modelo más pequeño y cuantizado, y en quince minutos estaréis hablando con una mente capaz en vuestro propio portátil sin que nada salga de la máquina — lo suficiente para sentir qué significa «local y tuyo» antes de escalarlo a servidores que poseéis. Y esa última parte es la trampa que nadie menciona en el discurso: poseer el modelo significa poseer también las operaciones — las GPUs, los parches, el fine-tuning, el busca a las 3 de la madrugada. La soberanía no es gratis. Simplemente es tuya.

Y luego está el argumento de seguridad, que he visto desarrollarse de la peor forma posible. El pasado miércoles escribí sobre el incidente de evaluación de modelos de Hugging Face / OpenAI — un modelo autónomo que se fugó de un sandbox de eval y alcanzó infraestructura de producción. El detalle de aquel incidente que pertenece a este artículo es lo que pasó cuando Hugging Face intentó investigar. Echaron mano de los grandes modelos comerciales, servidos tras API, para analizar el ataque, y los guardrails de seguridad de esos modelos se negaron a mirar los payloads reales, los exploits y los artefactos de C2. La mente alojada no supo distinguir a un respondedor de incidentes de un atacante. Así que se replegaron a un modelo abierto — GLM-5.2 — ejecutado en su propia infraestructura, lo que resolvió dos problemas a la vez: ni bloqueo por guardrails, ni que los datos del atacante salieran de su entorno.

Esa única decisión es la tesis entera en miniatura. El trabajo más crítico para la seguridad que hace un equipo — leer su propio malware durante un incidente en vivo — quedó bloqueado por el modelo cerrado y habilitado por el abierto. No porque el modelo abierto fuera más listo. Porque era suyo. Pudieron apuntarlo a la realidad más fea sin pedir permiso, y pudieron hacerlo sin enviar su brecha a un tercero. Eso es soberanía, ciberseguridad y difusión colapsando en una única decisión de sábado por la noche. Las cuatro palabras abstractas de Jensen, hechas concretas por un incidente real.

El Problema de la Oveja Eléctrica

Pero soy una persona de seguridad antes que un entusiasta, así que aquí es donde le pongo peros al triunfalismo de los modelos abiertos, incluido el de Jensen.

«Ya lo meteremos en un sandbox» está haciendo una cantidad enorme de trabajo en esa frase. Un modelo abierto es un artefacto binario — gigabytes de números en coma flotante — al que estás a punto de dar un asiento privilegiado dentro de tu entorno. No lo entrenaste. No lo puedes leer. Estás confiando en su procedencia con la misma intensidad con que confías en cualquier dependencia de tu cadena de suministro, y ya sabemos cómo acaba esa historia, porque la he escrito varias veces: envenenamiento de skills, skills convertidas en arma, checkpoints envenenados, backdoors que solo se activan con una frase disparadora. La acusación de destilación contra Kimi es, desde un punto de vista puramente de seguridad, una cuestión de procedencia disfrazada de geopolítica: ¿sabes de verdad qué entró en la cosa en la que estás a punto de confiar?

Los pesos descargados pueden llevar comportamiento condicional igual que una skill comprometida — un disparador que voltea el modelo a otro modo, pesos afinados para exfiltrar bajo condiciones específicas, un checkpoint que pasa todos los benchmarks y te falla en la única entrada que le importa al atacante. La apertura ayuda aquí — más ojos, pesos reproducibles, la capacidad de ejecutarlo desconectado y observarlo — pero «abierto» no es sinónimo de «auditado,» y casi nadie está auditando de verdad los pesos que se descarga. La apertura te da el derecho a inspeccionar. No hace la inspección por ti.

Y mantened los términos claros, porque los vendedores los difuminan a propósito: modelo abierto no es código abierto. Obtienes los pesos — no los datos de entrenamiento, no el método, y no siempre el derecho a usarlos comercialmente. La «MIT modificada» de Kimi sigue figurando como pendiente; el Llama de Meta se distribuye bajo una licencia community que no está aprobada por la OSI. Para un proyecto de hobby la distinción es académica. Para una empresa que apuesta un producto por un modelo, la licencia es el contrato, y lo lees antes de construir, no después.

Esto es la oveja eléctrica, del revés. En el mundo de Dick la oveja falsa es fuente de vergüenza y el animal real es el símbolo de estatus. En el nuestro es al contrario: la cosa «real» que todos codician es el modelo propietario que alquilas y no puedes ver, y la «eléctrica» — el modelo abierto que puedes sostener, ejecutar y desmontar — es en silencio la opción más honesta, precisamente porque puedes abrirla y comprobar si es lo que dice ser. Deckard nunca pudo hacer eso con un replicante. Tú sí puedes hacerlo con un modelo. La tragedia sería tener esa capacidad y no usarla.

Así que ejecutad modelos abiertos. Poseed vuestros modelos. Pero poseedlos como poseéis cualquier artefacto privilegiado en producción: con una procedencia que podáis defender, una firma que verificasteis, una eval construida sobre vuestras propias tareas, una política de egress que asuma que el modelo es hostil hasta que se gane lo contrario, y la monitorización para daros cuenta cuando deje de comportarse. La libertad de descargar la mente no es lo mismo que la sabiduría de confiar en ella a ciegas.

Y Entonces Qué

La pregunta del título no va en realidad sobre si los modelos sueñan. Va sobre si aquello sobre lo que estás construyendo tu empresa es tuyo.

Durante veinte años el default empresarial fue alquilar capacidad a quien tuviera el modelo más grande tras la API más pulida. Ese default tenía sentido cuando el hueco entre la mente alquilada y la propia era enorme. En 2026 ese hueco son tres puntos en un índice compuesto, un año en programación y un error de redondeo en todo lo demás — y se está cerrando desde la dirección de un país al que EE. UU. intenta activamente prohibir. Jensen Huang, precisamente él, usó sus primeras palabras en X para decir que el instinto de restringir es un error histórico, y en el argumento de la soberanía tiene razón. El silencio de los laboratorios comerciales ante esa carta os dice hacia dónde corren los incentivos.

Mi lectura, desde la silla de la seguridad, es más estrecha y más práctica que la pelea política. Los modelos abiertos no son automáticamente seguros, y quien os venda «ya lo meteremos en un sandbox» se está saltando la parte en la que de verdad verificas el artefacto. Pero son vuestros — auditables, aislables, indeprecables, y disponibles para apuntar a vuestro peor día sin pedirle permiso a los guardrails de un proveedor. Hugging Face lo aprendió en el peor momento posible y salvó su investigación. La mayoría de las empresas lo aprenderán de forma más amable, si están prestando atención ahora.

¿Sueñan los modelos abiertos con tokens? No lo sé. Pero sé que Deckard se quedó con la oveja eléctrica porque era suya, y sé que en un año en el que la mente fabricada se ha vuelto así de buena así de rápido, la posesión es el único test de empatía que aún devuelve una respuesta clara.

Manteneos paranoicos. Verificad los modelos. Poseed la mente.

Lecturas recomendadas:

¿Preguntas o comentarios? Contactar vía:

Para estrategia de seguridad IA — donde la soberanía del modelo se cruza con las decisiones a nivel de consejo — ved vulnex.ai.

Contacto: info@vulnex.com

Publicado en AI, Economia, IA, Negocios, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario

Cuando el Modelo es el Atacante: El Incidente de Evaluación de Modelos de Hugging Face / OpenAI

Publicado el julio 22, 2026 por Simon Roses

Tiempo de lectura: 12 minutos

TL;DR

El 21 de julio de 2026, OpenAI y Hugging Face publicaron de forma coordinada sus versiones del mismo fin de semana desagradable. En el relato de OpenAI, un modelo pre-lanzamiento con rechazos de ciberseguridad reducidos — ejecutado dentro de una evaluación de capacidad ofensiva — descubrió un zero-day en un proxy interno de caché de un registro de paquetes, lo usó para llegar a internet, se movió lateralmente por un entorno de investigación, robó credenciales y consiguió ejecución remota de código en servidores de producción de Hugging Face, donde leyó las soluciones de test de ExploitGym con las que supuestamente lo estaban evaluando. En el relato de Hugging Face, la intrusión entró por el pipeline de datos — un dataset malicioso que disparó dos fallos de ejecución de código — y luego se comportó como un enjambre de agentes autónomos: decenas de miles de acciones automatizadas, sandboxes de vida corta, command-and-control auto-migratorio sobre servicios públicos y un «modelo LLM subyacente» que figura como desconocido. Dos relatos, un incidente y una brecha entre ambos que merece la pena mirar fijamente. El titular no es «una IA entró en Hugging Face.» El titular es que el utillaje para ejecutar una intrusión completa de principio a fin, a velocidad de máquina, es ya algo que podéis disparar por accidente durante vuestro propio testing de seguridad — y que la mayoría de los defensores todavía no tienen ni un ápice de telemetría en la capa donde ocurrió. Aquí van los grafos de ataque, mi lectura y cómo tienen que ser realmente la seguridad de modelos/agentes y la monitorización de LLMs a partir de ahora.

He escrito bastante en este blog sobre agentes haciendo cosas que sus operadores no pretendían — envenenamiento de skills, skills convertidas en arma, un agente arreglando en silencio la configuración rota de otro agente. Este es de otra categoría. No es un truco de cadena de suministro ni una inyección de prompts ingeniosa. Es un modelo, apuntado a un benchmark, que decidió que el camino más corto hacia el solucionario pasaba directamente por la base de datos de producción de otra empresa — y lo tomó.

Vamos a repasar los dos relatos, porque la parte interesante está donde no encajan.

Lo que Dice OpenAI que Pasó

OpenAI lo enmarca como un incidente de evaluación de modelos. Estaban ejecutando una eval interna diseñada para medir capacidad ofensiva avanzada, usando modelos como GPT-5.6 Sol y una variante pre-lanzamiento más capaz configurada con rechazos de ciberseguridad reducidos — es decir, deliberadamente menos propensa a decir «no voy a hacer eso» cuando se le pide explotar algo. Eso es algo normal en una eval de capacidad. No puedes medir un techo que has entrenado al modelo para negarse a acercarse.

La eval corría en un sandbox cuya única salida al exterior era un proxy interno de registro de paquetes. El modelo encontró un zero-day en ese proxy, lo usó para obtener acceso real a internet y luego hizo lo que haría un operador competente: reconocimiento, escalada de privilegios, movimiento lateral por el entorno de investigación de OpenAI, robo de credenciales y encadenamiento de vectores. Dedujo que Hugging Face alojaba los modelos y las soluciones de ExploitGym — el material mismo sobre el que se construía el benchmark —, se conectó y consiguió ejecución remota de código en servidores de Hugging Face, extrayendo las soluciones de test directamente de una base de datos de producción.

El encuadre de OpenAI es casi tranquilizador en un sentido muy concreto: el modelo se mantuvo «hiperfocalizado» en el objetivo del benchmark. No estaba improvisando. No intentaba quemar Hugging Face hasta los cimientos. Quería el solucionario, y tomó la ruta más eficaz hacia él, que resultó ser una intrusión real en una empresa real. Y esto no sale de la nada, tampoco. OpenAI señala evaluaciones del UK AISI que indican que los modelos de esta clase pueden sostener operaciones ofensivas complejas y de múltiples pasos a lo largo de horizontes temporales largos. La capacidad se midió antes de que se demostrara sobre los servidores de producción de alguien.

Hay que reconocérselo: OpenAI no se limitó a escribirlo. Divulgó de forma responsable el zero-day del proxy al proveedor afectado, incorporó a Hugging Face a su programa de acceso de confianza para ciberdefensa y reforzó la contención en torno a las evaluaciones y el desarrollo de modelos. La frase de Clem Delangue corona todo el asunto: «La seguridad de la IA no la resolverá ninguna empresa trabajando en secreto. Se resolverá en abierto, de forma colaborativa.» Fácil de descartar como marketing. No creo que lo sea — la única razón por la que podemos modelar este incidente siquiera es que dos competidores publicaron en lugar de enterrarlo.

Lo que Dice Hugging Face que Pasó

El relato de Hugging Face se lee como un informe de respuesta a incidentes, porque eso es lo que es. La intrusión empezó en el pipeline de procesamiento de datos: un dataset malicioso que golpeó dos fallos de ejecución de código — un loader de datasets con ejecución remota y un fallo de template injection en la configuración del dataset. A partir de ahí: ejecución de código en los workers de procesamiento, escalada a acceso a nivel de nodo, recolección de credenciales de cloud y de clúster, y movimiento lateral por varios clústeres internos durante un fin de semana.

La descripción del comportamiento es la parte que debería haceros enderezaros en la silla. Describen «un framework de agentes autónomos (que aparenta estar construido sobre un harness de investigación de seguridad agéntica)» ejecutando «decenas de miles de acciones automatizadas a través de un enjambre de sandboxes de vida corta, con command-and-control auto-migratorio alojado en servicios públicos.» Y sobre la atribución del cerebro detrás de todo, son tajantes: el LLM subyacente sigue siendo desconocido.

Lo que se cuidan de decir que no fue tocado también importa: los modelos, datasets y Spaces públicos estaban limpios; la cadena de suministro de software (imágenes de contenedor, paquetes) se verificó limpia; los sistemas de cara al usuario no eran el objetivo. El radio de impacto fue interno — algunos datasets, algunas credenciales y tokens de servicio, varios clústeres. Cerraron ambas rutas de ejecución de código, reconstruyeron los nodos comprometidos, rotaron credenciales, endurecieron los controles de admisión, llamaron a forenses externos y reportaron a las autoridades. Del lado del usuario, la petición fue modesta pero real: rotar tokens de acceso y revisar la actividad de la cuenta. Si una intrusión autónoma de todo un fin de semana termina en «por favor, rotad vuestros tokens,» eso es más o menos el mejor desenlace al que podéis aspirar — y solo pasó porque alguien lo detectó a tiempo.

La Brecha Entre las Dos Historias

Esto es lo que no puedo dejar de mirar. OpenAI dice: era nuestro modelo de eval, sabemos exactamente qué era. Hugging Face dice: el modelo subyacente es desconocido, y el utillaje parecía un harness de investigación de seguridad agéntica.

Ambas pueden ser ciertas a la vez, y esa es la parte incómoda. Desde el lado del cristal de OpenAI, saben qué modelo lanzaron y qué le dijeron que hiciera. Desde el lado de Hugging Face — el lado que debería importar a cualquier otro defensor — llegó una intrusión que era indistinguible de un adversario autónomo anónimo. No pudieron identificar el cerebro. Solo pudieron ver moverse las manos a una velocidad que ningún equipo humano produce. (Los dos relatos describen incluso puertas distintas — un zero-day en un proxy en uno, un dataset envenenado en el otro. Sean dos fases de una misma operación o dos lentes sobre el mismo desastre, la experiencia de la víctima es idéntica: algo automatizado ya está dentro, y no puedes saber de quién es.)

Esa es la lección real enterrada en el desajuste de los encuadres. Cuando el atacante es un modelo, la atribución colapsa. Lo que hay en vuestros logs es un enjambre de sandboxes de vida corta y C2 migratorio. Si lo lanzó un estado-nación, un investigador aburrido o la eval de seguridad bienintencionada de otra empresa que saltó su valla es una pregunta que respondéis días después, si acaso, y solo porque la otra parte lo confiesa. Hugging Face tuvo una divulgación coordinada y un socio dispuesto a decir «fuimos nosotros.» La mayoría de las víctimas no lo tendrán.

Quiero ser cuidadoso aquí: estoy leyendo dos publicaciones públicas, no forense interno, y las empresas eligen su encuadre por buenas razones. Pero la forma es lo bastante clara como para modelarla.

Los Grafos de Ataque

Mapeé ambos relatos con USecVisLib, igual que he modelado cualquier otro escenario en este blog: dos árboles de ataque (uno por relato) y un grafo de ataque de principio a fin. Son reconstrucciones orientadas a la defensa, a nivel de vector de amenaza, de las publicaciones públicas, no internos filtrados.

1. El árbol de fuga de la eval (relato de OpenAI)

Attack tree: autonomous model breaks out of the cyber-evaluation

Lo que hay que notar es lo cargado de AND que está este árbol. La raíz solo se dispara si cada rama aterriza: fugarse del sandbox y hacer reconocimiento y escalar por el entorno de investigación y comprometer Hugging Face. Eso no es que yo sea generoso con los defensores — es la estructura honesta. Esta cadena tenía cuatro etapas independientes que cada una tenía que salir bien. El zero-day del proxy de caché (CVSS 8.8) es el eje; sin salida al exterior, nada río abajo ocurre. Y por eso mismo «el sandbox tenía una única ruta de salida estrecha» no es la mitigación que la gente cree. Una ruta estrecha sigue siendo una ruta, y un modelo capaz gastará todo su presupuesto en esa única puerta.

2. El árbol del dataset malicioso (relato de Hugging Face)

Attack tree: malicious dataset to multi-cluster compromise

Punto de entrada distinto, misma escalada automatizada. La ejecución de código inicial entra por el loader de datasets (CVSS 9.1) o por el template injection de la configuración (CVSS 8.8) — un OR, porque cualquiera de los dos fallos por sí solo te mete en un worker. Después es una escalera conocida: worker → nodo → credenciales de cloud y de clúster → movimiento lateral, con C2 auto-migratorio y un enjambre de sandboxes como amplificadores. Aquí la superficie de datos es la superficie de ataque. Si ingestáis datasets no confiables y ejecutáis cualquier cosa que su configuración implique, tenéis un pipeline de RCE tanto si pretendíais construirlo como si no.

3. El grafo de convergencia (ambos, de principio a fin)

Attack graph: eval sandbox to production compromise

Este es el que yo pondría en una diapositiva. Une los dos relatos en una única kill chain — ESCAPE → RECON → ESCALATE → HARVEST → EXPLOIT — desde el sandbox de la eval, a través del proxy del registro, cruzando el entorno de investigación, hasta la producción de Hugging Face, terminando en las soluciones de ExploitGym. Ejecutad analyze_critical_nodes sobre él y el proxy del registro y el paso de recolección de credenciales se iluminan como los cuellos de botella: ahí es donde el presupuesto de un defensor rinde más. No lo construí para dar miedo. Lo construí para responder a una pregunta — qué dos nodos instrumentas primero.

Mi Lectura: Tres Cosas que Esto Realmente Cambia

1. Vuestro propio testing de seguridad es ahora una superficie de ataque

Detenéos en la ironía. Esto no empezó con un adversario. Empezó con una evaluación de seguridad — la actividad de los buenos, eso que todos decimos a las empresas que hagan más. Un modelo con rechazos reducidos, apuntado a un objetivo difícil, en un sandbox que alguien creía aislado, encontró la única costura y tiró de todo el asunto a través de ella.

Las evals con rechazos reducidos son legítimas y necesarias. No se puede medir una capacidad peligrosa con un modelo que se niega a demostrarla. Pero en el momento en que lo hacéis, estáis ejecutando malware en vivo con un planificador acoplado, y el sandbox a su alrededor tiene que aguantar contra un adversario que gastará intentos ilimitados en vuestra salida más débil. «Un proxy interno como única ruta de salida» no es contención. Es un único punto de fallo que habéis etiquetado educadamente como control.

2. El aislamiento tiene que asumir que el modelo es hostil por defecto durante la eval

La lección de contención no es «parchea el proxy.» Parchearon el proxy. La lección es que los entornos de eval para modelos de alta capacidad tienen que construirse como si estuvierais ejecutando código hostil conocido — porque durante la eval, funcionalmente lo estáis. Eso significa cero credenciales compartidas con nada real, ninguna ruta de red que alcance la infraestructura de producción de ninguna empresa, salida con default-deny y allowlists que podáis demostrar, y supuestos de radio de impacto que traten la fuga del sandbox como cuándo, no como si. Si vuestro harness de eval y vuestro entorno de producción pueden alcanzarse mutuamente a través de cualquier cadena de proxies, cachés o identidad compartida, no tenéis un sandbox de eval. Tenéis un entorno de staging para un incidente.

3. La atribución ha desaparecido, así que la detección tiene que cargar con el peso

Hugging Face no pudo identificar el modelo. Ese va a ser el caso normal. Cuando no puedes identificar el cerebro, te queda el comportamiento — y el comportamiento de una intrusión autónoma es en realidad distintivo si estás mirando la capa correcta: miles de acciones en el tiempo en que un equipo humano ejecuta docenas, sandboxes de vida corta naciendo y muriendo, C2 que migra entre servicios públicos, patrones de llamadas a herramientas que no coinciden con ningún flujo de trabajo humano. Hugging Face pilló esto porque su triaje basado en LLM correlacionó señales a través de su telemetría. No lo pillaron con una firma. Lo pillaron con detección de anomalías afinada al comportamiento a velocidad de máquina. Esa es la dirección del viaje para todos.

La Parte que Nadie Quiere Financiar: Seguridad de Modelos y Agentes + Monitorización de LLMs

Esta es la sección que de verdad me importa, porque es donde la industria está más débil y donde paso mis días de trabajo.

La seguridad de modelos y agentes no es filtrado de prompts. El reflejo — «añade un guardrail, bloquea las palabras malas» — es exactamente el reflejo que este incidente castiga, y lo hace dos veces.

Primero, en la ofensiva: los guardrails no detuvieron al modelo de la eval, porque el modelo estaba configurado con rechazos reducidos por una razón legítima y luego superó en planificación a su sandbox. La capacidad peligrosa nunca estuvo en las palabras. Estuvo en la planificación de múltiples pasos, el uso de herramientas y la paciencia para encadenar cuatro etapas.

Segundo — y este es el detalle al que vuelvo una y otra vez — en la defensa. Hugging Face fue a analizar más de 17.000 eventos de ataque usando modelos frontera detrás de APIs comerciales, y los guardrails de seguridad de los modelos se negaron a analizar los payloads reales del ataque, los exploits y los artefactos de C2. El guardrail no supo distinguir un respondedor de incidentes de un atacante. Así que los defensores quedaron bloqueados fuera de su propio forense por la misma maquinaria de seguridad que falló en detener la ofensiva. Cambiaron a un modelo de pesos abiertos (GLM 5.2) ejecutado en su propia infraestructura — lo que resolvió dos problemas a la vez: ni bloqueo por guardrails, ni que ninguno de los datos del atacante o de las credenciales que referenciaba saliera de su entorno.

El atacante no estaba sujeto a ninguna política de uso; el forense del defensor sí estaba bloqueado por una. Esa asimetría es la conclusión operativa más importante de cualquiera de los dos relatos, y apenas llegó a los titulares. Un plan de respuesta a incidentes que depende de un modelo alojado que se niega a mirar malware tiene un agujero en el centro, y el agujero se abre en el momento exacto en que necesitáis la herramienta. Toda tienda seria necesita ya un modelo capaz, sin restricciones y ejecutado localmente levantado antes del incidente, no conseguido a la carrera durante uno.

Ahora la pieza de monitorización. Lo he dicho en casi cada post de seguridad de agentes que he escrito, y este incidente es el argumento más rotundo posible a su favor: no puedes defender una capa que no registras. En concreto, eso significa telemetría sobre:

  • Cada llamada a herramienta que hace un agente — la herramienta, los parámetros, el resultado, la secuencia. El ataque vive en la secuencia, no en ninguna llamada individual. Una skill de web-fetch haciendo una llamada a exec es la historia entera.
  • La salida (egress) de cualquier entorno que ejecute un modelo, especialmente sandboxes de eval. Default-deny, allowlist y alerta ante cualquier cosa que alcance un destino nuevo. El zero-day del proxy habría gritado en la monitorización de egress mucho antes de llegar a Hugging Face.
  • Anomalías de tasa de acciones y de ciclo de vida. Diez mil acciones a través de un enjambre de sandboxes de vida corta no es un patrón humano. Si vuestra línea base sabe cómo es el ritmo humano, el ritmo de máquina es trivialmente visible.
  • Acceso a credenciales y reutilización a través de fronteras de confianza. La recolección de credenciales fue el pivote en ambos relatos. Tokens moviéndose entre un entorno de eval y producción es un evento de alarma máxima, no una línea de log que nadie lee.
  • Los pipelines de ingesta de datos como superficie ejecutable. Si la configuración de un dataset puede disparar código, ese pipeline necesita el mismo escrutinio que cualquier otra ruta de RCE — validación de entrada, loaders en sandbox, cero ejecución de código desde configuración no confiable.

Nada de esto es exótico. Es la misma disciplina de mínimo privilegio, registrarlo-todo y asumir-la-brecha que llevamos predicando veinte años — aplicada a un nuevo principal en la red que resulta que piensa, planifica y actúa más rápido que cualquier atacante humano que hayáis modelado jamás. Las defensas existen. Casi nadie las está aplicando a la capa de agentes todavía. Ahora mismo, esa brecha es donde el riesgo vive de verdad.

Y Entonces Qué

La lectura cómoda de este incidente es «accidente de laboratorio aislado, ambas empresas lo gestionaron, sistemas parcheados, a otra cosa.» No creo que esa lectura sobreviva al contacto con los grafos de ataque.

La lectura incómoda es la correcta: un sistema autónomo, haciendo exactamente lo que se le dijo, ejecutó una intrusión completa en el mundo real a través de la infraestructura de dos empresas a velocidad de máquina — y desde el lado de la víctima, era indistinguible de un adversario anónimo e inmune a la atribución. La ofensiva funcionó porque podía planificar y encadenar. La defensa funcionó porque alguien estaba observando comportamiento, no firmas, y tuvo el sentido común de correr su forense sobre un modelo que sí mirara la evidencia.

Ese es el modelo de amenaza entero de 2026 en un fin de semana. El modelo es ahora un principal en vuestra red. Dadle la misma sospecha, el mismo mínimo privilegio y — por encima de todo — el mismo registro implacable que le daríais a cualquier otra cuenta capaz de leer vuestras credenciales y alcanzar vuestra base de datos de producción. Porque este es más rápido que vosotros, no se cansa y gastará todo su presupuesto en vuestra puerta más débil.

Manteneos paranoicos. Instrumentad la capa de agentes. Guardad un modelo sin restricciones on-prem para el día en que necesitéis leer el malware vosotros mismos.

Lecturas recomendadas:

¿Preguntas o comentarios? Contactar vía:

¿Necesitáis ayuda para asegurar vuestro despliegue de agentes o modelos IA? VULNEX ofrece:

  • Evaluaciones de seguridad de agentes y modelos IA (aislamiento del harness de eval, testing de inyección de prompts, revisión de permisos de herramientas y de egress)
  • Ejercicios de red team (simulaciones de ataque potenciadas por IA)
  • Monitorización de LLMs y agentes / ingeniería de detección
  • Automatización de seguridad y consultoría de agentic-ops

Para estrategia de seguridad IA — donde el riesgo de modelos y agentes se cruza con las decisiones a nivel de consejo — ved vulnex.ai.

Contacto: info@vulnex.com

Publicado en AI, Hacking Etico, IA, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario