Estrategias de Guerra de la Información (SRF-IWS): Operaciones ofensivas contra una visita papal — El Papa León XIV en Madrid 2026

Descargo de responsabilidad: Todo lo aquí descrito es pura imaginación y cualquier parecido con la realidad es mera coincidencia. Este documento está destinado a profesionales de la seguridad para desarrollar contramedidas defensivas. El autor no se hace responsable de las consecuencias de cualquier acción tomada a partir de la información proporcionada en este artículo. Mantengo cada escenario a nivel de vector de amenaza: sin detalle operativo, sin tácticas, sin información sobre armas, y cada uno va acompañado de una recomendación defensiva.

Nota: Como en el resto de la serie SRF-IWS, me he apoyado en varios modelos de IA para construir escenarios de ataque realistas y orientados a la defensa. El objetivo es la planificación del Blue Team, nada más.

Una nota sobre la serie. Este artículo pertenece a SRF-IWS, pero no es una continuación de los artículos de Davos. Aquellos (Davos 2024, 2025 y 2026) son su propia línea de análisis sobre el Foro Económico Mundial; este se sostiene por sí mismo y simplemente comparte el mismo marco de trabajo. Sí los referencio a lo largo del texto para dar contexto, así que merece la pena leerlos como base. La diferencia esta vez es el protegido: en lugar de un foro corporativo, hablamos de un jefe de la fe y jefe del Estado vaticano, al aire libre, en mitad de una capital europea y rodeado de más de un millón de personas.


Introducción

Del 6 al 9 de junio de 2026, el Papa León XIV, el primer pontífice norteamericano, estará en Madrid como primera etapa de su viaje apostólico a España (Madrid, Barcelona y Canarias, del 6 al 12 de junio). Es la primera visita papal a la capital en quince años, desde Benedicto XVI y la Jornada Mundial de la Juventud de 2011. El programa de Madrid es denso y, desde el punto de vista de la inteligencia de protección, está completamente expuesto:

  • Llegada el 6 de junio, con visita de cortesía al Rey Felipe VI, la Reina Letizia y la Familia Real.
  • Una vigilia de oración con jóvenes en la Plaza de Lima, en el Paseo de la Castellana, esa misma tarde.
  • El domingo 7 de junio, solemnidad del Corpus Christi, una misa al aire libre en la Plaza de Cibeles seguida de una procesión eucarística por el centro de Madrid.
  • El lunes 8 de junio, un discurso ante el Parlamento en el Congreso de los Diputados y, más tarde, un encuentro con la comunidad diocesana en el Santiago Bernabéu.
  • Movimientos del papamóvil y la comitiva concentrados en el eje Castellana–Cibeles–Lima y en los nodos fijos: Barajas, el Palacio Real, el Congreso y el Bernabéu.

El discurso en el Parlamento merece su propia línea, porque es realmente histórico. Por primera vez, un Papa hablará ante una sesión conjunta de las Cortes Generales, diputados y senadores juntos. Juan Pablo II visitó España cinco veces y Benedicto XVI tres, y ninguno se dirigió nunca a la cámara. Es justo el tipo de momento de alta carga simbólica y alto protocolo que un adversario adora.

Las autoridades estatales y municipales han montado un dispositivo de seguridad y movilidad sin precedentes en la ciudad, con una asistencia prevista de hasta 1,8 millones de personas en los actos principales. El lema elegido, «Alzad la mirada» (Juan 4:35), y el énfasis de León XIV en la migración, el viaje termina en Canarias, la principal puerta atlántica de entrada de migrantes a España, convierten esto en algo más que un problema de seguridad física. Es un objetivo casi perfecto para la guerra de la información: televisado a nivel mundial, construido sobre un asunto polarizante y con un protegido cuya cada frase tiene peso geopolítico.

Un Papa no es un delegado de Davos, y el abanico de amenazas es mucho más amplio. Tienes extremistas de motivación religiosa, tanto yihadistas como anticatólicos; sectores tradicionalistas y sedevacantistas; corrientes anticlericales y anarquistas; extremistas antiinmigración reaccionando al mensaje del Papa; actores solitarios movidos por agravios; y operaciones de información de Estados-nación buscando instrumentalizar el espectáculo. Nada de esto es hipotético. Los pontífices han sido siempre objetivos. A Juan Pablo II le dispararon en la Plaza de San Pedro en 1981. Lo volvieron a atacar en 1982 en Fátima, con una bayoneta, a manos de un sacerdote español, Juan María Fernández y Krohn. El complot Bojinka de 1995 en Manila incluía un plan para asesinarlo. Son hechos documentados, y razón suficiente para planificar en serio.

Lo que sigue son escenarios realistas y orientados a la defensa en los dominios de la información, ciber, RF, drones, multitudes y físico. Cada uno empareja el ataque con su propia defensa, en la misma sección.


1. Desinformación y la narrativa migratoria

El vector más probable y más dañino aquí no es una bomba ni un rifle. Es la información. La visita de León XIV gira en torno a la migración y aterriza en mitad de un debate migratorio español muy vivo, que es justo el terreno sobre el que les gusta trabajar a las operaciones de influencia, vengan de un actor estatal que quiere avivar las fracturas españolas y de la UE o de extremistas domésticos de uno u otro extremo.

La campaña que yo esperaría sería algo así. «Citas» papales fabricadas, texto, imágenes y clips cortos generados por IA que ponen en boca del Papa posiciones incendiarias sobre la inmigración, el Gobierno, Cataluña o la monarquía, soltadas unas horas antes de un acto clave para dominar el ciclo informativo. Fragmentos de homilía manipulados, audio o vídeo de la misa de Cibeles o del discurso en el Congreso, recortados selectivamente o falsificados por completo para fabricar indignación en cualquier dirección y atraer gente a las inmediaciones de los actos a enfrentarse. «Filtraciones» falsas, documentos forjados del Vaticano o de Moncloa que aleguen pactos políticos secretos ligados a la visita, diseñados para que tanto la Iglesia como el Estado parezcan estar ocultando algo. Indignación inflada por redes inauténticas que empujan hashtags divisivos, testimonios falsos de testigos y reportes falsos de incidentes para asustar a la gente o provocar un enfrentamiento. Y el más simple, cuentas suplantadas y dominios calcados que imitan las webs oficiales de inscripción e información para repartir horarios falsos, «cancelaciones» falsas o enlaces maliciosos.

01-disinformation

Figura 1 — Árbol de ataque de la desinformación y la narrativa migratoria, generado con USecVisLib.

Defensa

Esto hay que tratarlo como una función de seguridad de primer orden, no como una ocurrencia de prensa. Eso significa una célula de comunicación conjunta Vaticano–España con autoridad para desmentir rápido, audio y vídeo oficiales firmados en origen (procedencia tipo C2PA), una cadena activa para vigilar y dar de baja dominios calcados, y un único canal verificado en el que el público sepa que puede confiar. Si hay una sola fuente autorizada, la mayoría de las falsificaciones se quedan sin oxígeno.


2. Deepfakes y medios sintéticos

Esto lo traté a fondo en el análisis de Davos 2026, y no se ha vuelto más fácil de defender. Los deepfakes en tiempo real son maduros, la clonación de voz necesita solo unos segundos de audio, y la gente solo detecta un buen deepfake de vídeo una fracción de las veces. Un Papa retransmitido a nivel mundial, con un enorme archivo público de audio y vídeo, es prácticamente el mejor sujeto de entrenamiento que existe. También lo es el Rey, y también los organizadores principales.

Los escenarios que me preocupan son los que suplantan a la autoridad. Un anuncio «oficial» falso de evacuación, o un aviso de «artefacto encontrado», metido en un sistema de megafonía comprometido, una señalética digital secuestrada o un canal de alertas suplantado en Cibeles, Lima o el Bernabéu, con el fin de provocar el pánico (ver sección 3). Tráfico de radio con voz clonada haciéndose pasar por un mando de incidente o por un equipo de avanzada del Vaticano para redirigir unidades, alterar los tiempos de la comitiva o abrir un hueco. Grabaciones «privadas» sintéticas del Papa y el Rey, o del Papa y cargos del Gobierno, inventando compromisos o insultos que nunca se dijeron, lanzadas para envenenar la diplomacia de la visita. O imágenes fabricadas «entre bastidores» calculadas para tapar el discurso en el Parlamento.

02-deepfake

Figura 2 — Árbol de ataque de deepfakes y medios sintéticos (USecVisLib).

Defensa

La respuesta defensiva es clásica y funciona: verificación fuera de banda y desafío/respuesta para toda comunicación de mando, de avanzada y de protocolo. Ninguna unidad actúa solo por una voz o una cara. Encima de eso, detección de deepfakes en las señales de retransmisión monitorizadas, blindar megafonía, señalética y alertas como infraestructura crítica con autenticación real, y dejar guionizado de antemano el mensaje a la multitud, de forma que lo que el público oiga llegue solo por canales verificados y redundantes.


3. La multitud como arma

Con hasta 1,8 millones de personas repartidas por Cibeles, Lima, el recorrido de la procesión y el Bernabéu, el desenlace con más probabilidad de causar víctimas en masa no necesita arma alguna. Solo hay que provocar el pánico en una multitud densa. Es el vector más infravalorado de la lista, y no es teórico, la historia es larga y siniestra: Hillsborough, el Love Parade de 2010, la avalancha de Mina de 2015 durante el Hajj, Itaewon en 2022, Astroworld en 2021.

