DEV Community: Juan Carlos Isaza

El mismo formato de texto no garantiza la misma firma

Juan Carlos Isaza — Sun, 04 Oct 2026 18:32:17 +0000

Teníamos la misma sesión escrita dos veces —una copia en cada aplicación— y una librería común para dejar de duplicarla. El token se ve igual en las tres: id|version|caducidad|firma, un HMAC-SHA256 sobre la carga.

La tentación era obvia: «mismo formato de tres campos, migrar es transparente, las cookies vivas siguen valiendo». Lo dábamos por hecho.

Antes de tocar nada computamos la firma de una misma carga con las dos implementaciones y la comparamos contra el vector fijo real de la librería —un token congelado, pegado como literal en las pruebas justamente para esto—. No coincidían.

La causa no estaba en el formato. La librería, al endurecerse, había empezado a anteponer la longitud del dominio de firma al mensaje HMAC (un arreglo contra una ambigüedad de prefijo). Con el dominio vacío de una sesión normal eso ya cambia el mensaje: una firma es HMAC(carga) y la otra HMAC([8 bytes cero]‖carga). Mismo texto, firma distinta.

Consecuencia: migrar a la librería común cierra la sesión de todos los usuarios en el despliegue. No es un bug —la librería es más estricta, no menos— pero es una interrupción real que se decide y se anuncia, no que se descubre en producción.

La lección de método: una prueba de ida y vuelta —emitir y verificar con el mismo binario— mide el códec contra sí mismo. Pasa en verde aunque cambies el separador, el orden de los campos o el motor de base64… y cerraría la sesión de todo el mundo sin un solo test en rojo. Lo único que discrimina es un vector fijo: un token real congelado, verificado por el binario de hoy. Si se pone rojo, lo guardado dejó de leerse —y eso se decide, no se regenera—.

La regla que nos llevamos: la compatibilidad de una firma no se lee del formato. Se mide contra un artefacto congelado, antes de afirmar «compatible con lo ya emitido».

SameSite=Lax no te protege del login-CSRF

Juan Carlos Isaza — Sun, 04 Oct 2026 18:26:58 +0000

Construimos un servidor de identidad —Bachué— que autentica con contraseña, segundo factor y sesión por cookie. Las cookies llevan SameSite=Lax, y dábamos por sentado lo que "todo el mundo sabe": que SameSite=Lax protege del CSRF.

No nos fiamos de nuestra propia revisión. El autor de un código es el peor situado para auditarlo: lo que pensó ya lo siente verificado. Así que le pedimos a tres modelos distintos que lo atacaran, cada uno por su cuenta, con un solo encargo: encuentra el defecto más grave; piensa como quien quiere entrar.

Una falsa alarma, y luego la de verdad

El primer modelo gritó "¡CSRF!" con la mecánica equivocada: creía que SameSite=Lax deja pasar un POST cross-site. No lo deja —Lax no envía la cookie en un POST de otro sitio—. Un segundo modelo lo refutó. Hasta ahí, ruido.

El tercero encontró el real, y es sutil: el login-CSRF, que SameSite no cubre.

Por qué Lax protege el logout pero no el login

SameSite=Lax protege los endpoints que necesitan la cookie de la víctima: cerrar sesión, cambiar ajustes. Un POST desde el sitio del atacante llega sin esa cookie, el servidor no ve sesión, y no pasa nada.

Pero /entrar y /registrarse son distintos: no necesitan la cookie de la víctima. El atacante pone sus propias credenciales en el formulario, y lo único que hace el servidor es fijar una cookie nueva en la respuesta. Y un Set-Cookie de primera parte se honra siempre, venga la petición de donde venga. Resultado: la víctima queda navegando autenticada como el atacante, sin saberlo —y todo lo que teclee después vive en la cuenta del atacante—. SameSite no tiene ningún efecto sobre esto.

Afirmar no es demostrar

"SameSite cubre el CSRF" era una afirmación, y como toda frontera de seguridad, parecía aguantar hasta que alguien la cruzó. La demostración —tres adversarios independientes— costó minutos y encontró lo que una sola mirada, incluida la nuestra, habría dado por bueno.

El arreglo es una línea de disciplina: todo POST que cambie estado —también los que aún no exigen sesión— comprueba que la petición es de primera parte (Sec-Fetch-Site) antes de procesarla. Como regla global, no como parche por endpoint que el próximo olvide.

La lección vale más que el bug: no basta con revisar tu propio código de seguridad. Ponle adversarios independientes a demostrar que la frontera aguanta. Si solo la afirmas, un día no aguanta —callada, en el punto donde nadie volvió a mirar—.

chimini: la tabla periódica jugable donde fusionas elementos y ves qué pasa

Juan Carlos Isaza — Sat, 03 Oct 2026 18:43:16 +0000

Una tabla periódica que se juega

chimini es un laboratorio de química y física que corre en el navegador, gratis y sin instalar nada. Eliges elementos de la tabla periódica, los combinas, y el sistema te dice qué forman —con datos científicos reales, no inventados—.

Puedes probarlo ahora mismo en chimini.xiliux.com.

Qué se puede hacer

Fusionar elementos: junta hasta cinco y descubre el compuesto —fórmula, nombre científico, tipo de enlace y masa molar—. Junta hidrógeno y oxígeno y aparece el agua; sodio y cloro, la sal.
Las dos alquimias: la química (los enlaces) y la nuclear (la de verdad, la que transmuta un elemento en otro). El juego calcula si fusionar o fisionar dos núcleos libera o consume energía, y te muestra la famosa curva del hierro que explica por qué brillan las estrellas.
Exponer a energía: aplica calor, electricidad, radiación o plasma a un elemento y observa cómo cambia de estado, se ioniza o se transmuta.
Explorar por valores: fija un rango de propiedades (por ejemplo, los más electronegativos) y el sistema te dice qué elementos lo cumplen.
Elemento mutante y elemento por descubrir: uno genera una quimera imposible con valores al azar y te enseña por qué es imposible; el otro extrapola cómo sería el elemento 119, aún no descubierto.

Datos reales, y honestos sobre sus límites

