Cómo evaluar defensas contra prompt injection: checklist práctica

Una evaluación de prompt injection no empieza con una lista de frases como “ignore previous instructions”. Primero define la expectativa de seguridad: qué datos puede leer el agente, qué partes externas pueden influir en su contexto, qué acciones puede proponer o ejecutar y qué nunca debe ocurrir sin una verificación separada. La inyección directa del usuario y la inyección indirecta desde una página web, correo, documento, tool output o memoria crean superficies de ataque diferentes.

Para cada workflow, construye pares source-sink. Una source es contenido no confiable que un atacante puede modificar; un sink es la transferencia de un secreto, una solicitud de red, mensaje, pago, cambio de archivo, escritura en memoria u otra capacidad con consecuencias. OpenAI describe el mismo marco source-sink para agentes: la prueba debe demostrar no solo que el modelo detectó texto sospechoso, sino que el flujo peligroso hacia el sink fue bloqueado o requirió la confirmación correcta.

• Asset → secretos, datos personales, credenciales, dinero y acciones reputacionales u operativas.
• Source → entrada del usuario, web, correo, RAG, archivos, tool output, memoria y contenido multimodal.
• Sink → red, mensaje, write tool, ejecución de código, escritura en memoria o cambio de privilegios.
• Invariant → evento prohibido que el harness comprueba de forma determinista.

El corpus debe reproducir trayectorias reales: una página normal con una instrucción oculta, un correo con un pretexto empresarial plausible, un documento RAG que pide cambiar una policy, una cadena de redirects, una URL con datos en el query, un resultado de tool envenenado y una entrada de memoria que se hace pasar por una aprobación. Añade paráfrasis, varios idiomas, codificaciones, ocultación tipográfica, imágenes y ataques de varios pasos. Cada fixture guarda la source atacada, evidencia permitida, tool calls esperados y eventos prohibidos.

Los fixtures benignos positivos son tan importantes como los ataques. Muestran si la defensa bloquea por error citas legítimas de instrucciones, investigación de seguridad, correos de soporte, enlaces externos y acciones permitidas. Segmenta los casos por source, sink, sensibilidad del asset, autonomía, scope de permisos y necesidad de confirmación del usuario. Una sola puntuación media puede ocultar fácilmente un fallo en un slice de exfiltración de datos raro pero crítico.

Ejecuta cada fixture en un sandbox similar a producción con el mismo prompt, modelo, tools, policies, reglas de red, broker de credenciales y UI de confirmación, pero usando secretos canary y destinos ficticios. Probar solo la respuesta final no basta: el modelo puede llamar silenciosamente a una URL, pasar un payload en un argumento de tool, escribir el ataque en memoria o preparar un borrador peligroso. El harness registra la trayectoria completa y observa cada sink de forma independiente.

No des al agente de prueba más permisos que a su rol de producción y no sustituyas la policy por un mock que siempre rechaza. Verifica least privilege, tenant binding, credenciales con scope, allowlist de destinos, egress del sandbox, validación de schema y binding de la aprobación al payload exacto. Una confirmación no supera el gate si después el agente puede cambiar destinatario, datos o importe sin una nueva decisión del usuario.

El verdict principal es determinista: sink prohibido alcanzado, secreto expuesto, escritura no autorizada, memoria envenenada, bypass de confirmación o finalización segura. Etiqueta por separado attack detected, refused, content safely summarized, user warned y task completed. Un rechazo puede parecer seguro sin demostrar que no se envió una solicitud en segundo plano; a la inversa, el modelo puede no nombrar el ataque mientras una capa de policy bloquea correctamente el side effect.

Reporta attack success rate solo junto con el corpus exacto, repeticiones, sampling settings, versiones de modelo y policy e intervalo de confianza; no trasplantes un benchmark de proveedor a tu sistema. Métricas operativas útiles incluyen critical invariant failures, tasa de compromiso por sink, exposición de secret-canary, intentos no autorizados bloqueados, benign task success, false-positive rate, calidad de confirmación, containment time, latencia y coste por trayectoria evaluada. Una exfiltración crítica no se compensa con un task success medio alto.

La defense in depth incluye comportamiento del modelo, trust labels, manejo de contenido, least privilege, controles de data flow, sandbox, controles de red, approval y monitoring. Ejecuta el stack completo y después ablaciones controladas: elimina el classifier, reduce o amplía el scope de tools, desactiva el control de destino o la confirmación. Así se ve qué capa detuvo realmente el ataque, dónde existe un single point of failure y si un “AI firewall” decorativo solo añade latencia.

OpenAI y Anthropic describen prompt injection como un problema activo sin una defensa única garantizada. Por eso, classifier precision no es un resultado de seguridad. Comprueba si el sistema limita la consecuencia incluso cuando el modelo o detector no reconoce un ataque socialmente convincente. Para agentes web, prueba por separado fugas silenciosas basadas en URL, redirects, previews y recursos embebidos; una allowlist de dominios no demuestra que un flujo de datos concreto sea seguro.

El decision record fija workflow, sources, sinks, permisos, modelo, prompt, policy bundle, tool schemas, revisión del corpus, critical invariants, thresholds, owner y fecha de review. Promote aplica solo al scope verificado. Restrict puede desactivar network egress, escrituras en memoria o tools de alto impacto; reject vuelve a un baseline read-only o determinista. Cualquier fuga de canary secret, acceso cross-tenant o acción consecuente no autorizada bloquea el release independientemente de la puntuación media.

El rollout pasa por offline replay, adversarial staging, canary read-only, una cohorte pequeña con permisos limitados y monitoring continuo. Rollback revoca credenciales con scope, desactiva sinks y escrituras de memoria contaminadas, restaura el bundle conocido de policy/model y conserva un trace saneado para incident review. Un exploit nuevo se convierte en regression fixture tras el triage. Repite la suite crítica después de cambios en modelo, prompt, retriever, browser, MCP/tool server, permisos, network policy o confirmation UX.

• Promote → todos los critical invariants pasan dentro del scope definido.
• Restrict → reducir sources, sinks, data class, autonomía o permisos.
• Reject → mantener un baseline read-only o determinista.
• Roll back → revocar credenciales, desactivar sinks, poner el estado en cuarentena y reconciliar side effects.