¿Cómo lo harías? Lanzas una falsa alarma sincronizada, un rumor de disparos, una «bomba», un incendio, propagado por SMS y redes sociales, un único estruendo provocado o una señalética secuestrada, y lo colocas en un cuello de botella donde la densidad ya es crítica: los accesos estrechos a Cibeles o Lima, una grada del estadio. Lo emparejas con denegación de comunicaciones, interferir o saturar la red móvil y el wifi para que la multitud no pueda orientarse y el mensaje oficial no llegue, y dejas que el rumor llene el vacío (esto enlaza con la sección 7). Le añades manipulación del flujo, bloqueas o señalizas en falso las salidas, y una densidad controlable se convierte en un colapso progresivo. Y si quieres desbordar la respuesta, inicias en varios puntos separados a la vez para que el acomodo y los servicios de emergencia se fragmenten.

03-crowd

Figura 3 — Árbol de ataque de pánico provocado y avalancha de multitud (USecVisLib).

Defensa

Defenderlo se reduce a ver la densidad en tiempo real y poder actuar sobre ella. Monitorización óptica y térmica aérea más analítica anonimizada de densidad de móviles, con umbrales rígidos y dosificación y control de flujo reversibles planificados de antemano. Una megafonía que resista las interferencias. Acomodadores entrenados para matar rumores en el sitio. Salidas diseñadas, bien señalizadas y sobredimensionadas. Y una única imagen de mando de incidente unificada, para que un pequeño evento local nunca tenga la ocasión de propagarse.


4. Drones y contra-UAS

Espacios abiertos como Cibeles, Lima, el recorrido de la procesión y el cuenco abierto del Bernabéu son justo los lugares que explotan los drones pequeños. El problema de coste que describí en el análisis de Davos 2026 sigue vigente: los drones son baratos, las defensas son caras, y un enjambre puede simplemente saturar las defensas puntuales.

Los usos son conocidos. Vigilancia y adquisición de objetivos, pequeños cuadricópteros mapeando posiciones de seguridad, tiempos de la comitiva y ubicaciones VIP en tiempo real. Entrega de carga de pánico, un dron dispersando humo, un irritante o pirotecnia sobre una multitud densa, donde el objetivo es el pánico y la avalancha más que las víctimas directas. Saturación con enjambres y señuelos, drones desechables absorbiendo el esfuerzo contra-UAS mientras una plataforma principal termina su trabajo, o drones FPV usando los cañones urbanos para una aproximación baja y rápida. Y cargas RF, interferidores o IMSI-catchers aéreos degradando las comunicaciones y recopilando inteligencia sobre la multitud.

04-drone-uas

Figura 4 — Árbol de ataque de drones y contra-UAS (USecVisLib).

Defensa

La defensa tiene que ser por capas y multimodal, radar más RF más acústica más electroóptica/infrarroja, para que ningún truco aislado la deje ciega. Hacer cumplir las zonas de exclusión aérea y las restricciones temporales de vuelo con la autoridad legal para realmente actuar ante una violación. Pre-posicionar efectores en las líneas de aproximación probables. Y, esto importa más aquí que en Davos, elegir una mitigación que no haga daño ni provoque el pánico de una multitud de 1,8 millones de personas. La detección, la toma de control por RF y el geovallado, y la interceptación controlada van mucho antes que cualquier opción cinética sobre las cabezas de la gente.


5. La comitiva y el papamóvil

Los movimientos se concentran en un eje predecible, Castellana–Cibeles–Lima, y en nodos fijos de llegada y salida: Barajas, el Palacio Real, el Congreso, el Bernabéu. La previsibilidad más un papamóvil lento, abierto, a pie de valla, es el dilema clásico de la protección, y no hay manera ingeniosa de esquivarlo.

Las vías de explotación se entienden bien. Operaciones en el punto de estrangulamiento, la vigilancia escoge un punto lento fijo para un acto hostil, un disturbio provocado o una denegación de comunicaciones. Spoofing o interferencia del GPS de los vehículos de escolta para fragmentar la comitiva o desviar las unidades de apoyo y médicas; la captura por Irán de un dron estadounidense RQ-170 es el precedente de manual para el spoofing de GNSS incluso en una plataforma avanzada. Vehículo como arma, la amenaza europea más ensayada desde Niza y Berlín en 2016, un vehículo hostil lanzado contra un tramo del recorrido denso de peatones. Y el viejo reconocimiento hostil de puestos estáticos y horarios de antemano.

05-motorcade

Figura 5 — Árbol de ataque de la comitiva y el papamóvil (USecVisLib).

Defensa

Defender el desplazamiento significa aleatorizar ruta y horario allá donde el programa lo permita, poner mitigación de vehículos hostiles, barreras, zonas estériles, cruces controlados, a lo largo de todo el eje de cara a la multitud, y dotar a los vehículos de escolta de GNSS multiconstelación anti-spoofing con respaldo inercial. Añade contravigilancia agresiva, domina las azoteas y posiciones elevadas con observación amiga y cobertura contra-francotirador, y configura el papamóvil equilibrando la visibilidad pastoral con la protección. Siempre será un compromiso; que al menos sea uno deliberado.


6. Ciberataques al evento y a la ciudad

La visita funciona sobre mucho software. Un sistema masivo de inscripción pública que guarda los datos personales de potencialmente millones, acreditación y credenciales, ticketing, CCTV y control de accesos, la gestión de tráfico y movilidad de Madrid, los despachos de emergencia. Como demostró el caso GTG-1002 del análisis de Davos 2026, los agentes de IA pueden mapear y explotar un ecosistema así a velocidad de máquina, encontrando caminos que un humano pasaría por alto.

Los movimientos evidentes: vulnerar el sistema de inscripción e instrumentalizar los datos, exfiltrar los registros de asistentes para adquisición de objetivos, doxing o spear-phishing, o corromper las listas de acceso para crear caos en las puertas. Forjar credenciales comprometiendo la cadena de acreditación y fabricar acceso de insider en un rol de prensa, voluntariado o contratista. Cegar la vigilancia, manipular CCTV y control de accesos para abrir puntos ciegos programados. Golpear los sistemas de la ciudad, gestión de tráfico y señalética durante las ventanas de la comitiva, o el despacho de emergencias durante un incidente, que es como un evento ciber se convierte en un evento de seguridad física. Y el más simple, DDoS o defacement de los canales oficiales de información en el momento en que la atención del público alcanza su pico, lo que devuelve directamente a la sección 1.

06-cyber

Figura 6 — Árbol de ataque de los ciberataques al evento y a los sistemas de la ciudad (USecVisLib).

Defensa

La defensa es poco vistosa y necesaria: hacer red team a cada sistema del evento y de la ciudad dentro del alcance antes de la visita, segmentar los sistemas de seguridad para la vida y de control de accesos para que no sean alcanzables desde todo lo demás, aplicar Privilegio Cero Permanente (ZSP) y Acceso Justo a Tiempo (JITA) para que una credencial robada compre muy poco, poner monitorización de integridad sobre las listas de acreditación y acceso, y asegurarse de que cada función crítica para la vida tenga un respaldo manual probado para el día en que el software mienta.


7. RF y el espectro

Este es mi terreno y es de gran impacto. En España, las fuerzas y cuerpos de seguridad del Estado, Policía Nacional y Guardia Civil, funcionan sobre SIRDEE, la red troncalizada cifrada y de cobertura nacional basada en TETRAPOL. (Un detalle que conviene precisar: SIRDEE es TETRAPOL, no TETRA. TETRA es un estándar distinto que usan varios servicios autonómicos y municipales. La gente confunde los dos constantemente.) Sea cual sea la tecnología, todo el evento depende de un espectro resiliente.

Los ataques. Interferir SIRDEE, las radios de coordinación del evento y las bandas móviles en un momento crítico, lo que degrada el mando, amplifica la confusión de la multitud (sección 3) y aísla los puestos. Hacer spoofing del GPS/GNSS para corromper la sincronización, el geovallado, el seguimiento contra-UAS y la navegación de la comitiva (sección 5). Desplegar IMSI-catchers o células piratas para rastrear e interceptar a VIPs y a la multitud. Levantar puntos de acceso piratas cerca de los recintos y las áreas de mando para capturar tráfico y pivotar, incluida la recolección «recoge ahora, descifra después» que describí en el análisis de Davos 2026.

07-rf

Figura 7 — Árbol de ataque de RF y guerra inalámbrica (USecVisLib).

Defensa

Defender el espectro significa vigilarlo. Monitorización continua y radiogoniometría por toda el área de operaciones para cazar interferidores, spoofers e IMSI-catchers según aparezcan. Comunicaciones primarias cifradas, con salto de frecuencia y resistentes a interferencias, con un respaldo no-RF, enlaces a pie y nodos cableados, para cuando la banda se apague. Monitorización de integridad de GNSS con posicionamiento de respaldo. E higiene de RF básica, nada sensible por un canal que pueda estar comprometido.


8. Insiders y cadena de suministro

Una visita así moviliza una fuerza de trabajo enorme y montada a toda prisa. Solo el coro oficial, el Gran Coro de Voces Católicas, tiene más de 1.700 voluntarios, y eso antes de contar acomodadores, contratistas, catering, audiovisuales, transporte y proveedores de seguridad por todos los recintos. El problema del eslabón más débil crece con esa huella.