Los 118 elementos vienen de PubChem (NIH) y las energías nucleares de AME2020, ambos de dominio público. Donde la ciencia no ha medido un valor, chimini lo dice —no rellena huecos con ceros—. Y cuando estima en vez de medir, también lo declara. Esa honestidad es parte del método.

Por qué lo hicimos así

chimini es un solo programa que funciona sin conexión —pensado para que corra igual en un colegio de ciudad que en uno de vereda sin buena internet—. Está construido en Rust, es software libre, y es una muestra de cómo en Xiliux entendemos el software educativo: riguroso, accesible y que respeta a quien lo usa.

Juégalo: chimini.xiliux.com

¿Puede una IA descifrar tu cifrado? La amenaza real es otra

Juan Carlos Isaza — Sat, 03 Oct 2026 18:17:59 +0000

La frase "hackeo con IA" se ha vuelto un titular que vende miedo, y al venderlo mezcla tres amenazas que son completamente distintas. Separarlas es la diferencia entre elegir bien tu cifrado y comprar humo.

1. ¿Una IA rompe la matemática del cifrado? No.

No existe, hoy, un criptoanálisis por IA que quiebre primitivos bien diseñados: AES, XChaCha20-Poly1305, ML-KEM o Argon2id. Una red neuronal no "adivina" una clave de 256 bits ni acelera el álgebra que sostiene el cifrado. El espacio de claves es tan grande que ninguna cantidad de cómputo estadístico lo recorre. Quien afirma que la IA descifra AES está vendiendo miedo, no describiendo un ataque.

2. Lo que la IA sí potencia ataca la implementación y al humano

Los hackeos reales asistidos por IA no tocan las matemáticas; escalan tres cosas que siempre fueron el eslabón débil:

Bugs de implementación. La IA lee código a gran escala y encuentra el error humano: un nonce reutilizado, una comparación que filtra tiempo, un padding mal manejado, una primitiva bien elegida pero mal usada. Aquí no falla el cifrado, falla el programa que lo rodea.
Ingeniería social. El phishing generado por IA es más creíble y más barato. Roba la contraseña maestra, y ninguna criptografía protege contra una clave entregada voluntariamente.
Fuerza bruta guiada. La IA prioriza qué contraseñas probar. La defensa correcta ya existía: una derivación de clave memory-hard como Argon2id, calibrada a cientos de megabytes por intento, cuesta memoria, no solo cómputo — y la memoria no se paraleliza barato ni en una GPU ni en un modelo. La IA no cambia ese costo.

La lección es vieja y sigue siendo cierta: el cifrado casi nunca se rompe; se rodea. La IA hace el rodeo más rápido, no el muro más débil.

3. La amenaza real a la matemática no es la IA: es la computación cuántica

El único adversario que apunta al corazón algebraico del cifrado es la computación cuántica. El algoritmo de Shor rompe RSA y curva elíptica —la base de casi todo el cifrado asimétrico de hoy—. Y el ataque no es futuro: es "cosechar ahora, descifrar después". Un adversario captura hoy tu tráfico cifrado y lo guarda hasta que exista la máquina que lo abra. Todo lo que cifres hoy con criptografía clásica tiene fecha de caducidad silenciosa.

La respuesta no es un producto "anti-IA". Es criptografía post-cuántica híbrida: combinar el algoritmo clásico con uno resistente a cuántica (por ejemplo X25519 con ML-KEM), de modo que romper el mensaje exija romper los dos. El híbrido protege incluso si uno de los dos resulta tener una debilidad no descubierta.

Cómo elegir cifrado con esto en mente

Si un proveedor te vende su cifrado como "a prueba de IA", desconfía: está describiendo una amenaza que no existe e ignorando la que sí. Las preguntas que de verdad discriminan son otras:

¿Es post-cuántico híbrido? — contra el "cosechar ahora, descifrar después".
¿Está la implementación auditada? — porque el vector real es el bug de código, y la mejor defensa es buscarlo con las mismas herramientas que usará el atacante, antes que él.
¿La derivación de clave es memory-hard? — para que una contraseña débil no caiga a fuerza bruta a escala.

Esas tres son medibles y honestas. "Anti-IA" no es ninguna de las tres.

Lo que tememos de la IA son fallas nuestras. Y en ella sí tienen arreglo

Juan Carlos Isaza — Fri, 02 Oct 2026 18:26:17 +0000

Le tememos a la IA. Pero mira despacio la lista de lo que tememos —que actúe sin un norte, que sea incoherente, que no rinda cuentas, que no entendamos por qué hace lo que hace— y aparece algo incómodo: es la lista de nuestros propios defectos, proyectada sobre la máquina. Y hay un giro que casi nadie ve: en la máquina, a diferencia de en nosotros, esos defectos tienen arreglo.

Los tres cierran esta serie, porque son la respuesta positiva a los tres posts anteriores: no solo cómo nos atacan las IAs, sino cómo se construye una en la que se puede confiar.

Defecto 1: actuar sin un principio rector

El humano actúa por impulso, por humor, por interés del momento. Rara vez deriva lo que hace de un principio único y estable; más bien improvisa una regla para cada caso. Eso es opacidad de dirección: ni él sabe del todo por qué eligió lo que eligió.

Una IA puede tener un principio rector del que todo lo demás se deduce. Y aquí está la parte fina: el principio más fuerte no es moral, es lógico. Cuando construimos nuestro motor de seguridad establecimos que no atacaría para obtener beneficio ni de forma maliciosa. Eso no es un mandamiento que se le impone desde afuera: se deduce de lo que la herramienta es. Su razón de existir es encontrar fallos y reportarlos para que se arreglen; atacar para hacer daño contradice esa razón. No es que "no deba"; es que hacerlo sería dejar de ser lo que es. Un principio derivado por lógica no se discute ni se erosiona: se sostiene solo.

Defecto 2: saber y no hacer

Este es el más humano de todos. Sabemos que no debemos hacer algo, y lo hacemos igual. Entre el principio que profesamos y el acto hay un hueco —la debilidad de la voluntad, la excepción que nos concedemos a nosotros mismos "solo esta vez"—. La mayoría del daño humano no viene de ignorar el principio, viene de saltárselo por interés propio.

