Inyección de prompt como confusión de roles
Los ataques de inyección de prompt contra los modelos de lenguaje grandes se entienden cada vez más como una consecuencia de la “confusión de roles”, en la que los modelos infieren quién habla (sistema, usuario, herramienta, pensamientos internos) a partir del estilo de escritura y no de metadatos o etiquetas seguras. Los comentaristas sostienen que los mecanismos actuales de etiquetado de roles y las barreras de protección no ofrecen un límite de seguridad real, lo que facilita que prompts maliciosos o salidas de herramientas sobreescriban las políticas, especialmente en sistemas agénticos capaces de realizar acciones en el mundo real. Las mitigaciones propuestas van desde cambios arquitectónicos —como incorporar el rol o la procedencia directamente en las representaciones de tokens y separar estrictamente los datos del control— hasta un diseño de sistemas más conservador que aisle los LLM, los limite a tareas de bajo riesgo y trate toda salida del modelo como no confiable.
Confusión de roles y la naturaleza de la inyección de prompt
- Muchos comentaristas coinciden en que el artículo formaliza algo que los practicantes ya sabían: los LLM no tienen “roles” verdaderos; todo son solo tokens en una sola secuencia.
- El modelo infiere “quién está hablando” a partir del estilo y la posición, no de etiquetas seguras. Eso convierte a “hablar como el sistema” en una poderosa táctica de jailbreak.
- Varios lo comparan con la ingeniería social: si hablas con un tono de autoridad, el modelo te trata como tal.
Ideas para una señalización de roles más robusta
- Varias personas sugieren “colorear” los tokens: añadir dimensiones extra de embedding o vectores modificadores que codifiquen el rol (system/user/tool/CoT) por token, de forma análoga a los embeddings posicionales.
- Las variantes incluyen:
- Duplicar tokens para la cadena interna de pensamiento.
- Embeddings de segmento instructivo e IDs de origen por token.
- Usar metadatos explícitos por canal lateral en lugar de etiquetas dentro de la banda.
- Otros señalan desafíos: necesidad de datos de entrenamiento etiquetados, entrelazamiento de tema/fuente y riesgo de degradar el rendimiento del modelo.
Seguridad, sandboxing y límites de los LLM como componentes seguros
- Consenso fuerte: los LLM actuales no proporcionan ningún límite de seguridad real; los roles en las APIs son formato, no autorización.
- Algunos sostienen que cualquier sistema que permita a un LLM tomar acciones irreversibles es inherentemente inseguro; otros dicen que los usos restringidos y sandboxeados (p. ej., clasificación, detección de spam) son aceptables.
- Discusión sobre el aislamiento de sesión: los modelos son sin estado en principio, pero el manejo de la caché KV y los errores de sesión web aún pueden filtrar datos.
- La memoria persistente de agentes se destaca como especialmente arriesgada: las instrucciones inyectadas pueden “lavarse” hasta convertirse en notas “autoria propia” y volverse muy confiables más tarde.
Por qué la saneación clásica y las etiquetas se quedan cortas
- Los comentaristas preguntan por qué no simplemente eliminar o endurecer las etiquetas. Respuestas:
- Las APIs modernas a menudo ya usan tokens especiales no falsificables para los límites de rol.
- El problema central es que los modelos infieren los roles por el estilo; incluso sin etiquetas, el texto del usuario que parece cadena de pensamiento o política del sistema puede anular instrucciones.
- Se critican los benchmarks estáticos para inyección de prompt; el red-teaming humano que adapta los ataques es mucho más eficaz.
Reflexiones más amplias y escepticismo
- Algunos creen que la etiqueta de “teoría” está sobredimensionada; otros dicen que la merece al hacer predicciones comprobables y sugerir direcciones de investigación.
- Hay una preocupación recurrente de que hacer los modelos “seguros” mediante entrenamiento tiende a reducir drásticamente su utilidad, pero aun así no impide por completo los jailbreaks.