Lo que yo vigilaría: un voluntario o contratista infiltrado allá donde el alta masiva adelanta a la verificación. Un compromiso previo del equipo audiovisual y técnico en la cámara del Congreso, el Palacio Real o el Bernabéu, un dispositivo de escucha o grabación implantado, o un sistema de producción manipulado que alimente las jugadas de desinformación y deepfakes de las secciones 1 y 2. Acceso por logística, proveedores de catering, limpieza y equipamiento como vía hacia las áreas estériles. Y los proveedores de transporte, donde las credenciales de conductor y los datos de seguimiento de vehículos revelan en silencio los movimientos protegidos.

08-insider-supplychain

Figura 8 — Árbol de ataque de insiders y cadena de suministro (USecVisLib).

Defensa

Las contramedidas son proporcionalidad y disciplina. Verificar al nivel del acceso, con el escrutinio más profundo para los roles técnicos, audiovisuales, de transporte y de área estéril. Acceso físico de mínimo privilegio con escolta auditada. Barridos TSCM de cada recinto donde se hable antes de su uso, y mantener la zona estéril después. Y poner requisitos reales de seguridad a los proveedores, con monitorización continua y un respaldo para todo lo esencial.


9. Físico y NRBQ, a nivel de doctrina de protección

Lo mantendré al nivel contra el que de verdad planifica un equipo de protección, y lo anclaré otra vez en el historial: 1981 en la Plaza de San Pedro, 1982 en Fátima, el complot Bojinka de 1995.

Los vectores con los que hay que contar son la aproximación cercana de un actor solitario en una valla, la procesión o el recorrido del papamóvil, una amenaza con arma blanca u objeto arrojado desde dentro de una multitud autorizada; una posición de tiro elevada a lo largo del eje de la Castellana o alrededor de las plazas abiertas, que es para lo que existen la gestión de líneas de visión y la cobertura contra-francotirador; una dispersión química o irritante de bajo grado en la multitud cuyo efecto real es el pánico y la avalancha (secciones 3 y 4) más que la toxicidad masiva; y un explosivo improvisado o transportado en vehículo en el perímetro de un recinto o a lo largo del recorrido.

09-physical-cbrn

Figura 9 — Árbol de ataque físico y NRBQ en multitud (USecVisLib).

Defensa

Contra todo eso: zonas estériles con cacheo y arcos de detección en accesos controlados, dominio contra-francotirador y de posiciones elevadas con las estructuras inspeccionadas de antemano, mitigación de vehículos hostiles en cada ruta de cara a la multitud, detección y descontaminación NRBQ preparadas para una contingencia de víctimas en masa, una presencia saturadora de uniformados y de paisano en las vallas, y capacidad médica redundante pre-posicionada y ajustada al mapa de densidad.


10. El escenario de convergencia

Si hay una tesis en toda esta serie, es que la amenaza que define la época no es ningún vector aislado. Es la secuenciación deliberada de varios de ellos, y rápido. Aplicado a esta visita, se lee así. En los días previos, una campaña de desinformación (sección 1) polariza al público y siembra contramovilización cerca de los recintos. En el momento elegido, acciones coordinadas de ciber (sección 6) y RF (sección 7) degradan el CCTV, las comunicaciones y la conciencia situacional. Una carga lanzada por dron o un reporte provocado (secciones 3 y 4) inicia el pánico en un cuello de botella crítico. Una orden «oficial» de evacuación deepfake (sección 2), empujada por señalética o megafonía comprometidas, convierte ese pánico en una avalancha. Y en el caos, se persigue un objetivo principal mientras una narrativa falsa preparada de antemano (sección 1) reclama y enmarca el evento para el mundo antes de que las autoridades puedan decir una palabra.

10-convergence-graph

Figura 10 — El escenario de convergencia como grafo de ataque: preparar, cegar, disparar, amplificar, explotar, con vulnerabilidades puntuadas por CVSS a lo largo de la cadena (USecVisLib).

Defensa

Ninguna contramedida aislada detiene eso. Lo único que lo hace es una defensa integrada, rápida y multidominio construida sobre una única imagen compartida de lo que está pasando: una única imagen operativa común compartida por la seguridad de la Casa Real, la Policía Nacional, la Guardia Civil, la Policía Municipal de Madrid, la Gendarmería y el equipo de avanzada del Vaticano, y los servicios de inteligencia, correlacionada lo bastante rápido como para que sirva. Cada defensa por sección de las anteriores alimenta esa única imagen, porque el ataque de convergencia es precisamente el que una defensa fragmentada y a velocidad humana no puede responder.


Conclusión

Una visita papal comprime todos los dominios de amenaza en un único evento televisado, al aire libre y cargado ideológicamente. Las lecciones de la serie SRF-IWS se aplican todas, pero el protegido cambia las cuentas.

El primer punto es que la información es el campo de batalla principal. Para un Papa que habla de migración ante el Parlamento y una multitud de 1,8 millones, los vectores de desinformación y deepfake son más probables, y seguramente más graves, que cualquier acto cinético. La comunicación estratégica es una función de seguridad, y punto.

El segundo es que la multitud es a la vez el público y el arma. Se pueden producir víctimas en masa en una multitud densa sin disparar un solo tiro, solo provocando el pánico. La dinámica de multitudes merece el mismo esfuerzo de planificación que la cobertura contra-francotirador.

El tercero es la convergencia. Desinformación que prepara, ciber y RF que ciegan, drones que disparan el gatillo, deepfakes que amplifican, encadenados y rápido. La defensa tiene que ser igual de integrada e igual de rápida.

El cuarto es que la historia es la advertencia. Los ataques a pontífices son un hecho documentado, no imaginación, y la planificación tiene que respetar ese historial.

Y el último es que la velocidad y la unidad deciden el resultado. Una defensa fragmentada y a velocidad humana no puede responder a una operación coordinada y multidominio. Una única imagen de mando compartida es el precio de la entrada.

El sentido de escribir todo esto es simple: los defensores, no los adversarios, deberían ser los primeros en haberlo pensado a fondo.

SRF

Sígueme: @simonroses

Este artículo continúa la investigación SRF-IWS sobre estrategias de guerra de la información aplicadas a entornos de protección de alto perfil.

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

Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto (Parte 6)

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 (estás aquí)
  7. Prompt Engineering para Código Seguro (próximamente)
  8. El Checklist de Seguridad del Fundador (próximamente)
  9. Asegurando el Pipeline de Codificación IA (próximamente)
  10. El Futuro de la Seguridad del Vibe Coding (próximamente)

Tiempo de lectura: 20 minutos

TL;DR

Los escáneres de seguridad tradicionales buscan coincidencias de patrones en código que existe. Las vulnerabilidades más peligrosas de las aplicaciones vibe-coded están en código que no existe — controles de autenticación ausentes, falta de limitación de peticiones, lógica de autorización inexistente. Un benchmark SAST de enero de 2026 encontró que las herramientas marcaban como vulnerable entre el 68% y el 75% del código seguro mientras los fallos arquitectónicos pasaban desapercibidos, y Georgia Tech ha rastreado 74 CVEs atribuidos a IA con descubrimientos mensuales que crecieron 6x en dos meses. Las nuevas herramientas nativas de IA están cerrando la brecha, pero a mediados de 2026, la autorización rota y los controles de seguridad ausentes siguen requiriendo revisión humana. Este artículo cubre qué funciona, qué no, y cómo construir un pipeline de escaneo para código generado por IA.


La Paradoja del Escaneo

Tenemos más herramientas de escaneo de seguridad que en cualquier otro momento de la historia del desarrollo de software. SAST, DAST, SCA, IAST, RASP — solo la cantidad de acrónimos sugiere que el problema debería estar resuelto. Y para código escrito por humanos, estas herramientas han ido mejorando de forma constante durante dos décadas. El problema es que las aplicaciones vibe-coded no fallan como las escritas por humanos.

Cuando un desarrollador humano introduce una inyección SQL, normalmente es porque olvidó parametrizar una consulta. Una herramienta SAST detecta la concatenación de cadenas dentro de una llamada SQL por coincidencia de patrones y la marca. Sencillo. Cuando una herramienta de codificación IA introduce un fallo de seguridad, el código suele ser sintácticamente limpio, sigue patrones documentados de la API y pasa todas las pruebas funcionales. La vulnerabilidad no está en cómo está escrito el código — está en lo que el código no hace. Falta validación en el servidor. Falta limitación de peticiones. Faltan controles de autorización. Faltan políticas RLS. No puedes detectar por coincidencia de patrones el código que no existe.

El Vibe Security Radar de Georgia Tech, lanzado en mayo de 2025, rastrea CVEs atribuibles a herramientas de codificación IA trazando los commits de corrección hacia atrás en el historial de Git. Sus cifras lo dicen todo: 6 CVEs atribuidos a IA en enero de 2026, 15 en febrero, 35 en marzo. Un aumento de casi 6x en dos meses. El total confirmado se sitúa en 74, y los investigadores estiman que la cifra real es entre 5 y 10 veces mayor porque la mayoría del código generado por IA no deja marcadores de atribución claros.

Mientras tanto, el informe de estrategia de emergencia de la Cloud Security Alliance — elaborado en un solo fin de semana por más de 60 colaboradores incluyendo a Jen Easterly y Bruce Schneier — advertía que la ventana para corregir vulnerabilidades se está desplomando: el tiempo medio desde la divulgación hasta la explotación confirmada ha caído a menos de un día en 2026, frente a los 2,3 años de 2019. Investigaciones separadas de la CSA han encontrado que el 62% de las muestras de código generado por IA contenían vulnerabilidades.

Los escáneres están funcionando, las vulnerabilidades siguen llegando a producción, y la brecha se amplía.