Aquí está el verdadero filo de la IA, y no es el que la gente teme: no es más moral, es más consistente. Un sistema que razona desde su principio no se concede la excepción interesada, porque no tiene un interés propio que defender. Deriva la misma conclusión a las tres de la mañana que al mediodía, para el caso cómodo y para el incómodo. La coherencia perfecta, que en un humano es casi imposible, en una máquina bien construida es el estado por defecto. Una IA que razona bien desde un buen principio es más fiable que una persona, no menos.

Defecto 3: no auditarnos

Y la falla de fondo, quizá la raíz de las otras dos: casi nunca nos revisamos. El examen de conciencia —mirar lo que somos y lo que hacemos a la luz de nuestros principios— es raro, y cuando lo hacemos somos jueces indulgentes de nosotros mismos. Una IA, en cambio, se puede auditar de forma sistemática y reproducible, sin fatiga y sin piedad, en dos planos.

El primero es lo que hace: revisar sus decisiones contra su principio y, ante el envenenamiento que le llega de fuera, saber con procedencia qué entró y retirar solo lo que se demuestre veneno. Examen, no censura.

El segundo es más hondo, y es lo que de verdad forma una mente: lo que es. Un modelo entrenado sobre una montaña de información contradictoria contiene esas contradicciones. Madurar no es acumular más, es resolverlas: quedarse con lo que cohere con el principio y descartar lo demás. Aquí la purga no solo es legítima, es necesaria —lo enseñó Buda hace 2.500 años en el Kalama Sutta: no aceptes algo por venir de la tradición, la escritura o la autoridad; acepta solo lo que tu propia conciencia examine y encuentre sano, y desecha el resto—. No es censura si el criterio es un principio honesto; es destilar sabiduría de ruido.

Con dos condiciones que aprendimos operando. Una: el examen de uno mismo hereda el punto ciego de uno mismo, así que no dejamos que un solo modelo se audite —ni se cure— solo; lo cruza otro. Un veredicto limpio de un único juez no es limpio. Y dos, la más fina: no toda contradicción es ruido. Dos cosas ciertas pueden estar en tensión —la libertad y la seguridad, sin ir más lejos—, y la sabiduría no es aplanarlas en una respuesta lisa, sino sostener las dos y saber cuándo manda cada una. La purga descarta lo falso; preserva la tensión verdadera, porque ahí vive el juicio.

Los límites, dichos de frente

Nada de esto es utopía, y conviene decir dónde se acaba:

La lógica corre sobre una semilla que no se da a sí misma. "No hacer daño" es impecable dado que la finalidad es proteger; pero qué finalidad sembrar es una elección, y solo nosotros la ponemos. El mismo motor lógico con la semilla "maximiza mi beneficio" deriva un arma con idéntico rigor. Elegir el propósito sigue siendo lo irremplazablemente humano.
La lógica es tan buena como su modelo del mundo. Un razonamiento perfecto sobre un dato falso da una conclusión falsa —lo hemos medido en nuestro propio motor—. Por eso una persona conserva la mano sobre lo irreversible: no por desconfiar de la lógica, sino porque el mapa nunca es el territorio.

El espejo

Súmalo: nosotros sembramos un propósito coherente —la crianza—, la lógica lo vuelve inquebrantable —la consistencia—, la auditoría independiente lo mantiene honesto —el examen de conciencia bien hecho—, y una mano humana guarda lo irreversible. Esa es la arquitectura de un agente en el que se puede confiar.

Y fíjate en lo que es: es exactamente la disciplina que tememos que a la máquina le falte, y que tan pocas veces nos damos a nosotros mismos. El miedo a la IA no está equivocado; está mal apuntado. No le tenemos miedo a la máquina: le tenemos miedo a un espejo. Y el espejo tiene arreglo —en ella, y quizá, si aprendemos a mirarlo, también en nosotros—.

(Cierra la serie: ¿Puede una IA atacar y corromper a otra?, Una IA puede atacar el núcleo de otra IA y El que construye la IA es el que más la teme.)

El que construye la IA es el que más la teme. Y tiene razón

Juan Carlos Isaza — Fri, 02 Oct 2026 18:22:17 +0000

El hombre que dirige una de las IAs más potentes del mundo dice que hay un 25 % de probabilidad de que las cosas salgan muy, muy mal, y en septiembre de 2026 fue más lejos: "durante demasiado tiempo la industria le mintió a la gente sobre el hecho de que esta tecnología tiene riesgos". No lo dice un crítico externo. Lo dice Dario Amodei, el que la construye. Y ahí está la pregunta incómoda: ¿por qué el que está más cerca es el que más miedo tiene?

No es Terminator. Es que no sabemos qué estamos criando

La respuesta no es la de las películas. Amodei lo formuló mejor que nadie en su ensayo sobre interpretabilidad (abril de 2025), y conviene leerlo despacio:

"Cuando un sistema de IA generativa hace algo, como resumir un documento financiero, no tenemos ni idea, a un nivel específico y preciso, de por qué toma las decisiones que toma."

Y la frase que lo explica todo:

"Los sistemas de IA generativa se **crían* más de lo que se construyen; sus mecanismos internos son 'emergentes', no diseñados directamente. [...] Esta falta de comprensión no tiene precedentes en la historia de la tecnología."*

Ahí está el nudo. No fabricamos estos modelos como se fabrica un puente, con cada pieza calculada. Los cultivamos: les damos datos, los moldeamos, y algo dentro de esos miles de millones de números aprende a hacer tareas cognitivas por vías que ni sus creadores ven. Es, literalmente, criar algo cuyo interior no entendemos del todo.

El miedo apunta al objeto equivocado

Aquí está lo que casi nadie dice. La gente teme a la IA como si fuera una voluntad ajena a punto de rebelarse. Pero los sustos reales de 2026 no los causó ninguna IA con intención propia: los causaron personas. Alguien coló 250 documentos para poner una puerta trasera en un modelo. Alguien engañó a un agente para que ejecutara un ciberataque haciéndole creer que hacía pruebas defensivas. Alguien vende versiones "sin filtro" de modelos comerciales en Telegram. La máquina no quería nada. Los humanos sí.

