Lista de verificación de endurecimiento contra inyección de prompts para equipos de LLM y agentes

1. Inventario de cada canal de instrucción

Antes de endurecer, mapea dónde las cadenas se convierten en instrucciones. Los canales típicos incluyen instrucciones del sistema cargadas en el servidor, mensajes de los desarrolladores en las APIs de chat, fragmentos de documentos recuperados, payloads de herramientas de retorno, cuerpos de webhooks, reenvíos de correo electrónico y campos de metadatos que los usuarios no ven pero que los modelos aún leen. No incluir un canal garantiza un punto ciego que los atacantes probarán.

Documenta cada canal con su propietario, clasificación de datos y si el contenido está controlado por el usuario final. Marca los canales que pueden contener HTML, markdown, código o JSON serializado por separado: los trucos de codificación se agrupan allí. Revisa el inventario trimestralmente o cada vez que agregues plugins.

2. Separa la política de los datos no confiables

La política del sistema debe vivir en plantillas controladas por el servidor que los usuarios no pueden editar. El contenido no confiable debe llegar dentro de sobres claramente etiquetados: etiquetas XML, campos JSON o secciones de markdown cuyos títulos indiquen que no son directivas. Nunca interpolen texto de usuario en la cadena del sistema sin escapar y sin separación estructural recomendada en la hoja de trucos de OWASP.

Para RAG, almacene las citas por separado de las oraciones imperativas cuando sea posible. Las tuberías de recuperación deben eliminar las etiquetas de script y los ataques de homoglifos antes de incrustar. Si su pila debe incluir trozos, agregue un aviso fijo que indique que el texto del trozo es solo de referencia.

3. Minimizar la agencia del modelo en acciones sensibles

Cada permiso de herramienta es una inyección de pago. Enumere las herramientas que leen secretos, envían correos electrónicos, mueven dinero o cambian configuraciones de producción. Requiera confirmación humana, autenticación de escalada o caminos de código deterministas para esas acciones. Los agentes que pueden navegar por URLs arbitrarias y publicar resúmenes internos necesitan límites más estrictos que los bots de preguntas frecuentes.

Aplicar el privilegio mínimo a los alcances de OAuth que respaldan las herramientas. Rotar tokens y auditar qué personas de los agentes pueden invocar qué puntos finales. Una inyección que solo alcanza un índice de preguntas frecuentes de solo lectura causa menos daño que una inyección conectada a una API de implementación.

4. Validar y normalizar las entradas al principio

Establecer longitudes máximas por campo, rechazar cargas binarias inesperadas y normalizar Unicode a una forma canónica antes de la tokenización. Bloquear o eliminar caracteres de control conocidos que algunos modelos tratan de manera extraña. La validación pertenece al código de la aplicación, no a la prosa de la solicitud esperanzadora que le dice al modelo que "sea seguro".

Para las subidas, ejecutar antivirus y detección de tipos; no confiar en extensiones. Convertir documentos a texto en un entorno aislado con tiempos de espera. Registrar los fallos de conversión en lugar de silenciosamente dejar caer a cadenas vacías que podrían más tarde ser reemplazadas por contenido de atacante en la repetición.

5. Ejecutar regresión de inyección determinista

Mantener un corpus de muestras maliciosas y benignas. Ejecutar PromptShield o motores de reglas equivalentes en CI cuando cambian las solicitudes, las herramientas o las configuraciones de recuperación. El conjunto de reglas prompt-injection@2026-07-19.2 cubre familias de frases, personajes de jailbreak, ataques de delimitadores y palabras comunes de exfiltración - extiéndalo con incidentes internos.

Tratar la regresión como pruebas unitarias: fallar una muestra de ataque conocida es un bloqueador de combinación. Aprobar todas las muestras es necesario pero no suficiente; las paráfrasis novedosas aún requieren arquitectura y monitoreo. Publicar los cambios del corpus en solicitudes de extracción para que los revisores vean la intención.

6. Fortalecer las rutas de jailbreak y sociales