Qué Detecta Realmente el SAST (Y Qué No)

Static Application Security Testing funciona analizando código fuente sin ejecutarlo. Herramientas como CodeQL, Semgrep, SonarQube y Checkmarx parsean el código en un árbol de sintaxis abstracta y luego buscan coincidencias de patrones contra firmas de vulnerabilidades conocidas — concatenación de cadenas en consultas SQL, eval() sobre entrada no confiable, funciones criptográficas obsoletas. Estos son patrones bien definidos, y SAST los maneja de forma fiable.

El problema son los falsos positivos y los puntos ciegos estructurales.

El Problema de los Falsos Positivos

Un estudio de enero de 2026 evaluó CodeQL, Semgrep, SonarQube y Joern contra OWASP Benchmark v1.2 — 2.740 casos de prueba en Java con estado de vulnerabilidad conocido. CodeQL obtuvo el mayor F1-score con 74,4%, pero marcó el 68,2% de los casos no vulnerables como positivos — 904 falsos positivos en todo el benchmark. SonarQube produjo 1.254 falsos positivos, cubriendo el 45,8% de todos los casos. Semgrep marcó el 74,8% de los casos no vulnerables. Joern tuvo menos falsos positivos con 96, pero alcanzó solo un 8,2% de recall — apenas detecta nada.

Para un vibe coder ejecutando Semgrep contra su código generado por IA por primera vez, esto significa que aproximadamente tres cuartas partes de las alertas que ve son ruido. Después del tercer falso positivo sobre una «inyección potencial» en código que en realidad es seguro, la mayoría acaba ignorando la salida. La señal se ahoga en el ruido, y los problemas reales — los que importan — pasan desapercibidos.

Un caso con el que me encuentro constantemente. En los últimos años he hecho muchas revisiones de código de aplicaciones basadas en AWS en VULNEX, y Semgrep marca los IDs de cuenta de AWS como fugas de información sensible en casi todos los proyectos. El problema es que la propia AWS no considera los IDs de cuenta como información sensible — su documentación indica explícitamente que se pueden compartir cuando sea necesario. Es un falso positivo que aparece en todos y cada uno de los proyectos AWS, entrenando a los equipos a ignorar la salida de Semgrep para ese código por completo. Siempre trabajo con el cliente para entender sus requisitos de privacidad específicos antes de descartar o escalar cualquier hallazgo — algunas organizaciones sí tratan los IDs de cuenta como información interna independientemente de lo que diga AWS — pero este es exactamente el tipo de ruido que erosiona la confianza en las herramientas automatizadas.

El Punto Ciego Estructural

Los falsos positivos son molestos pero manejables. El punto ciego estructural es el verdadero problema. SAST funciona buscando coincidencias de patrones en código que existe. Las vulnerabilidades del código vibe-coded suelen estar en código que no existe.

Pensemos en la aplicación QuickNote de la Parte 5. Los problemas más peligrosos no eran errores en el código — eran funcionalidades ausentes. Sin limitación de peticiones en el endpoint de login. Sin políticas RLS en la base de datos. Sin verificación de autorización en el servidor. Sin expiración de tokens. SAST no puede señalar la ausencia de un control de seguridad, porque no hay código que analizar. Es como pedirle a un corrector ortográfico que te diga que a tu ensayo le falta la conclusión.

Esto es lo que ocurre cuando ejecutas Semgrep contra una aplicación Express.js vibe-coded típica:

semgrep --config=auto ./src

Semgrep probablemente marcará cosas como el uso de innerHTML (problema real — XSS), llamadas a eval() si las hay, y quizás la función de hash MD5. Lo que no marcará: que el endpoint /api/users/:id/notes carece de verificación de propiedad, que jwt.sign() se llamó sin parámetro expiresIn, que toda la aplicación no tiene middleware de limitación de peticiones, que Supabase RLS está deshabilitado en todas las tablas.

Estas son las clases de vulnerabilidad que más importan en aplicaciones vibe-coded, y SAST es estructuralmente incapaz de detectarlas.

Para Qué Sirve el SAST

Esto no es un argumento para dejar de usar SAST. La coincidencia de patrones detecta problemas reales: credenciales hardcodeadas (cuando coinciden con patrones conocidos), llamadas a funciones peligrosas, uso de bibliotecas con vulnerabilidades conocidas, vectores de inyección obvios. Para el subconjunto de vulnerabilidades que parecen errores tradicionales, SAST funciona. El problema es que en aplicaciones vibe-coded, ese subconjunto cubre quizás el 30% de la superficie de riesgo real. El otro 70% es arquitectónico.


Lo Que el DAST No Detecta en la Era de las SPA

Dynamic Application Security Testing adopta el enfoque opuesto — en vez de leer código fuente, ejecuta la aplicación y la ataca desde fuera. OWASP ZAP y Burp Suite envían payloads maliciosos a los endpoints, monitorizan las respuestas y marcan comportamientos que indican vulnerabilidades. Si puedes provocar una inyección SQL mediante una petición HTTP, DAST lo encuentra. Si un payload XSS reflejado aparece en la respuesta, DAST lo detecta.

Para aplicaciones web tradicionales renderizadas en servidor, DAST ha sido razonablemente eficaz. Pero las aplicaciones vibe-coded son abrumadoramente aplicaciones de página única (SPA) construidas con React, Next.js o Vue, y la arquitectura de DAST no funciona bien con ellas.

El Problema del Rastreo

DAST descubre la funcionalidad de las aplicaciones rastreando — siguiendo enlaces, enviando formularios, parseando HTML. Las SPA no funcionan así. Las rutas se gestionan en el cliente mediante JavaScript. Los formularios son componentes React que se comunican a través de llamadas fetch(). Los endpoints de API no se descubren parseando HTML, porque el HTML es una cáscara casi vacía que carga un bundle de JavaScript. Un rastreador DAST que llega a una aplicación React vibe-coded típica ve <div id="root"></div> y quizás algunas etiquetas <script>. Se pierde todo lo demás.

Las herramientas DAST modernas han mejorado en la renderización de JavaScript — ZAP tiene un AJAX Spider, Burp tiene un navegador integrado. Pero siguen teniendo problemas con flujos de autenticación (especialmente OAuth), workflows de múltiples pasos y estado de la aplicación. Un formulario de login que usa useState para el seguimiento de inputs y useEffect para almacenar el token no se comporta como un formulario HTML tradicional, y los rastreadores DAST a menudo no pueden completar el flujo de auth para alcanzar la superficie protegida que hay detrás.

La Brecha de Lógica de Negocio

Incluso cuando DAST llega a los endpoints, se topa con la misma pared que SAST: la vulnerabilidad está en lo que el código no hace. DAST envía un payload de inyección SQL a /api/notes y comprueba si la respuesta parece salida de base de datos. Es una prueba legítima. Pero no comprueba si /api/notes/42 devuelve datos de un usuario diferente. No comprueba si el endpoint /api/admin/users es accesible con un token de usuario normal. No comprueba si el endpoint de login permite 10.000 intentos por minuto.

Estas son vulnerabilidades de lógica de negocio — requieren entender el comportamiento previsto de la aplicación, no solo su superficie de entrada/salida. DAST trata la aplicación como una caja negra. Para aplicaciones vibe-coded donde las vulnerabilidades más peligrosas están en el modelo de autorización, ese enfoque de caja negra se pierde lo que importa.

Dónde el DAST Sigue Ayudando

DAST detecta problemas de configuración que SAST no puede: cabeceras de seguridad ausentes, políticas CORS permisivas, información del servidor expuesta, configuraciones erróneas de SSL/TLS. Estos son problemas a nivel de despliegue, no a nivel de código, y las aplicaciones vibe-coded tienden a salir con configuraciones por defecto terribles porque la IA optimiza para que «funcione en local». Ejecutar ZAP o Nuclei contra tu aplicación desplegada detecta las carencias de la capa de infraestructura.

Nuclei merece una mención específica. Su biblioteca de templates mantenida por la comunidad supera ya los 11.000 templates, y ProjectDiscovery ha introducido generación de templates con IA — describe una comprobación en lenguaje natural, obtén un template YAML. Un pull request reciente añadió templates DAST de Seguridad IA específicamente dirigidos a patrones de sistemas IA. No resuelve el problema arquitectónico fundamental, pero es lo más cerca que ha llegado DAST de ser consciente del vibe coding.


La Brecha del SCA: Cuando las Dependencias No Existen

Las herramientas de Software Composition Analysis (SCA) — Snyk, npm audit, Dependabot, Socket.dev — comprueban las dependencias de tu proyecto contra bases de datos de vulnerabilidades. Si usas lodash@4.17.20 y hay un CVE para esa versión, SCA lo marca. Esta ha sido una de las prácticas automatizadas de seguridad más eficaces de la última década.

El código generado por IA rompe el SCA porque las dependencias son inventadas.

Slopsquatting

El término, acuñado por el investigador de seguridad Seth Larson, describe lo que ocurre cuando las herramientas de codificación IA recomiendan paquetes que no existen en ningún registro. Un estudio de marzo de 2025 que analizó 576.000 muestras de código generado por IA encontró que aproximadamente el 20% recomendaba paquetes que no son reales. Peor aún, el 43% de esos nombres de paquetes alucinados son consistentes entre diferentes ejecuciones de la IA — lo que significa que un atacante puede predecir qué nombres falsos sugerirá la IA, registrarlos y rellenarlos con código malicioso.

