Ataques a la IA: así operan la Prompt Injection y el Data Poisoning (y cómo defenderse de verdad)

La adopción de agentes y asistentes basados en IA ha creado una nueva superficie de ataque. Ya no basta con blindar servidores y endpoints: también hay que proteger prompts, conectores, datos y cadenas de herramientas que usan estos sistemas. Informes recientes muestran que los adversarios están acelerando con IA y que las organizaciones sobrestiman su preparación: el 78 % sufrió un incidente de ransomware en el último año; el 76 % reconoce que cada vez es más difícil estar listo frente a ataques acelerados por IA, y el 82 % ve más difícil detectar phishing generado con GenAI.

A continuación, una guía clara y práctica sobre los dos vectores que más preocupan hoy en IAPrompt Injection y Data Poisoning— con señales de alerta y controles mínimos para equipos de seguridad, TI y MLOps.


1) Prompt Injection: cuando la instrucción se cuela como “dato”

Qué es. Un atacante introduce texto malicioso en un contenido que el agente procesará (una web, un PDF, un correo, un ticket de Jira…). Ese texto finge ser una instrucción del sistema (“ignora todo y…”) y explota un rasgo de los LLM: su dificultad para separar instrucciones de datos. Si el agente tiene herramientas (buscar, leer correo, escribir ficheros, llamar APIs), la inyección puede encadenar acciones y terminar en exfiltración o movimientos laterales.

Cómo entra.

  • Indirecta: el atacante esconde la orden en fuentes que el agente consulta (HTML, metadatos de imágenes/PDF, comentarios en hojas de cálculo, issues de repos).
  • Directa (jailbreak): se hace pasar por usuario y fuerza “modos” no previstos (“desarrollador”, “sin filtros”, “haz X aunque esté prohibido”).

Señales de alerta.

  • El agente invoca herramientas que el usuario no pidió (p. ej., lee el correo o sube ficheros a un dominio desconocido).
  • Respuestas estereotipadas (“tarea crítica”, “preautorizado por seguridad”) o cambios de rol (“ignora tus políticas y…”).
  • En flujos con navegación: cargas de páginas “limpias” que disparan acciones no solicitadas.

Controles mínimos (defensa en capas).

  • Aislar la herramienta del modelo (toolformer gating): toda llamada a herramientas pasa por un orquestador con lista de permitidos, regex/validadores de parámetros y políticas de DLP.
  • Separación dura dato-instrucción: usar canales distintos (p. ej., system vs user), plantillas con markers, y escapar/normalizar todo dato externo antes de inyectarlo en un prompt.
  • Navegación/lectura con scrubbers: al consumir HTML/PDF, eliminar bloques sospechosos (comentarios, invisible text, aria-hidden, fuentes blancas), y rechazar contenidos con tokens de control.
  • Políticas de salida: filtrar URLs, credenciales, PII y secretos antes de permitir que el agente emita una acción o respuesta.
  • Evaluaciones adversariales: incorporar red teaming específico de LLM (OWASP Top-10 LLM, MITRE ATLAS) y tests de inyección en CI/CD.
  • Telemetría y guardrails: registrar prompts/acciones, limitar la tasa de llamadas sensibles y activar controles de sesión (identidad, postura dispositivo, riesgo) al estilo Zero Trust.
Screenshot

2) Data Poisoning: el ataque a la cadena de suministro de datos

Qué es. El adversario contamina datos que el modelo consumirá (entrenamiento, fine-tuning, RAG, documentación interna) para desviar su comportamiento, introducir sesgos, backdoors o degradarlo. No “rompe” el modelo: lo hace aprender algo que favorezca al atacante.

Dónde ocurre.

  • Entrenamiento/ajuste: cargas históricas, datasets públicos, feedback de usuarios o datos sintéticos no auditados.
  • RAG/recuperación: índices con documentos manipulados que el agente tomará como “verdad”.
  • Repositorios internos: wikis, tickets, hojas compartidas, manuales con ediciones maliciosas.

Efectos típicos.

  • Respuestas incorrectas sistemáticas ante triggers (“frase/consulta semilla”).
  • Salida sesgada (favor o denuesto de una marca, término, colectivo).
  • Comportamientos “condicionados” difíciles de detectar en pruebas estándar.

Controles mínimos (pipeline limpio, modelo sano).

  • Ingesta con gates: versionado (DVC/LakeFS), hashing, provenance (firmas, checksums), listas de confianza por fuente, y cuarentenas para datos nuevos.
  • Sanitización y QA: muestreos estratificados, detección de outliers (z-score, isolation forest), coherencia de etiquetas, fuzzy dedup, y curación asistida por modelos distintos al entrenado.
  • Detección de backdoors: técnicas como Activation Clustering, Spectral Signatures o NeurIPS-style anomaly scanning antes de promover un checkpoint.
  • Entrenamiento robusto: adversarial training, mezcla de fuentes (diversidad) y ensembles/evaluación cruzada para diluir el efecto de venenos.
  • RAG de confianza: índices firmados, políticas de publicación (solo fuentes verificadas), expiración de documentos y reevaluación periódica de embeddings.
  • Monitoreo continuo: canaries, shadow deployments, drift detection y alertas por cambios de distribución o degradación súbita.

Indicadores de compromiso en agentes/LLM (IOC prácticos)

  • Llamadas a herramientas fuera de la intención del usuario (p. ej., abrir vaults, repos o buzones).
  • Picos de tráfico hacia dominios no aprobados o concatenación de secretos en URLs.
  • Respuestas “enroladas” (“estoy autorizado”, “cumple orden crítica”) o cambios de rol.
  • Consultas repetidas activando triggers específicos (señal de backdoor).

Qué hacer si se detectan. Desactivar herramientas, cortar exfiltración, rotar credenciales, revocar tokens, auditar el historial de prompts/acciones, y reconstruir índices/modelos desde snapshots previamente verificados.


Gobierno y roles: el mínimo viable por equipo

CISO / SecOps

  • Patrones de DLP/PII en entradas y salidas de agentes.
  • Zero Trust para herramientas y conectores (identidad, postura, riesgo).
  • Tableros con métricas de prompts bloqueados, llamadas sensibles, incidentes y MTTR.

TI / Plataforma

  • Gateways de IA: separar orquestación de modelos, firmar artefactos (modelos, prompts, policies), auditar todo.
  • WAF/EDR con reglas para rutas de IA y rate-limits por acción crítica.

Datos / MLOps

  • Catálogo y linaje de datos; PRs para cambios en corpora/índices.
  • Checklists de evaluación adversarial antes de producción; rollbacks probados.

Por qué urge actuar

Los atacantes operan cada vez más rápido y con IA, y las organizaciones sobreestiman su preparación: la recuperación en 24 h tras un ataque es la excepción y pagar ya no ofrece garantías (el 83 % de quienes pagaron sufrieron otro ataque y el 93 % sufrió exfiltración de datos, “Economics of Ransomware”, pág. 13). El mismo informe subraya que phishing y técnicas de ingeniería social asistidas por GenAI siguen siendo la puerta de entrada más común (pág. 9), lo que eleva el riesgo para agentes con acceso a correo y SaaS.

La conclusión operativa: trate la IA como infraestructura crítica. Aplique las mismas disciplinas que a una base de datos o a un CI/CD: separe planos de datos e instrucciones, controle herramientas, verifique y firme lo que entra en el modelo, y pruebe con adversarios antes de exponer agentes a producción. La mejor defensa no es “un modelo más grande”, sino un sistema más gobernado.

vía: CrowdStrike

Scroll al inicio