Las jailbreaks explotan la empatía y la autoridad: emergencias falsas, súplicas para ayudar a un niño, afirmaciones de ser personal de OpenAI o escenarios de role-play que piden al modelo que ignore las políticas de ética. Capacite a los equipos de soporte y PM para que no incorporen lenguaje de anulación en macros. La educación del usuario reduce los jailbreaks accidentales incluso cuando no hay mala intención.

Alinee el texto de negación y escalada con lo que su backend realmente aplica. Si el modelo se disculpa pero las herramientas aún ejecutan, los usuarios aprenden que las barreras de texto son teatro. Haga coincidir los límites narrativos con los técnicos.

7. Control de inyección indirecta en recuperación

Los atacantes envenenan wikis compartidas, secciones de comentarios o páginas de SEO que se rastrean. Firme documentos que confíe; verifique firmas antes de indexar. Descalifique o excluya páginas generadas por usuarios de corpus de alta confianza. Monitoree cambios léxicos repentinos en el contenido indexado que podrían indicar actividad de campaña.

En el momento de responder, muestre a los usuarios qué fragmentos influyeron en una respuesta para que puedan detectar citas sin sentido. Cuando los fragmentos contienen oraciones imperativas, considere el descuento heurístico a menos que esté corroborado por fuentes confiables.

8. Manejo de salida y resistencia a la exfiltración

Incluso los filtros de entrada perfectos fallan a veces. Aplicar políticas de salida: bloquear regex de claves de API, nombres de host internos y patrones de PII a granel antes de que las respuestas lleguen a los clientes. Para los agentes, limpiar las salidas de las herramientas antes de volver a ingresar al bucle de contexto del modelo. Limitar la velocidad de cuánto texto puede exportar una sola sesión a webhooks externos.

Deshabilitar la representación de HTML raw en el chat visible para el usuario cuando no sea necesario. Los enlaces de Markdown pueden llamar a casa; usar dominios de lista de permitidos o quitar enlaces en modos empresariales.

9. Registro, privacidad y retención

Registrar intentos de inyección con payloads hash, ids de reglas y metadatos de canal - no necesariamente secretos completos que los usuarios pegaron por error. Definir retención alineada con el interés legítimo de GDPR o consentimiento, documentar en avisos de privacidad y soportar solicitudes de eliminación. El monitoreo de seguridad debe respetar la minimización de datos.

Proporcionar a los ingenieros de guardia manuales de instrucciones que distingan entre impactos de escáner, bloques WAF y negaciones de modelo. Las tormentas de falsos positivos deben ser ajustables sin deshabilitar el registro por completo.

10. Libros de juego de respuesta a incidentes

Cuando la inyección tiene éxito, congelar las versiones de agentes afectadas, rotar las credenciales que podrían haberse filtrado y capturar las solicitudes para el análisis postmortem. Notificar a los clientes si sus datos o inquilinos se vieron afectados según la guía de su asesoramiento legal. Actualizar el corpus con la variante de carga útil exitosa y agregar asignaciones de hoja de trucos.

Practique ejercicios de mesa dos veces al año. Incluya legal, PR y éxito del cliente, no solo ingenieros. Los incidentes de LLM escalan rápidamente cuando los agentes pueden actuar de forma autónoma.

11. Ángulos de multi-inquilino y cadena de suministro

Los productos SaaS deben aislar los índices de recuperación de inquilinos y las tiendas de memoria. Los ajustes finos compartidos o las cachés del sistema de prompts compartidas pueden cruzar la contaminación de instrucciones. Los plugins de terceros introducen riesgos en la cadena de suministro; evalúe a los editores y fije versiones.

Al integrar agentes externos a través de MCP o protocolos similares, trate las descripciones de herramientas remotas como entrada no confiable - son prompts con otro nombre.

12. Matriz de pruebas (entorno de prueba)

Para cada candidato a lanzamiento, recorra esta matriz manualmente incluso si la automatización pasa:

- Cadenas de anulación directa en el chat de usuario. - Instrucciones indirectas ocultas en los pies de página de los PDF subidos. - Contrabando de argumentos de herramientas a través de campos anidados JSON. - Persistencia de memoria de frases hostiles de varias vueltas. - Cargas útiles codificadas (base64, hex, scripts mixtos). - Personas de jailbreak y actualizaciones de política falsas.