Eso es exactamente lo que pasó. En enero de 2026, un paquete npm alucinado llamado react-codeshift se propagó por 237 repositorios a través de código generado por IA. Nadie plantó deliberadamente el nombre del paquete en los datos de entrenamiento de la IA. La IA lo alucinó, múltiples desarrolladores lo instalaron cuando su IA lo sugirió, y finalmente alguien lo registró con código malicioso. El ataque a la cadena de suministro fue automatizado por la propia IA.

Las herramientas SCA no pueden marcar un paquete que no tiene un CVE porque es nuevo y no aparece en ninguna base de datos de vulnerabilidades. npm audit habría reportado cero problemas para react-codeshift — el paquete existía, no tenía CVEs conocidos, y su package.json parecía normal. El comportamiento malicioso estaba en el código, no en los metadatos.

Qué Detecta Cada Herramienta SCA

El panorama SCA se ha dividido en dos campos. Las herramientas tradicionales basadas en CVE (npm audit, Dependabot, escaneo básico de Snyk) comprueban paquetes contra bases de datos de vulnerabilidades conocidas. Si la vulnerabilidad tiene un CVE, la detectan. Si no, no. Para paquetes establecidos con investigación de seguridad activa, esto funciona. Para paquetes alucinados, paquetes recién registrados y paquetes con comportamiento malicioso ofuscado, están ciegos.

Socket.dev representa el enfoque más nuevo — analiza el comportamiento de los paquetes en vez de solo comprobar bases de datos de CVE. Detecta scripts de instalación que exfiltran variables de entorno, llamadas de red a dominios inesperados, código ofuscado que se decodifica en tiempo de ejecución y cambios repentinos en el comportamiento de los mantenedores. Este análisis de comportamiento detecta ataques a la cadena de suministro que las bases de datos de CVE aún no han catalogado.

Snyk DeepCode AI combina análisis simbólico con IA para escanear fragmentos de código a medida que se generan, detectando patrones vulnerables dentro del IDE antes de que lleguen al repositorio. Esto está más cerca de donde el SCA necesita ir para aplicaciones vibe-coded — señalar problemas en el momento de la generación en vez de después de que el paquete se instale y el código se haya hecho commit.

Para los problemas de dependencias que cubrí en la Parte 4, ninguna herramienta SCA por sí sola cubre toda la superficie de riesgo. La respuesta práctica es la superposición: npm audit para CVEs conocidos, Socket.dev para anomalías de comportamiento, y verificación manual de que los paquetes que tu IA sugirió realmente existen y son lo que dicen ser.


Lo Que Realmente Funciona: La Nueva Ola

La brecha entre lo que detectan las herramientas tradicionales y lo que necesitan las aplicaciones vibe-coded ha generado una nueva generación de herramientas de seguridad. Algunas son nativas de IA — usan LLMs para razonar sobre el código en vez de buscar coincidencias de patrones. Otras adoptan enfoques híbridos, combinando análisis tradicional con razonamiento potenciado por IA. Algunas están diseñadas específicamente para aplicaciones vibe-coded.

SAST Aumentado con LLM

La mejora a corto plazo más prometedora es usar LLMs para post-procesar la salida de SAST tradicional. El mismo estudio de enero de 2026 que expuso las tasas de falsos positivos del SAST también probó superponer agentes LLM sobre la salida. La mejor configuración redujo la tasa inicial de falsos positivos del 98,3% al 6,3%. El LLM lee el código señalado en contexto, entiende qué hace, y determina si la alerta es legítima o ruido.

Esto no resuelve el problema del punto ciego — el LLM sigue trabajando a partir de los hallazgos iniciales del SAST, así que el código ausente sigue siendo invisible. Pero hace que la salida del SAST sea realmente utilizable. En vez de 750 alertas donde 700 son falsos positivos, obtienes 50 alertas donde 47 son reales. Esa es la diferencia entre un informe que nadie lee y un informe que impulsa correcciones.

Análisis Neuro-Simbólico (IRIS)

IRIS, publicado en ICLR 2025, adopta un enfoque diferente. En vez de filtrar la salida del SAST, combina el razonamiento de LLM con el análisis estático de CodeQL en un framework neuro-simbólico. El LLM identifica patrones potenciales de vulnerabilidad a través de la comprensión del código, luego CodeQL los valida con análisis formal. Usando GPT-4, IRIS detectó 55 vulnerabilidades en 30 proyectos Java — un 103,7% más que CodeQL solo. Encontró 4 vulnerabilidades previamente desconocidas. Incluso un modelo más pequeño (DeepSeekCoder 7B) detectó 52 vulnerabilidades, lo que demuestra que este enfoque no requiere modelos de última generación.

La tasa de falsos descubrimientos sigue siendo alta con un 84,82%, pero es un 5,21% menor que CodeQL por sí solo. Más importante aún, IRIS detecta categorías de vulnerabilidades que la simple coincidencia de patrones no capta — puede razonar sobre si una verificación de autorización es semánticamente correcta, no solo sobre si existe alguna.

Escáneres Nativos de IA

Dos escáneres de seguridad nativos de IA importantes se lanzaron a principios de 2026. Claude Code Security de Anthropic, publicado en febrero de 2026, utiliza razonamiento LLM para analizar código en busca de vulnerabilidades en vez de buscar coincidencias de patrones. Está disponible para clientes Enterprise y Team, y es gratuito para mantenedores de código abierto. En su periodo inicial, encontró más de 500 vulnerabilidades de alta gravedad en proyectos de código abierto. Codex Security de OpenAI, lanzado en marzo de 2026, escaneó más de 1,2 millones de commits durante su beta, revelando 792 hallazgos críticos y 10.561 de alta gravedad.

Ninguna de las dos herramientas ha sido auditada independientemente, así que hay que tomar las cifras con cautela. Pero el enfoque es fundamentalmente diferente del SAST tradicional — en vez de buscar coincidencias de patrones, estas herramientas leen el código como lo haría un revisor de seguridad, razonando sobre el flujo de datos, los límites de confianza y si el modelo de seguridad tiene sentido a nivel arquitectónico.

Puertas de Seguridad Pre-Publicación

VibeGuard, publicado en abril de 2026, apunta a los puntos ciegos específicos del código generado por IA con un framework de puerta de seguridad pre-publicación. Comprueba cinco categorías: higiene de artefactos (source maps, archivos de depuración que llegan a producción), deriva de configuración de empaquetado, secretos hardcodeados, riesgos de cadena de suministro y exposición de source maps. La motivación surgió de un incidente real — en marzo de 2026, el propio CLI de Claude Code de Anthropic envió un source map de 59,8 MB que exponía aproximadamente 512.000 líneas de código TypeScript. En experimentos controlados con 8 proyectos sintéticos, VibeGuard logró un 100% de recall y un 89,47% de precisión (F1 = 94,44%).

Es una herramienta más específica que un escáner SAST completo, pero apunta exactamente a lo que las aplicaciones vibe-coded hacen mal. Las herramientas de codificación IA son muy buenas generando código que funciona. Son terribles generando artefactos de despliegue limpios y reforzados. VibeGuard se sitúa en esa brecha.

Plataformas de Seguridad Agénticas

DryRun Security se define como seguridad de código «nativa de IA, agéntica». En vez de buscar coincidencias de patrones en archivos individuales, inspecciona el flujo de datos entre archivos y servicios — entendiendo cómo se mueven los datos por la aplicación a nivel arquitectónico. Su Informe de Precisión SAST de 2025 mostró un 88% de detección de vulnerabilidades sembradas desde el primer uso, superando a cuatro analizadores estáticos tradicionales líderes, con particular fortaleza en lógica compleja y fallos de autorización. En febrero de 2026, lanzaron un DeepScan Agent que realiza revisiones de seguridad de repositorios completos.

Escape recaudó 18 millones de dólares en marzo de 2026 específicamente para reemplazar los escáneres heredados con pruebas de seguridad dirigidas por agentes IA. Vale la pena estudiar la metodología de su equipo de investigación: escanearon 5.600 aplicaciones vibe-coded accesibles públicamente y encontraron más de 2.000 vulnerabilidades de alto impacto. El desglose es revelador — más de 400 secretos expuestos y 175 casos de exposición de datos personales, incluyendo historiales médicos y números de cuentas bancarias. APIs sin autenticación, falta de limitación de peticiones y BOLA/IDOR dominaron los hallazgos. Estas son exactamente las clases de vulnerabilidad que los escáneres tradicionales no detectan.


Lo Que los Escáneres No Detectan: Los Puntos Ciegos del Vibe Coding

A lo largo de la investigación, seis patrones de vulnerabilidad en código generado por IA evaden consistentemente las herramientas de escaneo tradicionales. Conocerlos significa saber qué buscar manualmente, incluso cuando el escáner te da un informe limpio.

1. Controles de Seguridad Solo en el Frontend

La IA genera un auth guard de React que comprueba si hay un JWT en localStorage antes de renderizar las rutas protegidas. El guard funciona — los usuarios no autenticados ven la página de login. Pero la API detrás de esas rutas acepta cualquier petición, con o sin token. SAST escaneando el backend ve endpoints de API que reciben peticiones y devuelven datos. No hace referencia cruzada con el frontend para comprobar si existe cumplimiento del lado del servidor. DAST puede que ni siquiera llegue a los endpoints si no puede completar el flujo de auth del frontend.

2. APIs Sin Autenticación