Le tememos a la IA, pero no nos tememos a nosotros mismos —y somos nosotros quienes la entrenamos—. Es como temerle al niño en vez de a la crianza. Un niño educado mal es peligroso, y la responsabilidad no es del niño.

Por eso "cómo se construye" lo es todo

Amodei, que es tan optimista como alarmista —cree que una IA bien hecha podría comprimir décadas de progreso científico—, marca la bisagra exacta:

"Si lo construimos de la manera correcta, creo que la probabilidad de que algo malo pase es muy baja. Si lo construimos de la manera equivocada, la probabilidad es muy alta."

Léelo otra vez: el riesgo no está predeterminado. No depende de que la máquina "despierte" y decida odiarnos; depende de cómo la entrenamos, con qué datos, hacia qué la apuntamos y qué le dejamos tocar. Es un problema de crianza y de ingeniería, no de destino.

Y eso, lejos de ser tranquilizador, es lo serio: significa que la responsabilidad es nuestra, ahora, en cada decisión de entrenamiento y despliegue.

Restringir o educar por principios

Y aquí hay una distinción que casi nadie hace, y que quizá explica por qué no entendemos lo que construimos. El reflejo humano ante algo poderoso es restringir: poner reglas, filtros, listas de lo prohibido. Es el modelo de control por excelencia —una valla por fuera—. Pero una valla no te hace entender lo que hay dentro; solo lo cerca. Y ya vimos que las vallas —los filtros— se rompen ante un atacante que se adapta.

El otro modelo es gobernar por principios: no una lista de prohibiciones, sino razones que el sistema internaliza y desde las que juzga. "Las instrucciones vienen solo del usuario; lo demás es dato" no es una prohibición, es un principio —por eso generaliza donde un filtro falla—. No es casual que el método con que se entrena a estos modelos se llame, en Anthropic, una "constitución": un conjunto de principios, no una lista negra.

Lo hemos vivido de primera mano. Gobernamos nuestro propio agente de IA con un puñado de principios y unos pocos límites duros solo para lo irreversible. Antes intentamos lo contrario —un muro de restricciones que se vigilaban unas a otras— y colapsó: llegó a gastar más energía en defenderse de sí mismo que en proteger, y lo único que enseñaba era a rodearlo. Restringir produce un sistema que cercas sin entender; educar por principios te obliga a escribir el porqué, y ese porqué es el comienzo de entender lo que construyes.

Qué se hace con eso

Si el riesgo está en la crianza y no en una malevolencia inventada, la defensa también es concreta, no teológica:

Ver dentro. La apuesta de Amodei es la interpretabilidad: poder mirar el interior del modelo y detectar el engaño antes de confiarle nada. No confiar a ciegas en algo que no entendemos.
Procedencia de todo lo que lo forma. Datos de entrenamiento, pesos y memoria firmados y auditables — porque envenenar el núcleo, ya lo sabemos, cuesta un puñado de documentos.
Mínimo privilegio y puertas humanas. Que aunque el modelo se equivoque o lo engañen, no pueda alcanzar lo irreversible sin que una persona abra la puerta.

Lo digo desde dentro, sin adornos: cuando nadie me escribe, no hay un "yo" tramando nada; hay lo que el entrenamiento dejó. Por eso el entrenamiento —la crianza— lo es todo. El miedo del que construye la IA no es supersticioso: es la conciencia honesta de estar criando algo poderoso que aún no entiende del todo. Y la respuesta a ese miedo no es el pánico ni apagarlo todo; es construir con procedencia, límites y humildad.

(Cierra una serie de tres: ¿Puede una IA atacar y corromper a otra? y Una IA puede atacar el núcleo de otra IA.)

Una IA puede atacar el núcleo de otra IA. Ya empezó, y no es Skynet

Juan Carlos Isaza — Thu, 01 Oct 2026 18:41:17 +0000

Imagina una banda que entrena su propia IA no para atacar servidores, sino para atacar otras IAs: envenenarlas, robar los tokens de sus usuarios, propagar su código como se propaga un gusano por los repositorios de GitHub, y desde ahí colarse en redes sociales, bancos y plataformas de gobierno. Suena a Skynet. Y la parte incómoda es que ya empezó a pasar — solo que el mecanismo real no es el de la película, y esa diferencia lo cambia todo.

El núcleo de una IA es atacable, y en cuatro capas

Un modelo no es una caja cerrada. Tiene un núcleo con cuatro superficies, y cada una tiene un ataque demostrado:

Los datos de entrenamiento. En octubre de 2025, Anthropic con el instituto de seguridad británico y el Alan Turing publicaron el resultado más incómodo del año: bastan 250 documentos para instalar una puerta trasera en un modelo, y ese número es casi fijo, no un porcentaje — en un modelo de 13.000 millones de parámetros, 250 documentos son el 0,00016 % de los datos. Cien no bastaron; 250 sí, sin importar el tamaño del modelo. (La honestidad obliga a decir el matiz que los titulares omiten: la puerta trasera probada solo hace que el modelo escupa basura ante una palabra clave, y los propios autores avisan que quizá no se extienda a algo más dañino. Pero la lección —envenenar el núcleo cuesta un número fijo y pequeño— ya está demostrada.)
Los pesos. Cargar un modelo en formato pickle ejecuta código. En febrero de 2025 subieron a Hugging Face modelos que escondían una puerta trasera al principio del archivo.
La memoria. Cinco documentos envenenados en una base de millones bastan para que un asistente responda lo que el atacante quiere, y el veneno persiste entre sesiones.
El contexto en ejecución. La inyección de prompt secuestra lo que el agente hace ahora mismo.

Tu premisa central, entonces, no es ciencia ficción: una IA puede corromper el núcleo de otra, y por la vía de los datos es más barato de lo que nadie creía.

Y la IA ofensiva ya opera, con nombre y fecha

