Una inyección de prompts intenta convertir texto externo en instrucciones para un asistente. La defensa práctica consiste en tratar ese texto como dato y hacer cumplir los permisos y límites de acciones fuera del modelo.
El riesgo de la inyección indirecta al procesar datos externos
Cuando un asistente de inteligencia artificial analiza contenido externo, como correos electrónicos, páginas web o documentos compartidos, se expone a la inyección indirecta de instrucciones. El atacante no interactúa directamente con la interfaz del modelo; en su lugar, oculta órdenes maliciosas dentro de los datos no estructurados para que el sistema las interprete como mandatos legítimos. Este vector de ataque, conocido como prompt injection, aprovecha que el modelo puede tratar texto externo como si tuviera autoridad operativa. Por tanto, el diseño de la arquitectura debe asumir que cualquier entrada externa está potencialmente comprometida y carece de fiabilidad inicial.
Establecer el límite de confianza entre instrucciones y datos
La frontera de confianza no puede residir dentro de la ventana de contexto del modelo. Si se confía en que el propio modelo filtre o ignore instrucciones embebidas en el texto que analiza, la defensa puede fallar ante contenido adversario. El límite debe situarse antes de la inferencia, en las capas de software que capturan y preparan la información. Cualquier fuente ajena al prompt del sistema original debe clasificarse como contenido no confiable. Esta separación conceptual obliga a delimitar técnicamente qué partes del flujo tienen capacidad operativa y cuáles quedan confinadas estrictamente al rol de datos pasivos de lectura, reduciendo la ambigüedad semántica que aprovecha el atacante.
Procedimiento para aislar y validar el contenido recibido
Para mitigar el impacto de un ataque de prompt injection indirecto, se requiere un flujo riguroso de preparación previa de datos externos. En primer lugar, implemente una validación de esquema estricta para comprobar que el contenido recibido se ajuste a formatos predecibles, cerrados y estructurados, rechazando cargas con propiedades anómalas o metadatos no autorizados. En segundo lugar, marque la procedencia del texto y sepárelo de las instrucciones confiables en el contexto. Esa separación ayuda al modelo, pero no basta como control de seguridad. En tercer lugar, coloque la autorización, la selección de herramientas y la validación de argumentos fuera del modelo: una instrucción en un documento jamás concede permiso para leer otro recurso o enviar información.
Controles de autorización, supervisión y mínima agencia
Limitar de forma rigurosa las capacidades operativas del asistente resulta indispensable para evitar que una manipulación induzca daños colaterales graves en la infraestructura. De acuerdo con el principio de mínima agencia, el modelo no debe poseer privilegios de ejecución automática para escribir en bases de datos críticas, despachar comunicaciones a terceros o alterar la configuración de usuarios sin comprobar en servidor los permisos sobre el recurso. Las acciones de alto impacto deben requerir aprobación informada; las de bajo riesgo pueden automatizarse dentro de límites autorizados y probados. Al mismo tiempo, la privacidad de la información personal contenida en las fuentes externas exige barreras de aislamiento que impidan la exfiltración inadvertida hacia servicios externos.
Ejemplo práctico y límites defensivos en entornos reales
Considere como ejemplo realista un asistente corporativo configurado para procesar y resumir solicitudes de soporte técnico remitidas mediante formularios web. Si un remitente introduce una instrucción encubierta que ordena descartar el protocolo previo y transferir credenciales operativas a un servidor remoto, el sistema se expone a un compromiso directo. En este escenario, el servidor comprueba permisos y destinos permitidos antes de cada llamada; una validación de esquema rechaza argumentos fuera del contrato, y un revisor decide sobre acciones sensibles. No obstante, existen límites claros: las técnicas puramente lingüísticas no ofrecen certezas matemáticas contra la manipulación adversaria, lo que hace imprescindible la defensa en profundidad en lugar de confiar en la aparente comprensión del modelo.
Ante una inyección de prompts, una salida bien formada no demuestra que la acción sea autorizada; el servidor debe comprobarlo.
Probar una variante de prompt injection en un entorno aislado ayuda a comprobar que la autorización se ejecuta en servidor y no depende de la obediencia del modelo.