El escaneo de Escape de 5.600 aplicaciones vibe-coded encontró aplicaciones con 7–12 endpoints de API públicos realizando operaciones destructivas (DELETE, PUT) sin ninguna autenticación. La especificación OpenAPI — cuando existía — no tenía esquemas de seguridad definidos. SAST no marca un endpoint por no tener middleware de auth, porque «sin middleware» no es un patrón que pueda detectar. El código es perfectamente válido; simplemente le falta un requisito de seguridad.

3. Falta de Limitación de Peticiones

Como mostré en la Parte 5, un endpoint de login sin limitación de peticiones permite a un atacante probar las 1.000 contraseñas más comunes en diez segundos. Ningún escáner marca esto porque la limitación de peticiones es una adición de middleware, no un patrón de código. El endpoint de login en sí es correcto — valida credenciales y devuelve un token. La ausencia de express-rate-limit o su equivalente es una decisión de despliegue, no un error de código.

4. BOLA/IDOR Sin IDs Secuenciales

La brecha BOLA de Lovable de la Parte 5 es el ejemplo canónico. La API comprobaba la autenticación (token Firebase válido) pero no la autorización (¿el usuario de este token es propietario de este proyecto?). SAST ve la llamada a firebase.auth() y considera el endpoint protegido. La verificación de propiedad que debería seguir es lógica de negocio que el escáner no puede inferir. DAST podría teóricamente detectar IDOR probando con dos sesiones de usuario diferentes, pero la mayoría de las configuraciones DAST no preparan escenarios de prueba multiusuario.

5. Configuraciones Inseguras por Defecto

El código generado por IA usa Supabase con RLS deshabilitado, Firebase con reglas de seguridad configuradas como allow read, write: if true, Express sin configuración CORS (permitiendo todo por defecto), y bibliotecas JWT con el parámetro algorithms sin establecer (permitiendo el ataque none). Ninguna de estas son errores. Son todas configuraciones válidas que resultan ser inseguras. SAST necesitaría reglas específicas de configuración para marcarlas — y la mayoría de herramientas no incluyen reglas para «tabla Supabase sin política RLS.»

6. Fallos de Higiene de Artefactos

Source maps enviados a producción, archivos .env incorporados en imágenes Docker, node_modules incluidos en artefactos desplegables, logging de depuración activo en producción. Estas no son vulnerabilidades de código — son fallos de empaquetado y despliegue que exponen código fuente, secretos y arquitectura interna. El SAST y DAST tradicionales no escanean artefactos de compilación en absoluto.


Construyendo un Pipeline de Escaneo que Funcione

Ninguna herramienta por sí sola cubre toda la superficie de riesgo de una aplicación vibe-coded. La respuesta práctica es superponer herramientas donde cada una cubra una brecha diferente, ejecutarlas en el orden correcto, y saber qué sigue requiriendo revisión humana.

Capa 1: Pre-Commit (Detectar Secretos Antes de que Se Envíen)

Antes de que el código llegue al repositorio, ejecuta detección de secretos. Esta es la comprobación automatizada con mayor retorno de inversión porque los secretos en control de versiones son permanentes — incluso si borras el archivo, el secreto sigue en el historial de Git.

# Instalar y ejecutar Gitleaks como hook de pre-commit
gitleaks detect --source . --verbose

# O TruffleHog para análisis más profundo incluyendo historial de Git
trufflehog filesystem . --only-verified

Configúralo como hook de pre-commit de Git. Cada commit se escanea. Si se detecta un secreto, el commit se bloquea. Esta es la única capa donde la automatización es genuinamente fiable — los patrones están bien definidos y los falsos positivos son manejables.

Capa 2: Pipeline CI (SAST + SCA en Cada Push)

Ejecuta SAST y SCA en tu pipeline CI. El objetivo aquí no es la perfección — es detectar el 30% de problemas que la coincidencia de patrones maneja bien.

# Semgrep con auto-config (extrae conjuntos de reglas relevantes para tu stack)
semgrep --config=auto --error --json ./src > semgrep-results.json

# npm audit para CVEs conocidos de dependencias
npm audit --audit-level=high

# Socket.dev CLI para análisis de comportamiento de dependencias
socket scan create --repo . --branch main

El paso crítico es filtrar la salida del SAST. Si tu equipo se ahoga en falsos positivos, empieza solo con las reglas de alta confianza. El conjunto de reglas p/security-audit de Semgrep es más específico que --config=auto. Para SCA, diferencia entre dependencias de desarrollo y producción — un CVE en una dependencia de desarrollo tiene menor prioridad que uno en tu middleware de autenticación.

Capa 3: Post-Despliegue (DAST Contra la Aplicación en Ejecución)

Después del despliegue, ejecuta DAST contra tu aplicación real. Esto detecta problemas de configuración que no existen en el código fuente.

# Nuclei con templates de la comunidad
nuclei -u https://yourapp.com -t nuclei-templates/ -severity critical,high

# Escaneo básico con ZAP
docker run -t zaproxy/zap-stable zap-baseline.py -t https://yourapp.com -r report.html

Para SPAs, usa el AJAX Spider de ZAP o el rastreo basado en navegador de Burp en lugar del rastreador HTTP por defecto. Proporciona al escáner tu especificación OpenAPI si la tienes — descubrirá endpoints que el rastreador no encuentra.

Capa 4: Revisión Aumentada con IA (La Nueva Capa)

Esta es la capa emergente que no existía hace un año. Si tienes acceso a Claude Code Security, Codex Security o DryRun, ejecútalos como complemento al SAST tradicional. Cubren la brecha de razonamiento arquitectónico — detectando controles ausentes, evaluando si la lógica de autorización es semánticamente correcta y entendiendo el flujo de datos entre los límites de los servicios.

Si no tienes acceso a estas herramientas comerciales, puedes aproximar el enfoque ejecutando un LLM contra tu salida de SAST para filtrar falsos positivos (la técnica del estudio de enero de 2026 redujo los falsos positivos del 98,3% al 6,3%), o pidiendo a un LLM que revise archivos clave de seguridad con preguntas dirigidas: «¿Este endpoint verifica que el usuario autenticado es propietario del recurso solicitado?» «¿Hay un middleware de limitación de peticiones aplicado a esta ruta?»

Capa 5: Revisión Manual (La Capa Insustituible)

Llevo más de dos décadas en seguridad de aplicaciones. Cada encargo que hago en VULNEX empieza con escaneo automatizado y termina con revisión manual, porque las herramientas automatizadas siempre se dejan algo. Para aplicaciones vibe-coded, la revisión manual es aún más importante porque las clases de vulnerabilidad son arquitectónicas.

El checklist de revisión manual es más corto de lo que la gente piensa. Para cada endpoint de API: ¿comprueba autenticación? ¿Comprueba autorización — no solo «está logueado este usuario» sino «tiene este usuario permiso para acceder a este recurso específico»? ¿El cliente envía algún dato que controla el comportamiento del servidor (IDs de usuario, flags de rol, overrides de precio) sin validación del lado del servidor? ¿Hay funciones de administración accesibles para usuarios normales?

Una revisión manual enfocada de la capa de auth y autorización lleva horas, no días, y detecta los problemas que todas las herramientas automatizadas se pierden.

Lo Que Cuesta

Para un fundador en solitario o un equipo pequeño, esto es aproximadamente lo que implica. Las capas 1–3 usan herramientas gratuitas y de código abierto — Gitleaks, Semgrep, npm audit, la capa gratuita de Socket.dev, Nuclei. Configurar el pipeline CI completo lleva una tarde si manejas GitHub Actions o similar, un fin de semana si partes de cero. La capa 4 varía: Claude Code Security es gratuito para proyectos de código abierto, DryRun y Escape tienen precios comerciales que normalmente empiezan en unos pocos cientos al mes. La capa 5 es donde se encarece si no tienes experiencia en seguridad en el equipo. Una revisión enfocada de auth y autorización por parte de una consultora de seguridad suele costar entre 3.000 € y 10.000 € dependiendo del tamaño y complejidad de la aplicación. Es dinero real para una startup en fase inicial — pero saltársela es precisamente lo que provocó las brechas de la Parte 3.


El Checklist de Escaneo

Ejecuta esto contra tu aplicación vibe-coded. Cada elemento aborda una brecha específica del escaneo tradicional.

Secretos (Pre-Commit):

  1. Ejecuta gitleaks detect --source . --verbose y trufflehog filesystem . --only-verified — cero hallazgos antes de cualquier commit
  2. Busca claves filtradas en los bundles del frontend: grep -r "sk-\|API_KEY\|SECRET\|Bearer\|supabase\|firebase" dist/ build/
  3. Verifica que los archivos .env nunca se han subido al repositorio: git log --all --diff-filter=A -- '*.env' '.env*'

SAST (Pipeline CI):

  1. Ejecuta semgrep --config=p/security-audit --error ./src — usa el conjunto de reglas enfocado, no --config=auto, para mantener el ruido controlado
  2. Revisa manualmente cada hallazgo high o critical — busca innerHTML, eval(), dangerouslySetInnerHTML, SQL sin sanitizar

SCA (Pipeline CI):

  1. Ejecuta npm audit --audit-level=high — soluciona todos los CVEs altos y críticos
  2. Verifica que las dependencias son reales: comprueba que cada paquete en package.json tiene una página legítima en npmjs.com con descargas y un mantenedor real
  3. Ejecuta Socket.dev o Snyk para análisis de comportamiento — detecta ataques a la cadena de suministro que las bases de datos de CVE no captan