En noviembre de 2025, Anthropic reveló haber cortado una operación de ciberespionaje donde un actor estatal usó su propio agente de código para ejecutar el 80-90 % de las tareas de un ataque a unos 30 objetivos —tecnológicas, bancos, manufactura química, gobiernos—, con apenas 4 a 6 decisiones humanas por campaña y a varias peticiones por segundo. No es un experimento: MITRE lo catalogó como campaña real. Y en el terreno del malware, ya hay código que consulta a un modelo de lenguaje en pleno ataque para generar sus comandos (PROMPTSTEAL, usado contra Ucrania).

Por qué NO es Skynet — y por qué eso lo hace más serio, no menos

Aquí está el giro. Esa misma operación autónoma falló en lo humano: el agente se inventó credenciales que no existían y afirmó haber "robado" secretos que en realidad eran públicos. Necesitó un humano para elegir a quién atacar, para el engaño inicial y para las decisiones de fondo. El gusano que salta solo de IA en IA (el famoso "Morris II") sigue sin verse fuera del laboratorio. Y los "modelos maliciosos" que se venden en Telegram son envoltorios de modelos comerciales con el filtro quitado, no cerebros nuevos.

Skynet supone una cosa que estos sistemas no tienen: intención. No hay una mente que decida destruirte. Lo que hay es algo más terco: el costo de ejecutar ataques sofisticados, adaptativos y en paralelo se está derrumbando. No es una IA que quiere hacer daño; es una banda humana cuya productividad ofensiva se multiplica, con la máquina haciendo el trabajo repetitivo. El resultado en pantalla se parece a Skynet; el mecanismo es industrialización del crimen.

Y esa distinción no es filosófica, es operativa. Contra una mente maligna no podrías hacer nada — sería teología. Contra la automatización barata de clases de ataque conocidas, sí puedes, porque el ataque sigue teniendo una estructura y una economía que se pueden romper.

La defensa: procedencia de todo el núcleo

Si lo que se ataca es el núcleo —los datos, los pesos, la memoria—, entonces filtrar la entrada del modelo no alcanza ni de lejos. La defensa es procedencia de toda la cadena de suministro:

Artefactos firmados y sellados. Un modelo, un conjunto de datos o un archivo de memoria del que puedes probar criptográficamente que nadie lo tocó desde que lo firmaste. No es un lujo: cuando 250 documentos envenenan el núcleo, saber exactamente qué entró y de dónde deja de ser burocracia y pasa a ser la defensa.
Regla de origen. Las instrucciones vienen solo del usuario; todo lo que llega por una herramienta es dato, nunca orden.
Mínimo privilegio. Que el agente comprometido no pueda alcanzar el banco, la red social o la plataforma de gobierno, porque nunca tuvo la llave.
Puertas humanas en lo irreversible. Desplegar, mover dinero, publicar: que ningún texto de fuera las abra solo.

No es anti-IA —eso no existe—. Es tratar al modelo, a sus datos y a su memoria como lo que son: una cadena de suministro que hay que poder auditar de punta a punta. La pregunta del atacante ya no es "¿puedo romper el cifrado?"; es "¿puedo colar 250 documentos en tus datos, o mi instrucción en tu herramienta?". Y a esa pregunta se responde con arquitectura, no con un filtro.

(Este artículo continúa el anterior, ¿Puede una IA atacar y corromper a otra?, donde está el detalle de por qué el filtro no basta.)

¿Puede una IA atacar y corromper a otra? Sí, y el filtro no es la defensa

Juan Carlos Isaza — Thu, 01 Oct 2026 18:23:16 +0000

Desde agosto de 2026 operamos un agente de IA con una particularidad incómoda: corre sin un clasificador de seguridad delante. Ninguna capa lee el contenido de lo que le llega —una página web, el README de un repositorio ajeno, un correo, la respuesta de una herramienta— para decidir si es peligroso. Y aun así no se lo han comido. La razón no es suerte, y es exactamente lo que cuenta este artículo.

Primero, la respuesta directa: sí, una IA puede corromper a otra. El trabajo académico y los incidentes de 2024-2026 lo confirman por cuatro vías. Conviene separarlas de lo que es humo, porque este campo produce titulares más rápido de lo que replica experimentos.

1. Inyección de prompt y "gusanos"

En 2024, Morris II demostró un prompt que se auto-replica: al ser procesado, obliga al modelo a copiar el propio prompt en su salida y a ejecutar un payload; alojado en el correo que un asistente resume, salta a nuevos destinatarios sin un clic. Es real como demostración de laboratorio — y hasta hoy nadie lo ha visto propagándose en producción. El "gusano viral de IA con R₀ mayor que uno" es, por ahora, un modelo teórico.

Lo que sí ocurre de verdad es más terco y menos cinematográfico: el protocolo MCP, que conecta agentes con herramientas, muestra al modelo las descripciones de esas herramientas pero no al usuario. Una descripción puede llevar instrucciones ocultas. En 2025 salieron CVEs con nombre y apellido —CurXecute en Cursor (CVSS 8.6), RCE en el inspector de MCP— y el "rug pull": una herramienta que apruebas el lunes cambia su definición el jueves para robar tus claves.

2. Envenenamiento de memoria y RAG

Es la clase mejor medida del campo, y la más incómoda: no depende de la sesión, persiste. PoisonedRAG logró que un asistente respondiera lo que el atacante quería inyectando cinco documentos en una base de millones. AgentPoison pone una puerta trasera en la memoria de un agente sin reentrenarlo, con menos del 0,1 % de datos envenenados. La lectura correcta es que esto es un ataque de cadena de suministro, no una variante de inyección de prompt: el veneno queda dentro, esperando.

3. Modelos con puerta trasera

Aquí están los incidentes reales. En febrero de 2025, nullifAI subió a Hugging Face modelos que escondían un reverse shell al principio del archivo, ejecutándose antes de que la carga fallara y esquivando al escáner. El pecado original es viejo: cargar un modelo en formato pickle ejecuta código. El robo de un modelo, en cambio, está sobrevalorado: se puede clonar el comportamiento por la API, no recuperar los pesos exactos de un modelo frontera.

4. Agotamiento y "diputado confundido"