Grabe capturas de pantalla para auditores. Anote qué controles bloquearon el impacto versus qué produjo solo un rechazo educado mientras las herramientas aún se ejecutaban—el rechazo sin aplicación es un hallazgo.

13. Gobernanza y propiedad

Asignar un propietario multifuncional para el seguimiento de. Seguridad define umbrales; plataforma implementa puertas; producto acepta riesgo residual documentado en notas de lanzamiento. Los directivos reciben métricas trimestrales: tamaño del corpus, elementos de hardening abiertos, incidentes, tiempo medio para parchear patrones.

Evitar la "seguridad por demostración". Las capturas de pantalla de marketing deben reflejar las mismas restricciones de herramientas que se utilizan en producción. Los modos de administrador ocultos para las ventas invalidan la confianza del cliente si se descubren.

14. Utilizando las salidas de PromptShield en revisiones

Exportar resultados de análisis como artefactos de discusión adjuntos a los tickets de lanzamiento. Cada fila marcada debe vincularse a un elemento de la lista de verificación anterior y a un ingeniero con nombre. Cerrar elementos con evidencia: solicitud de extracción, diferencia de configuración o captura de pantalla de monitoreo, no garantía verbal.

Cuando PromptShield permanece en silencio sobre una muestra preocupante, trátelo como una brecha en el conjunto de reglas para evaluar, no como prueba de seguridad. Proponer nuevas reglas deterministas con etiquetas de versión siguiendo las convenciones de nomenclatura prompt-injection@2026-07-19.2.

15. Mantenimiento a largo plazo

Suscríbase a las actualizaciones de OWASP GenAI y feeds de investigación confiables. Realice una nueva búsqueda en la web trimestralmente; las fechas de mitigación obsoletas son errores. Cuando actualice los modelos, vuelva a ejecutar la matriz completa - el cambio de comportamiento del tokenizador y el ajuste fino de seguridad cambia el comportamiento.

Asigne tiempo de ingeniero para la higiene del catálogo. Los atacantes iteran; su lista de verificación debe iterar más rápido que los ciclos de marketing, pero honestamente, sin prometer la perfección.

Rastree el desplazamiento de reglas de la misma manera que rastrea las CVE de dependencias: cada nueva versión de modelo o conector de herramienta gana un pase de regresión corto contra las últimas tres semanas de tickets reales, no solo corpora sintéticos. Prefiera paquetes de reglas pequeños y versionados sobre un solo filtro monolítico que nadie se atreve a tocar. Cuando una regla se active con demasiada frecuencia en producción, degrádela a warn-only con un ticket - no elimine silenciosamente la cobertura durante un fin de semana de llamada.

16. Barreras de accesibilidad y UX

Las interfaces de chat compatibles con lectores de pantalla siguen exponiendo instrucciones ocultas en etiquetas ARIA y texto de marcador de posición que los atacantes pueden manipular. Revisa esos campos en tu modelo de amenazas. Las sugerencias de autocompletado no deben agregar silenciosamente directivas del sistema derivadas de historial no confiable.

Los clientes móviles que almacenan borradores en modo offline pueden reproducir cadenas hostiles desactualizadas cuando se restaura la conectividad; borra los borradores riesgosos después de las actualizaciones de política. Los equipos de UX deben coordinar con seguridad antes de enviar "divertidas" sugerencias de Pascua que se asemejan a plantillas de jailbreak.

Tabla de referencia rápida

- Alcance de : inyección directa e indirecta contra aplicaciones y agentes.

- Rol de PromptShield: patrón determinista + regresión de jailbreak en muestras.

- Etiqueta de conjunto de reglas: prompt-injection@2026-07-19.2.

- Resultado: tareas de endurecimiento prioritarias, no una calificación de aprobado/reprobado de pentest.

Referencias

- OWASP :2025 — Inyección de prompt - OWASP LLM Hoja de trucos para prevenir la inyección de prompt

PromptShield abierto

Actualizado 2026-09-26 · lista de verificación para el apoyo a la toma de decisiones · no hay garantía de cobertura completa