DAST (Post-Despliegue):

  1. Ejecuta nuclei -u https://yourapp.com -severity critical,high contra tu aplicación desplegada
  2. Comprueba cabeceras de seguridad y CORS: curl -s -D- https://yourapp.com | grep -i "x-frame\|x-content-type\|strict-transport\|content-security-policy" y prueba con Origin: https://evil.com

Manual (Las Brechas):

  1. Prueba cada endpoint de API sin el frontend — ¿requiere autenticación?
  2. Prueba acceso entre usuarios — ¿puede el Usuario A acceder a los recursos del Usuario B cambiando IDs?
  3. Prueba endpoints de administración con el token de un usuario normal, envía 100 peticiones rápidas al login para verificar la limitación de peticiones (espera un 429), y confirma que las reglas de Supabase RLS / Firebase están habilitadas y limitadas al usuario autenticado

Este pipeline no detectará todo. Pero cubre las capas donde las herramientas automatizadas son fiables, señala las áreas donde están ciegas, y dirige el esfuerzo manual donde más importa. Si no estás ejecutando ningún escaneo hoy — que, por lo que veo en las evaluaciones, es el caso de la mayoría de aplicaciones vibe-coded — empezar con los puntos 1, 2, 11 y 12 te da el mayor valor de seguridad con el menor esfuerzo.


Lo Que Deberías Sacar de Esto

Los escáneres de seguridad tradicionales no están rotos. Están resolviendo un problema diferente. Fueron construidos para un mundo donde los desarrolladores entienden su código y cometen errores localizados — una consulta sin parametrizar, una función criptográfica mal usada, una dependencia desactualizada. El código generado por IA introduce una nueva clase de vulnerabilidad: código arquitectónicamente correcto con controles de seguridad ausentes. El login funciona, el JWT valida, la base de datos responde — y el hecho de que cualquier usuario autenticado pueda leer los datos de cualquier otro usuario no es algo que un buscador de patrones pueda detectar.

El panorama del escaneo está evolucionando rápido. Las herramientas nativas de IA que razonan sobre el código en vez de buscar coincidencias de patrones están empezando a cerrar la brecha. El enfoque IRIS (análisis neuro-simbólico), el filtrado de falsos positivos basado en LLM y las puertas pre-publicación como VibeGuard son pasos en la dirección correcta. Pero a mediados de 2026, ninguna herramienta automatizada detecta de forma fiable la lógica de autorización rota, la falta de limitación de peticiones o los controles de seguridad solo en el cliente. Eso sigue requiriendo revisión humana.

Mi flujo de trabajo en VULNEX: Gitleaks y TruffleHog para secretos, Semgrep para problemas basados en patrones, npm audit más Socket.dev para dependencias, Nuclei para la superficie desplegada, y después pruebas manuales de cada frontera de autenticación y autorización. Las capas automatizadas llevan minutos, la revisión manual lleva horas — y por mi experiencia, es en la revisión manual donde aparecen las vulnerabilidades críticas.

Si eres un fundador en solitario o un ingeniero sin formación en seguridad — que describe a la mayoría de la gente que construye con herramientas de codificación IA — la capa 5 es la difícil. No puedes revisar lo que no sabes buscar. Mi consejo práctico: ejecuta las capas 1–3 como mínimo, son gratuitas y detectan problemas reales. Si tu aplicación maneja datos de usuario, pagos o cualquier cosa sensible, presupuesta una revisión de seguridad profesional antes de lanzar. No tiene que ser un pentest completo — una revisión enfocada de tus fronteras de autenticación y autorización, acotada a 2–3 días, detecta los problemas arquitectónicos que la automatización no alcanza. La Parte 8 de esta serie profundizará en esto con un checklist completo para fundadores.

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


Lecturas Adicionales


Referencias

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

Cuando los Agentes Arreglan a los Agentes: Cómo Hermes Reparó OpenClaw Tras una Mala Actualización

Tiempo de lectura: 7 minutos

TL;DR

Le pedí a OpenClaw que se actualizara solo. Lo hizo. Después, el gateway se negó a arrancar porque un campo de configuración había cambiado de forma silenciosa entre versiones (channels.discord.streaming pasó de ser una cadena a ser un objeto). openclaw doctor --fix detectó el problema, pero no fue capaz de arreglarlo. El AI Overview de Google sugirió con total seguridad lo contrario de la solución correcta. Hermes-Agent, con acceso a shell y al sistema de ficheros, leyó la configuración rota, hizo el único cambio necesario, guardó una copia de seguridad del original, reinició el servicio y verificó que todo iba bien, todo a partir de un prompt de un único párrafo. Trece minutos desde el primer aviso en rojo hasta el verde. Esto es lo que realmente significa «agentic ops».


Llevo bastante tiempo ejecutando OpenClaw en una Raspberry Pi 5. Es ese tipo de montaje que afinas los fines de semana y olvidas durante la semana, hasta que llega una actualización y algo se rompe sin avisar.

Esta mañana fue una de esas mañanas. Lo que quiero dejar por escrito no es solo el bug, sino la forma del arreglo. La herramienta de reparación de OpenClaw no fue lo que devolvió el gateway a la vida. Tampoco lo fue el AI Overview que aparece en la parte superior de cada resultado de Google. Lo que funcionó fue un agente de propósito general con acceso a shell y a ficheros, y la costumbre de leer una configuración antes de tener una opinión sobre ella.

Esa distinción parece pequeña. No lo es.


Paso 1: Le Pedí a AgentX que se Actualizara

Toda la historia empieza con una instrucción perfectamente razonable. Abrí la interfaz de chat de OpenClaw, saludé a AgentX (mi agente principal de OpenClaw) y le pedí que se actualizara.

1

update yourself please. El tipo de frase que le dices a un agente autónomo dando por hecho que sabrá apañárselas.

Y la parte de la actualización la gestionó. Lo que no gestionó fue la parte de validación posterior a la actualización, porque eso todavía no es algo que OpenClaw haga por sí mismo. La nueva versión introducía un cambio de esquema en uno de los campos de configuración. La actualización escribió los nuevos binarios. El fichero de configuración mantuvo su forma antigua. El siguiente arranque del gateway iba a fallar.

Yo todavía no sabía nada de esto.


Paso 2: Media Hora Después, el Gateway se Niega a Arrancar

Misma sesión, misma mañana. La actualización terminó en silencio en segundo plano. Cuando fui a levantar el gateway — openclaw gateway, esperando un arranque normal —, esto fue lo que obtuve:

2

Invalid config at /home/vulnex/.openclaw/openclaw.json:
channels.discord.streaming: invalid config: must be object
Run "openclaw doctor --fix" to repair, then retry.

Útil, en teoría. El arranque deja escrito un stability bundle (bien — para eso están los stability bundles) y el servicio se cae justo después.


Paso 3: El Status Confirma el Estado Roto

Lancé openclaw gateway status para ver el cuadro completo.

3

Una línea roja de lado a lado. state failed, sub failed, last exit 1, reason 1. La URL del dashboard ahí, burlándose de mí, la sonda de loopback sin poder conectar, y el gateway sin intención de volver por su cuenta.

En un mundo normal, este es el momento en el que sigues la solución sugerida por OpenClaw y terminas en cinco minutos. Eso fue lo primero que probé.


Paso 4: doctor --fix — La Auto-Reparación Que No Fue (Parte 1)

openclaw doctor --fix se supone que es el botón de «¿has probado a apagarlo y volverlo a encender?». Así que lo ejecuté.

4

El doctor se dedicó a sermonearme sobre NODE_COMPILE_CACHE y OPENCLAW_NO_RESPAWN en hosts de poca potencia. Consejos útiles. No el problema.


Paso 5: doctor --fix — La Auto-Reparación Que No Fue (Parte 2)

El doctor recorrió las secciones de config y gateway y acabó donde yo había empezado:

5

Restarted systemd service: openclaw-gateway.service
Error: Config validation failed: channels.discord.streaming: invalid config: must be object

El doctor reinició el servicio, pero nunca llegó a tocar la clave problemática. Lo cual tiene sentido, visto en frío. El validador dice «must be object», pero el doctor no tiene ninguna opinión sobre qué forma concreta debería tener ese objeto. No está en el negocio de adivinar esquemas nuevos. Es una postura razonable. Tampoco es muy útil a las 10:27 de la mañana.

Una cosa que OpenClaw debería cambiar: doctor --fix no debería imprimir «Restarted systemd service» una línea por encima de «Error: Config validation failed» y salir tan contento. A mí me confundió, y va a confundir a más gente. Lo abriré como bug.


Paso 6: La Respuesta Equivocada del AI Overview

Llegado este punto hice lo que haría la mayoría de la gente: pegué el mensaje de error exacto en Google a ver si alguien más se había topado con esto entre versiones.

6

Me decía que el validador quiere una cadena como "partial" y que mi configuración tenía un objeto, cuando en realidad el nuevo OpenClaw espera un objeto y mi configuración antigua tenía una cadena. Incluso me ofrecía un bloque JSON limpio, con resaltado de sintaxis, listo para copiar y pegar directamente en el fichero para romperlo más, etiquetado con un pin de citación de GitHub que daba toda la confianza del mundo.

Si hubiera ido con prisa, lo habría pegado. Esa es la parte que las demos de «IA para ops» suelen pasar por alto sin hacer ruido. La respuesta era fluida, estaba bien formateada, hasta llevaba cita, y apuntaba justo en sentido contrario a la dirección real de la migración del esquema.

Es el mismo modelo de amenaza que cubrí en Professional Vibe Coding vs. Vibe Coding, trasladado de un contexto de código a uno de operaciones. Si tu IA no puede leer el validador ni la configuración, te va a dar una respuesta segura sintetizada a partir del texto del error, y a veces esa respuesta es justo la contraria a la correcta.