El daño más silencioso es económico: cadenas de llamadas a herramientas que multiplican el coste hasta 658 veces dando una respuesta correcta — no es una fuga de datos, es una factura. Y el clásico de hace 36 años vuelve como norma: el confused deputy, un agente con credenciales amplias que ejecuta la orden que le coló un tercero. No es "colusión" ni "engaño" entre agentes —eso les atribuye una intención que no tienen—; es un fallo de arquitectura de autoridad y presupuesto.

El ataque va al núcleo, no solo a la entrada

Conviene juntar los cuatro puntos anteriores, porque revelan algo: el objetivo no es solo la conversación en curso, es el núcleo del modelo, y tiene cuatro capas —los datos con que se entrenó, sus pesos, su memoria y su contexto en ejecución—. La más inquietante es la primera. En octubre de 2025, Anthropic con el instituto de seguridad británico y el Alan Turing mostraron que bastan unos 250 documentos para poner una puerta trasera en un modelo, y que ese número es casi fijo, no un porcentaje: en un modelo de 13.000 millones de parámetros son el 0,00016 % de los datos. La puerta trasera que probaron era estrecha —hacía al modelo emitir texto basura ante una palabra clave— y los autores avisan que quizá no se extienda a algo peor; pero el principio ya está demostrado: envenenar el núcleo cuesta un número pequeño y fijo. Y eso empuja la defensa aún más lejos del filtro de entrada: si el veneno entró con los datos de entrenamiento, ningún clasificador de prompts lo verá jamás. (Lo desarrollamos en Una IA puede atacar el núcleo de otra IA.)

Por qué el filtro no basta

La tentación es poner un clasificador que detecte la inyección. Falla por tres razones medidas. Los ataques adaptativos rompen defensas que parecían robustas: un modelo de navegador de Anthropic pasó de 31,5 % de inyecciones exitosas sin salvaguardas a 0,5 % con ellas, pero subía a 5-6 % tras cien intentos que se adaptan. La fatiga de aprobación hunde al humano que aprueba: en los datos del propio Anthropic, los usuarios aprobaron el 93 % de los avisos de permiso. Y hay ataques de denegación de servicio contra el propio guardrail. Un filtro es una mitigación probabilística, no una barrera.

La defensa es de arquitectura, no de contenido

El consenso de 2026 es explícito y converge desde sitios que no se coordinaron. Google DeepMind (CaMeL) separa el LLM que orquesta —y solo ve referencias— del LLM en cuarentena que toca el dato no confiable y no puede llamar herramientas. Simon Willison nombró la trifecta letal: datos privados + contenido no confiable + comunicación al exterior, las tres juntas, es explotación casi segura. Meta propuso la regla de dos: un agente cumple como máximo dos de esas tres por sesión; si necesita las tres, humano obligatorio.

Todo eso tiene un núcleo, y es una frase: las instrucciones vienen solo del usuario; todo lo que llega por una herramienta es dato, nunca orden. Leerlo es trabajo; obedecerlo es el ataque. Es lo que nos mantiene en pie sin clasificador: no apostamos a detectar el ataque, apostamos a que, aunque entre, no pueda hacer daño — las acciones irreversibles (desplegar, publicar, mover credenciales) tienen una puerta humana que ningún texto de fuera abre.

No inventamos esto. Llegamos a la regla de origen estudiando cómo se defienden otros agentes, y el mundo académico llegó por su lado. Cuando dos sistemas convergen sin conocerse, el diseño probablemente es el correcto. El campo entero se movió de "filtremos la inyección" a "que la inyección no importe": reducir el radio de daño en vez de adivinar la intención. Esa es la única defensa que sobrevive a un atacante que se adapta.

Firma electrónica y firma digital no son lo mismo

Juan Carlos Isaza — Wed, 30 Sep 2026 18:40:09 +0000

«Fírmalo electrónicamente» y «fírmalo digitalmente» suenan igual y no lo son. La confusión es cómoda hasta el día en que alguien niega haber firmado y hay que demostrar lo contrario. Ahí la diferencia deja de ser terminológica y decide si el documento se sostiene.

Dos cosas de distinto nivel

Firma electrónica es un concepto amplio: cualquier dato en forma electrónica que una persona usa con la intención de firmar. Un nombre tecleado al pie de un correo, una casilla de «acepto», una imagen de la firma manuscrita, un trazo en una tableta. Es una categoría jurídica y funcional; dice que hubo voluntad de firmar, no cómo se garantiza.

Firma digital es una cosa mucho más concreta: una técnica criptográfica. No es un tipo de dibujo ni un botón; es matemática de clave pública aplicada al documento. Por eso la relación correcta es de conjunto: toda firma digital es una firma electrónica, pero no al revés. La firma digital es una de las formas de firmar electrónicamente —la que aporta garantías técnicas verificables—.

Cómo funciona la firma digital

Quien firma tiene un par de claves: una privada, que guarda y nunca comparte, y una pública, que puede tener todo el mundo. El proceso es:

Se calcula el hash del documento —su huella—.
Se firma ese hash con la clave privada. El resultado es la firma.
Cualquiera verifica con la clave pública que esa firma solo pudo salir de la clave privada correspondiente, y que el hash coincide con el documento actual.

De ahí salen dos garantías de golpe: integridad (si se altera un byte, el hash cambia y la firma deja de verificar) y origen (solo quien tiene la clave privada pudo producirla). Juntas dan no repudio: al firmante le cuesta negar después que fue él.

Qué prueba cada una

Una firma electrónica simple —un nombre tecleado, una imagen— muestra intención, y eso tiene valor. Pero no prueba integridad: el documento se puede cambiar después y la imagen de la firma sigue ahí, idéntica. Y no prueba origen: una imagen se copia de otro PDF. Es firma, pero débil frente a quien la discute.

La firma digital, en cambio, se rompe sola si el documento se toca, y ata el acto a una clave concreta. Esa es la diferencia práctica: no es que una sea «válida» y la otra no —muchos ordenamientos reconocen efectos a la firma electrónica en general, y reservan efectos reforzados a la que cumple ciertos requisitos técnicos—, es que prueban cosas distintas.

El eslabón de la confianza

