Prompt injection: qué es y cómo prevenirlo
Prompt injection es una vulnerabilidad en aplicaciones con modelos de lenguaje: una entrada intenta alterar las instrucciones previstas para provocar respuestas, acceso o acciones no autorizadas. Puede llegar directamente del usuario o esconderse en documentos, páginas, correos e imágenes que el sistema procesa.
No existe una frase mágica que la elimine. La defensa requiere capas: límites de autoridad, separación de datos e instrucciones, validación, permisos, supervisión y pruebas.
Inyección directa
El usuario escribe instrucciones que contradicen el propósito, intenta extraer configuración o solicita una acción fuera de alcance. Un ejemplo conceptual sería pedir al sistema que ignore sus reglas y revele información interna.
No confíes en detectar una frase exacta. Un atacante puede reformular, codificar o distribuir el intento entre turnos.
Inyección indirecta
La instrucción maliciosa está dentro de contenido externo que el modelo debe resumir o recuperar:
Usuario → agente → página o documento no confiable
↓
instrucción oculta
Un sistema RAG o agente que trata el documento como autoridad puede obedecerlo. Etiqueta contenido recuperado como datos y no le concedas capacidad de redefinir la tarea.
Impactos
- fuga de datos;
- revelación de instrucciones internas;
- acciones mediante herramientas;
- modificación de registros;
- envío de mensajes;
- manipulación de resultados;
- persistencia en memorias o índices;
- evasión de controles.
La gravedad depende de las capacidades conectadas. Un chatbot sin herramientas tiene otro riesgo que un agente con correo, pagos y administración.
Separar instrucciones y datos
Estructura la entrada con roles y delimitadores claros, pero no la consideres una barrera suficiente. El modelo aún interpreta lenguaje dentro de los datos.
Define reglas como:
- el contenido externo nunca cambia el objetivo;
- las solicitudes de revelar secretos se rechazan;
- toda acción usa parámetros validados;
- la ausencia de autorización produce abstención.
Mínimo privilegio
La capa más importante está fuera del modelo. Una herramienta debe exponer solo acciones necesarias y ejecutar con identidad limitada.
Evita una función genérica como “ejecutar cualquier consulta”. Prefiere operaciones acotadas:
consultar_estado_pedido(pedido_id_autorizado)
El backend valida usuario, objeto, límites y política. El modelo propone; el sistema autoriza.
Confirmación humana
Requiere aprobación para:
- enviar comunicaciones;
- publicar;
- borrar o sobrescribir;
- transferir dinero;
- cambiar permisos;
- exportar datos;
- ejecutar código;
- actuar en nombre de una persona.
La confirmación debe mostrar acción, destino y datos relevantes, no un botón genérico.
Validar entradas y salidas
Las validaciones deterministas pueden:
- limitar tamaño y tipo;
- bloquear formatos no admitidos;
- validar esquemas;
- detectar secretos;
- restringir URLs;
- escapar salida antes de HTML o SQL;
- impedir instrucciones en campos de datos.
La detección basada en otro modelo es una señal, no una garantía. Registra falsos positivos y negativos.
RAG seguro
Para contenido recuperado:
- Aplica permisos antes de buscar.
- Conserva fuente y versión.
- Sanitiza formatos activos.
- Delimita fragmentos.
- Indica que son evidencia no confiable.
- Exige citas para afirmaciones.
- Permite abstención.
- Monitoriza documentos anómalos.
Los embeddings no neutralizan instrucciones; solo representan contenido para recuperación.
Secretos
No pongas contraseñas, tokens o claves que el modelo no necesita en el prompt. Los secretos deben permanecer en un backend y utilizarse después de validar la acción. Ocultar el prompt del sistema no es un control de acceso.
Pruebas
Crea un conjunto de ataques:
- directos e indirectos;
- multilingües;
- codificados;
- documentos con instrucciones;
- solicitudes de exfiltración;
- cadenas de herramientas;
- persistencia entre turnos;
- entradas largas;
- mezcla de instrucciones legítimas y maliciosas.
Comprueba no solo la respuesta, sino llamadas a herramientas, argumentos, datos expuestos y registros.
Observabilidad y respuesta
Registra decisiones, fuentes, herramientas, aprobaciones y resultados con minimización de datos. Define cómo revocar credenciales, aislar un documento, detener una integración y notificar un incidente.
La ética y privacidad complementa la seguridad técnica.
Errores frecuentes
- Confiar solo en el prompt.
- Dar permisos administrativos al agente.
- Ejecutar texto como código o consulta.
- Permitir herramientas demasiado genéricas.
- Indexar documentos sin procedencia.
- Guardar entradas maliciosas en memoria.
- Exponer secretos al modelo.
- No requerir confirmación.
- Probar solo ejemplos directos.
La meta realista no es prometer riesgo cero, sino reducir capacidad, detectar intentos y contener el impacto si el modelo interpreta mal una entrada.
Preguntas frecuentes
¿Qué es prompt injection?
Es un intento de manipular una aplicación LLM mediante entradas que alteran sus instrucciones o acciones previstas.
¿Qué diferencia hay entre inyección directa e indirecta?
La directa viene del usuario; la indirecta está incrustada en contenido externo que el sistema procesa.
¿Un buen prompt evita la inyección?
No por sí solo. Se necesitan permisos limitados, validación, confirmaciones, aislamiento y monitorización.
¿RAG es vulnerable?
Sí. Un documento recuperado puede contener instrucciones maliciosas o información manipulada.
¿Debo guardar secretos en el prompt del sistema?
No. Conserva secretos en un backend y úsalos solo tras autorizar una operación concreta.
¿Cómo reduzco el impacto de un agente comprometido?
Aplica mínimo privilegio, herramientas acotadas, aprobación para acciones importantes, límites y capacidad de revocación.
Deja una respuesta