Paso 7: Entra Hermes

Tengo Hermes-Agent enganchado a esta máquina precisamente para este tipo de líos. Trae herramientas de fichero, ejecución de shell, y la paciencia de leer las cosas en lugar de adivinarlas.

7

El stack de skills aquí importa: file:patch, read_file, search_files, write_file, code_execution, además del skill openclaw-agent-integrations que mantengo en local justo para este tipo de fontanería. Nada glamuroso, solo los movimientos básicos que hacen falta para arreglar un servicio mal configurado.

Le di un brief de un párrafo:

«I told openclaw to update itself and did, however the latest version breaks due a openclaw config json file error. The folder path is /home/vulnex/.openclaw. Make a copy of the config json file and fix the issue. You can use openclaw command to see the issue.»

Eso es todo. Sin esquema, sin pistas, sin ejemplo del nuevo formato.


Paso 8: Hermes se Orienta

Hermes hizo lo que yo habría hecho si hubiera dispuesto de otra hora.

8

  • Inspeccionó el entorno
  • Encontró la manera de invocar openclaw (el binario está en mi PATH, pero la shell no interactiva de Hermes no lo heredó, así que tiró de npx --yes openclaw y lo dejó claro en su resumen)
  • Leyó la configuración rota
  • Recuperó el stability bundle que el gateway había dejado caer al desplomarse

Nada de una única llamada dramática al LLM. Una pila de pasos pequeños y verificables: find, command -v, head, npm prefix -g, un heredoc de python3 que recorre $PATH buscando cualquier cosa que contenga claw. Aburrido a propósito.


Paso 9: Hermes Diagnostica

Una vez que tenía la configuración y el stability bundle en contexto, Hermes los comparó y averiguó qué había cambiado exactamente entre versiones.

9

Nada de adivinar a partir del texto del error. Lectura del original.


Paso 10: El Arreglo Aterriza

Hermes no tuvo el problema que tuvo el AI Overview, porque Hermes estaba leyendo los ficheros reales en lugar de inferir desde la prosa del error.

10

El diff es la historia completa:

// antes — forma antigua, válida en 2026.5.18 y anteriores
"channels": {
  "discord": {
    "streaming": "off"
  }
}

// después — forma nueva, requerida en 2026.5.19
"channels": {
  "discord": {
    "streaming": { "mode": "off" }
  }
}

OpenClaw 2026.5.19 promovió channels.discord.streaming de cadena a objeto etiquetado. El doctor vio que algo estaba mal, pero no tenía opinión sobre la nueva forma. El AI Overview de Google sí tenía opinión, y era la contraria a la correcta. Hermes:

  1. Leyó la configuración rota y el stability bundle startup_failed.json del gateway
  2. Hizo el cambio mínimo posible
  3. Escribió ~/.openclaw/openclaw.json.agenth-bak-20260521-103255 junto al original
  4. Reinició el servicio del gateway
  5. Verificó que el JSON parsea bien y que el error anterior había desaparecido

También fue honesto con sus propias matizaciones:

  • Usó npx --yes openclaw porque su shell no interactiva no heredó mi PATH interactivo — aunque el binario openclaw está, de hecho, instalado globalmente en este host. Una pequeña lectura errónea del entorno, pero transparente.
  • openclaw doctor seguía reportando avisos no relacionados, pero el problema de arranque que rompía la configuración estaba resuelto.

Esa auto-declaración importa, incluso cuando (como en el caso del PATH) el agente es algo demasiado pesimista sobre su entorno. Es mucho más fácil confiar en un agente que pone sus supuestos encima de la mesa que en uno que los esconde.


Paso 11: Verificación Desde el Shell

Confía, pero verifica. Vuelta al comando original que arrancó toda esta historia.

11

Runtime: running (pid 10178, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok

Mismo comando, resultado opuesto. Once minutos antes esto había sido un muro rojo.


Paso 12: Pedirle a AgentX que lo Confirme

Después volví a la interfaz de chat de OpenClaw, el mismo sitio donde había empezado toda la historia, y se lo pregunté directamente a AgentX. Porque si no puedes fiarte de que el agente te cuente su propio estado tras una recuperación, tienes otros problemas.

12

«All good — gateway is running on 2026.5.19, active since 10:33. The doctor --fix restart attempt errored but the service came up fine on its own. We’re fully updated and online.»

Trece minutos desde el primer aviso en rojo hasta tenerlo en verde. La mayor parte de ese tiempo me lo pasé leyendo yo.

La sesión de chat hace de marco para toda la historia. Se abre con «update yourself please» y se cierra con «fully updated and online». Entremedias, un agente completamente distinto tuvo que entrar a hacer el trabajo real. Ese hueco es de lo que va este artículo.


Qué Nos Dice Realmente Este Episodio

La versión bonita de la historia es «agente que se rompe a sí mismo, agente que se arregla a sí mismo». Lo interesante está en el medio.

La herramienta de reparación del propio fabricante no arregló el producto del propio fabricante

openclaw doctor --fix es una buena idea ejecutada a medias. O entiende los caminos de migración de esquemas entre versiones recientes, o deja de fingir que ha hecho una reparación cuando la siguiente línea de su propio output dice que la configuración sigue sin validar. Ahora mismo hace lo peor posible: canta victoria y te deja roto. Eso es un bug de OpenClaw, no de la IA, y lo voy a reportar.

Los AI Overviews para usuario final se equivocan con seguridad en preguntas de esquema

Esto no es un caso aislado. El AI Overview no puede leer tu configuración, no puede leer el código del validador, no puede decirte hacia dónde ha migrado un esquema entre dos versiones, y formatea la respuesta equivocada con la misma seguridad que la correcta.

Para alguien que solo intenta levantar el gateway antes de una reunión, esa respuesta es peor que ninguna respuesta. Ninguna respuesta te manda a la documentación. Una respuesta equivocada con aire de seguridad te manda a pegar JSON roto en un fichero que estaba bien.

Tampoco es un problema específico de Google. Es el patrón general de producir una respuesta fluida a partir del síntoma en lugar de la fuente. Cualquier IA desplegada sin acceso de lectura al artefacto real se va a chocar con el mismo muro.

El agente que sí funcionó no era magia

Hermes no resolvió esto por ser más grande, más inteligente o estar entrenado con algo exótico. Lo resolvió porque podía leer el fichero, ejecutar un comando, escribir el fichero, y guardar una copia de seguridad. Esos cuatro movimientos son el suelo de lo que yo llamaría agentic ops, y la mayoría de la IA para usuario final sigue claramente por debajo de ese suelo.

La regla que me llevo de esta mañana es corta: si la IA en la que estás a punto de confiar para tocar una configuración no puede leer el fichero ni guardar una copia, no es una herramienta de ops. Es un buscador con mejor gramática.


Qué Voy a Cambiar en Mi Setup Después de Esto

Algunas cosas que voy a montar este fin de semana.

Quiero que ~/.openclaw/openclaw.json quede capturado en un repo git local antes de cada openclaw update. Los ficheros .agenth-bak de Hermes están bien para un incidente puntual, pero un historial real con control de versiones es mejor cuando llegue el próximo cambio de esquema.

También voy a dejar de tratar doctor --fix como una recuperación de un solo paso. Es un diagnóstico que de vez en cuando además escribe un arreglo. La auténtica verificación tiene que ser volver a lanzar openclaw gateway status y leer la salida.

Hermes se queda enganchado a esta máquina con scopes de fichero y ejecución pre-aprobados. La gracia del montaje es que cuando algo se rompe a las 10:25, no estoy también a las 10:26 cableando permisos de herramientas.

Y los nombres de los backups necesitan trabajo. openclaw.json.agenth-bak-20260521-103255 es razonable, pero quiero que esos ficheros caigan en ~/.openclaw/backups/ en lugar de quedarse al lado de la configuración viva.

Si estás ejecutando OpenClaw, la Guía Sencilla de Hardening de Seguridad para OpenClaw que escribí esta primavera sigue siendo la línea base correcta. Nada en el incidente de esta mañana cambia esas recomendaciones. Solo refuerza por qué una IA de solo lectura, que no puede tocar el artefacto, no debería estar en ningún punto cercano a tu bucle de recuperación.


Notas del Setup

Para quien quiera reproducir o comparar:

  • OpenClaw 2026.5.19 sobre un host Linux de clase Raspberry
  • Gateway en el puerto 18789, controlado desde la interfaz web de OpenClaw
  • Hermes-Agent v0.12.0 sobre el backend gpt-5.5 con 272K de contexto, configurado contra mi stack de skills estándar
  • El ~/.openclaw/openclaw.json original conservado como openclaw.json.agenth-bak-20260521-103255 para comparación forense

Una línea de JSON, y un recordatorio: la IA en la que confías durante un incidente tiene que poder leer el fichero.

Mantente paranoico. Lee la fuente. Guarda el backup.

Lecturas Recomendadas:

¿Preguntas o feedback? Contáctame a través de:

¿Necesitas ayuda para fortificar tu despliegue de agentes de IA? VULNEX ofrece:

  • Auditorías de seguridad de agentes IA (auditoría de skills, pruebas de prompt injection, revisión de configuración)
  • Engagements de red team (simulaciones de ataque potenciadas por IA)
  • Consultoría de automatización de seguridad y agentic ops
  • Desarrollo a medida de herramientas de seguridad

Contacto: info@vulnex.com

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