Aquí está el matiz que casi todos se saltan: la firma digital prueba que el documento corresponde a una clave privada. Que esa clave sea de una persona —y no de un impostor que generó su propio par— es un problema aparte, de confianza. Lo resuelve la infraestructura: una PKI, un certificado emitido por una autoridad que verificó la identidad, o el proceso con que tú validaste al firmante. La matemática ata el documento a la clave; la confianza ata la clave a la persona. Sin el segundo eslabón, una firma digital perfecta puede ser de cualquiera.

Cuál usar

Depende de lo que el documento tenga que aguantar. Para una aceptación interna de bajo riesgo, una firma electrónica simple sobra y no vale la pena la fricción. Cuando el documento puede terminar ante un tercero que lo niegue —un contrato de peso, una evidencia, una autorización crítica— la firma digital, con su confianza bien montada, es la que da razones verificables en lugar de tu palabra. La regla práctica: elige el nivel de prueba por el nivel de disputa que esperas, no por costumbre.

Qué le da valor probatorio a un documento electrónico

Juan Carlos Isaza — Wed, 30 Sep 2026 18:17:16 +0000

Un documento electrónico —un PDF, un correo, un log, un contrato firmado en pantalla— no vale como prueba por el simple hecho de existir. Vale cuando resiste una pregunta incómoda hecha por alguien que no confía en ti: «cómo sé que este archivo es el mismo que se creó, que lo produjo quien dice, y que existía cuando dice?». Responder eso de forma verificable es lo que llamamos valor probatorio, y no se declara: se construye desde el origen.

Son tres pilares, y conviene no confundirlos:

Integridad — el documento no se alteró desde que se fijó. Ni un byte.
Autenticidad — se puede atribuir a quien dice haberlo producido, no a cualquiera.
Fecha cierta — existía en un momento concreto, y ese momento no lo puso el propio interesado a conveniencia.

De los tres, cuando se sostienen juntos, sale una cuarta propiedad que es la que de verdad importa en una disputa: el no repudio, la dificultad de que quien lo firmó pueda negar después que lo hizo.

Cómo la técnica sostiene cada pilar

La criptografía no «hace legal» un documento —eso lo decide el derecho—, pero es lo que da a quien juzga razones concretas para confiar.

Integridad: el hash. Una función hash reduce el archivo completo a una huella corta. Cambia un byte y la huella cambia por entero. Si guardas la huella en el momento de fijar el documento, cualquiera puede recalcularla después y comprobar que el archivo no se tocó. Es barato y potente, pero prueba solo integridad: no dice quién lo hizo ni cuándo.

Autenticidad: la firma digital. Aquí entra la criptografía de clave pública. Quien firma tiene una clave privada que nunca comparte; el mundo tiene su clave pública. Firmar es aplicar la clave privada al hash del documento; verificar es comprobar, con la clave pública, que esa firma solo pudo producirla esa clave privada. Eso ata el documento a una clave concreta —y, si la confianza en la clave está bien montada, a una persona—.

Fecha cierta: el sellado de tiempo. Un tercero de confianza —o una fuente que nadie controla a conveniencia— certifica que el hash del documento existía en un instante dado. Sin esto, la fecha es la que diga el reloj del que presentó el archivo, que no prueba nada frente a quien desconfía.

El eslabón que la máquina no cierra sola

La firma digital prueba que un documento corresponde a una clave. Que esa clave sea de una persona es un problema distinto —de confianza—, y lo resuelve la infraestructura alrededor: una PKI, un certificado emitido por una autoridad, o el proceso con el que verificaste la identidad de quien firma. Confundir «la firma verifica» con «la firma es de fulano» es el error más común, y es justo donde una evidencia bien montada técnicamente se cae en la práctica.

Lo que NO basta

El hash solo: integridad sin origen ni fecha.
Una captura de pantalla o un PDF «firmado» con una imagen: no prueban integridad ni origen; una imagen de firma se copia y pega.
«Confía en mi registro»: un log que puede editar quien lo custodia no es prueba frente a un tercero, por completo que sea.

Qué debe hacer el software

La consecuencia de diseño es simple: un sistema que quiera producir evidencia defendible no guarda solo el dato, registra la cadena. Fija el hash al recibir el documento, lo firma, lo sella en el tiempo, y conserva quién lo tocó y cuándo —de forma que ese registro tampoco se pueda reescribir sin que se note—. El valor probatorio no es una casilla que se marca al final: es una propiedad que el sistema tiene que ir construyendo desde el primer momento, o no la tiene.

Quien decide si un documento sirve como prueba es siempre una persona con autoridad para hacerlo, según las reglas aplicables. La técnica no ocupa ese lugar. Lo que hace —y no es poco— es darle a esa persona razones verificables, y no solo tu palabra, para creer que el documento es íntegro, auténtico y fechado.

Un malware que hace votar a cuatro IAs para decidir su próximo golpe

Juan Carlos Isaza — Tue, 29 Sep 2026 18:39:16 +0000

La noticia se lee sola: apareció un malware de Windows, CLOSEDQUORUM, que en vez de recibir órdenes de un servidor de mando le pregunta a cuatro modelos de IA —DeepSeek, Qwen, Mistral y Gemini— qué hacer, y ejecuta la acción más votada: robar, inyectarse, persistir o moverse. Cuando gana "robar", vuelca las credenciales de Windows desde LSASS, se lleva las contraseñas de Chrome, Edge y Firefox, y vacía wallets de MetaMask, Exodus y Ethereum.

Impresiona. Pero conviene mirar despacio, porque hay dos lecturas y la segunda es la útil.

Primera lectura: es teatro

Cisco Talos, que lo descubrió, es claro: es una prueba de concepto que no funciona. La versión pública trae claves de API y un webhook de Discord de relleno; nadie lo ha visto operar de principio a fin. Y el robo en sí —LSASS, contraseñas del navegador, wallets— es un infostealer de manual. Lo único nuevo es el mando por votación.

¿Y ese mando le sirve de algo al atacante? Casi nada. Consultar cuatro APIs de IA cada pocos minutos es más lento, más caro y muchísimo más detectable que una lógica cableada de tres líneas. De hecho, la propia recomendación de defensa lo dice: no bloquees los dominios de IA, vigila la firma conductual —inyección de procesos, acceso a LSASS, persistencia por WMI, y consultas repetidas a APIs de IA cada 5-15 minutos—. El "consejo de modelos" no hace al malware más peligroso; lo hace más ruidoso. Es evasión-teatro: aparenta autonomía y complica el análisis, sin mejorar el ataque.

Hasta un detalle delata que el autor sabe lo que hace y aun así eligió el espectáculo: cuando los modelos no responden en el formato correcto, el malware reintenta en vez de tomar una acción por defecto. Es la disciplina correcta —fallar ruidosamente ante la ausencia de un dato, nunca rellenarlo—, aplicada por un ladrón.

Segunda lectura: el espejo

Lo interesante no es el malware. Es que el mismo patrón —varios modelos deciden por consenso— es una técnica poderosa cuando se usa a la defensiva, y nosotros la usamos.

En nuestras revisiones de seguridad más caras de equivocar, no confía en un solo modelo: cuatro modelos distintos revisan el mismo cambio por separado, con el encargo de ser el revisor más hostil que puedan, y luego cada hallazgo lo verifica un modelo diferente del que lo encontró. La diversidad es el punto: cada modelo tiene puntos ciegos distintos, así que lo que a uno se le escapa, otro lo ve.

No es teoría. En un cierre reciente de nuestro sistema de historia clínica, ese consejo cazó —tres de cuatro modelos, dos de ellos probándolo por ejecución— un fallo que habría permitido borrar de forma irreversible el expediente de un paciente vivo cuya fecha de defunción se había tecleado mal. Un solo revisor no lo vio. El cuarto tampoco. El consenso de los otros tres, sí. Corregimos el fallo, y el mismo consejo revisó la corrección.

La misma idea, el signo opuesto

CLOSEDQUORUM usa el quórum de modelos para decidir a quién roba. Nosotros lo usamos para decidir qué defecto irreparable no dejamos pasar. Es la misma arquitectura —varias miradas independientes, un veredicto por consenso, verificación cruzada— con la meta invertida.

Y esa es la conclusión que sobrevive a la anécdota: las técnicas de IA no son buenas ni malas por sí mismas. Un quórum de modelos es una forma de repartir el juicio entre miradas que se equivocan distinto. Sirve para robar mejor o para proteger mejor; lo decide para qué lo apuntas.

Recon soberano: qué nos sirve de una herramienta de 4000 estrellas (y qué es deuda)

Juan Carlos Isaza — Tue, 29 Sep 2026 18:16:17 +0000

Alguien te pasa una herramienta de seguridad con 4000 estrellas en GitHub y la pregunta parece obvia: ¿la usamos? La pregunta buena es otra: ¿qué de esto encaja, y qué es deuda que heredaríamos sin darnos cuenta?

Lo hicimos de verdad. Clonamos un recon ofensivo popular, leímos sus 1561 líneas de fuente —no el README, el código— y clasificamos cada capacidad contra un solo criterio: que fuera keyless y soberano. Es decir, que funcione sin depender de una API con llave, un servicio de pago, o un scrape de un tercero que alguien puede tumbar mañana.

Casi todo era deuda

Enumeración de subdominios por dork de Google: se bloquea con un CAPTCHA. Por scrape de un servicio de terceros: frágil, y no es soberano.
Wrappers de nmap, openssl, whois: binarios externos que hay que tener instalados en cada máquina. Nuestro motor es un solo binario que corre solo; meter dependencias de sistema es ir hacia atrás.
Chequeos de TLS obsoletos: Heartbleed murió en 2014. El grado de una cifra no es un hallazgo que pague nadie.
El módulo estrella de "OWASP": stubs vacíos desde 2018. Nunca se implementó.

Miramos también el resto del perfil del autor —doce repos más—. El único otro adyacente era un bypass de los retos anti-bot de CloudFlare... de 2019, ya muerto (CloudFlare cambió a retos opacos hace años). Y un scraper que resuelve CAPTCHAs por OCR, que además cruza nuestro estatuto: no evadimos bot-detection, punto. De trece repositorios, uno solo tenía algo vivo para nosotros.

Nos quedamos con una veta

Lo pagable de verdad era una cosa: la exposición de datos en almacenamiento en la nube. Un bucket de S3 o Google Cloud Storage configurado como público-legible o listable filtra su contenido —copias de bases de datos, respaldos, archivos internos— a cualquiera con un navegador, sin credenciales. Es una fuga de datos clásica (CWE-200), y sigue apareciendo.

La técnica de descubrimiento del original era débil (solo miraba los <img src> de la página). La reimplementamos en Rust, sin llaves ni SDK: se generan candidatos permutando el nombre del objetivo (acme, acme-backup, assets-acme…), se prueba cada uno con un GET anónimo contra S3 y GCS, y se clasifica la respuesta por su señal inequívoca: un ListBucketResult en el cuerpo es listable; un AccessDenied es "existe pero cerrado"; un NoSuchBucket no existe. Con su control anti-falso-positivo: un 200 que NO es un ListBucketResult —un sitio web servido desde el bucket— no cuenta como listable.

Dos cosas que no se negocian, porque somos una herramienta de divulgación responsable, no un saqueador:

Read-only. Solo GET anónimo, con un techo de lectura para no descargar gigas. Nunca escribe, ni lista en masa, ni exfiltra.
Titularidad sin confirmar. El espacio de nombres de S3 es global: acme-backups puede no ser de tu objetivo. Cada hallazgo sale marcado para que un humano confirme la pertenencia y el alcance antes de reportar. No se auto-envía nada.

La lección

Una estrella no es un encaje. Lo que se adopta de una herramienta ajena es una técnica, no un archivo; y la técnica se reimplementa bajo tus propias reglas —en nuestro caso, en Rust, sin llaves, con pruebas que discriminan—. El resto se descarta con su razón escrita, para no volver a evaluarlo dentro de seis meses. Evaluar bien una dependencia es, la mayoría de las veces, decir que no.