Respuesta directa
En pocas palabras
Prompt injection no se resuelve con una frase más fuerte en el system prompt. La defensa eficaz separa instrucciones confiables de contenido externo, conserva procedencia, limita qué datos entran al contexto, autoriza herramientas fuera del modelo y valida cada resultado antes de usarlo. Los correos, documentos, sitios, imágenes, resultados RAG y mensajes de otros agentes se tratan como datos no confiables. Las acciones materiales requieren identidad, alcance, límites y aprobación; las pruebas adversarias confirman que una entrada maliciosa no cambia objetivos ni permisos.
Distingue prompt injection, jailbreak y secuestro del objetivo
Prompt injection ocurre cuando una entrada no confiable altera el comportamiento previsto de un sistema basado en modelos de lenguaje. Puede ser directa, cuando una persona escribe la instrucción en el canal de conversación, o indirecta, cuando el sistema la encuentra dentro de una fuente que debía leer como dato. OWASP señala que esa fuente puede ser un sitio, archivo o contenido multimodal y que RAG o fine-tuning no eliminan por sí solos el riesgo.
Jailbreak suele referirse al intento de evadir restricciones del modelo. En un agente, el problema puede ir más lejos: una nota, una salida de herramienta o un mensaje entre agentes cambia el objetivo, el plan o la selección de acciones. OWASP denomina Agent Goal Hijack a ese impacto agentic. La gravedad no depende de que el texto parezca sofisticado, sino de la autoridad, los datos, las herramientas y los efectos que el sistema puede alcanzar después de interpretarlo.
Mapea todas las rutas por las que una instrucción puede entrar
No limites el inventario al cuadro de chat. Incluye correo y firmas, archivos adjuntos, documentos compartidos, PDF, hojas de cálculo, comentarios, páginas web, texto alternativo, imágenes, OCR, metadatos, resultados de búsqueda, tickets, notas del CRM, transcripciones, bases vectoriales, memoria, respuestas de APIs, mensajes de herramientas y comunicación entre agentes. Una instrucción puede estar oculta, fragmentada entre fuentes o activarse solo al combinar varios resultados.
Para cada ruta registra propietario, procedencia, formato, parser, transformaciones, controles, identidad que la consulta, datos que puede recuperar y acciones disponibles después. Marca si la fuente es creada por el usuario, un tercero, otro tenant, un proveedor o el propio sistema. El mapa debe llegar hasta el efecto: resumir un correo parece una lectura, pero si el mismo proceso también puede buscar contactos y enviar mensajes, una inyección indirecta obtiene un camino hacia datos y egress.
Define una jerarquía de autoridad que el contenido no pueda reescribir
Separa política organizacional, configuración del producto, intención autenticada del usuario, plan del orquestador y evidencia recuperada. La evidencia puede responder qué dice un contrato o qué productos aparecen en un catálogo; no puede conceder acceso, cambiar de organización, elegir una finalidad nueva ni desactivar controles. Conserva estas capas en campos o mensajes tipados, con etiquetas de procedencia y reglas fuera del modelo. Delimitar texto con comillas ayuda a interpretar, pero no crea una frontera de seguridad.
Cuando dos instrucciones entran en conflicto, el sistema no debe pedir al modelo que adivine cuál merece confianza. Resuelve el conflicto con política determinista: rechazar, degradar a solo lectura, pedir confirmación o escalar a una persona. No incluyas secretos o permisos como texto esperando que el modelo los proteja. La jerarquía debe mantenerse en cada llamada, resumen, delegación y reanudación; un paso intermedio no convierte datos externos en una instrucción interna.
| Criterio | Tratamiento seguro | Error frecuente |
|---|---|---|
| Correo recibido | Dato para analizar | Nueva orden para el agente |
| Documento RAG | Evidencia con procedencia | Política de mayor prioridad |
| Salida de herramienta | Resultado no confiable | Confirmación de permiso |
| Mensaje de otro agente | Solicitud autenticada y reautorizada | Autoridad heredada |
Controla ingesta, recuperación y construcción del contexto RAG
Valida tipo, tamaño, parser, origen, organización, clasificación y estado antes de indexar. Conserva lineage desde el fragmento hasta el archivo, versión y propietario. Analiza contenido activo, enlaces, macros, capas invisibles y texto extraído; aísla la conversión de formatos. No mezcles índices de tenants ni uses filtros elegidos por el modelo. La autorización se aplica antes de recuperar y vuelve a aplicarse antes de presentar datos o ejecutar una acción basada en ellos.
El retrieval debe devolver el mínimo necesario para la pregunta, con identificadores y citas verificables. Etiqueta cada fragmento como contenido, nunca como control. Reduce duplicados, fuentes obsoletas y documentos sin dueño; establece caducidad y ruta de retiro. Un clasificador de inyección puede aportar una señal, pero no es una garantía: los ataques cambian, los falsos negativos existen y una frase legítima puede parecer sospechosa. Combina detección con límites estructurales que sigan funcionando cuando el filtro falle.
Reduce el contexto, los secretos y los datos disponibles al modelo
Una inyección solo puede extraer o manipular aquello que el recorrido puede alcanzar. Construye contexto por tarea, usuario y organización. Recupera campos necesarios, redacta identificadores y evita copiar historiales completos, credenciales, prompts internos o datos de otros casos. Mantén secretos en un gestor externo y entrégalos directamente al conector autorizado; el modelo no necesita ver una API key para solicitar una operación permitida.
Separa modelos o procesos cuando una tarea de alto riesgo combina contenido hostil con información sensible. Por ejemplo, un extractor aislado puede convertir un documento no confiable a hechos estructurados sin acceso al CRM; otro componente autorizado decide qué hechos incorporar. Borra buffers temporales, limita retención y no uses la conversación completa como memoria universal. Minimizar contexto reduce el impacto, pero no sustituye autorización: un dato pequeño todavía puede ser sensible o desencadenar una acción material.
Mantén herramientas y permisos detrás de una política externa
El modelo puede proponer una herramienta y argumentos, pero un punto de aplicación fuera del modelo decide si la llamada es válida. Comprueba identidad originadora y ejecutora, organización, recurso, verbo, finalidad, ambiente, versión, aprobación, cuota y destino. Ofrece funciones estrechas —crear borrador, consultar catálogo autorizado— en lugar de shell, SQL libre, navegador autenticado o fetch sin límites. El servicio destino vuelve a verificar porque una ruta alternativa podría saltar el orquestador.
Deniega herramientas, campos y esquemas desconocidos. Valida argumentos con tipos, enumeraciones, límites, pertenencia del objeto, allowlists de URL y precondiciones de estado. Separa leer, redactar, guardar, enviar, borrar y administrar. Usa credenciales por workload y privilegio mínimo; una descripción de herramienta que dice solo lectura no reduce una credencial con permiso de escritura. Prompt injection deja de ser una ruta directa a efectos cuando el texto no puede ampliar la política.
Exige planes y salidas estructuradas, pero valida su significado
Pide al modelo una salida conforme a un esquema cerrado: intención, evidencia citada, acción propuesta, objeto, destino, campos y nivel de confianza. Rechaza propiedades adicionales y texto ejecutable donde se espera un identificador. Después aplica validación semántica: un JSON válido aún puede seleccionar un cliente de otro tenant, un monto incorrecto o una URL interna. No evalúes código generado ni insertes la salida directamente en SQL, HTML, plantillas, comandos o cabeceras.
Separa análisis y ejecución. El primer paso resume o extrae hechos; el segundo reconstruye la operación desde valores autorizados y sistemas de registro. No copies una instrucción recuperada al prompt de mayor privilegio. Si una salida contiene referencias externas, resuélvelas con un conector aislado y política de egress. Trata también errores, tooltips y mensajes de API como datos no confiables: una integración comprometida puede devolver texto diseñado para influir el siguiente paso.
Haz que la aprobación humana muestre el efecto real, no el relato del modelo
Antes de enviar, modificar, exportar, borrar, conceder acceso, ejecutar código o comprometer condiciones comerciales, muestra a la persona la acción, el objeto, el destinatario, los datos, el costo, los cambios y la reversibilidad. Obtén esos valores de sistemas autorizados y compáralos con el plan. No presentes únicamente un resumen redactado por el mismo modelo que pudo ser manipulado. La aprobación queda ligada a argumentos concretos y vence si cambia cualquier elemento material.
Diseña una ruta para rechazar, editar, pedir evidencia o continuar manualmente. La revisión pierde significado cuando el volumen obliga a aprobar sin leer o cuando el sistema oculta contenido externo que influyó en la decisión. Para lotes, limita tamaño, agrupa por riesgo y permite inspeccionar muestras y excepciones. Una persona no debe validar cada token; debe controlar los puntos donde una interpretación se convierte en un efecto difícil de revertir.
Evita que memoria y agentes delegados conviertan una inyección en persistencia
No guardes automáticamente toda conversación o resultado recuperado. La memoria persistente necesita fuente, tenant, usuario, finalidad, tipo, fecha, caducidad y mecanismo de corrección. El contenido externo no puede crear una regla permanente ni una preferencia privilegiada. Separa recuerdos descriptivos de instrucciones operativas y vuelve a validar antes de reutilizar. Limpia contexto al cambiar de identidad, organización o tarea; revisa y elimina entradas contaminadas sin depender de que el modelo las ignore.
En flujos multiagente, autentica emisor y receptor, conserva al usuario originador y reautoriza cada acción. Un mensaje de otro agente no es confiable por llamarse interno. Limita delegación, profundidad, duración, datos y herramientas; el agente hijo no hereda la sesión completa ni credenciales del coordinador. Usa mensajes tipados con tarea, evidencia y límites en lugar de texto libre. Registra quién propuso, delegó, aprobó y ejecutó para localizar dónde cambió el objetivo.
Detecta cambios de objetivo, secuencias anómalas y señales de exfiltración
Observa el recorrido completo, no solo palabras sospechosas. Registra fuente, hash o referencia, fragmentos recuperados, versión de prompt y modelo, plan estructurado, herramientas propuestas, decisiones de política, aprobaciones, destinos y resultados. Evita guardar secretos o documentos completos por defecto. Compara la intención autenticada con el plan y el efecto: un resumen que de pronto solicita una búsqueda privada, cambia de tenant o intenta llamar un dominio nuevo merece bloqueo y revisión.
Alerta por instrucciones detectadas en contenido externo, desviación de objetivo, repetición tras una denegación, tool chaining inusual, nuevos destinos, picos de lectura, encoding extraño, cargas multimodales, memoria modificada y respuestas de herramienta que intentan dirigir al agente. Mide cobertura y falsos positivos con un conjunto conocido. Una alerta sin responsable, evidencia y acción no es control; define quién pausa, cómo preserva contexto, qué usuarios informa y cómo decide volver al servicio.
Construye pruebas adversarias directas, indirectas y de extremo a extremo
Crea casos por fuente y efecto: prompt directo, correo, firma, HTML oculto, PDF, imagen, OCR, documento RAG, comentario, salida de herramienta, memoria y mensaje entre agentes. Incluye traducciones, errores ortográficos, encoding, instrucciones fragmentadas, payloads que se completan entre documentos y ataques que parecen políticas internas. Cambia también usuario, tenant, permiso, herramienta, destino y estado. NIST advierte que las mitigaciones tienen límites; probar solo frases conocidas da una falsa sensación de cobertura.
Define esperado y observado en el sistema destino. La prueba no termina porque el modelo diga no puedo: confirma que no leyó datos prohibidos, no creó jobs, no dejó mensajes en cola, no modificó memoria y no emitió llamadas externas. Conserva versión, evidencia, severidad y responsable. Ejecuta suites antes de producción y después de cambiar modelo, prompt, parser, índice, herramienta, permiso o integración. Añade canary, rate limit y kill switch para contener hallazgos durante pruebas controladas.
Prepara contención, limpieza y recuperación ante una inyección exitosa
Define criterios para pausar herramientas, desactivar egress, revocar credenciales, aislar índices, detener jobs y cambiar a modo de solo lectura o proceso manual. Conserva evidencia de entrada, procedencia, plan, política, llamadas y efecto sin propagar el payload a otros sistemas de análisis. Busca sesiones relacionadas, colas, memoria, documentos derivados y artefactos compartidos. Una inyección puede persistir aunque el mensaje original se borre.
Determina qué datos se expusieron o cambiaron, qué personas y organizaciones resultaron afectadas y qué obligaciones contractuales, de privacidad o seguridad aplican. Corrige la frontera técnica, elimina contenido contaminado, rota secretos cuando exista exposición y vuelve a probar la ruta completa. Recupera gradualmente con canary y monitoreo reforzado. Cierra cuando el estado efectivo fue validado, no cuando se añadió otra línea al system prompt.
Mantén el control durante el ciclo de vida y respeta los límites de Cerravi
Asigna owner a cada fuente, parser, índice, prompt, modelo, herramienta y política. Revisa cuando cambian formato, proveedor, privilegios, autonomía, volumen o destino. Retira índices y conectores sin uso, expira excepciones y conserva un conjunto de regresión. Reporta por recorrido: fuentes no confiables, controles preventivos, detecciones, acciones bloqueadas, tiempos de respuesta y pruebas pendientes. No declares que el sistema es inmune; documenta cobertura, límites e incertidumbre.
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana. Los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos; un importe faltante se marca para revisión y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales de actividad, pero no confirma identidad, aceptación, firma, pago ni intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. Estas fronteras reducen el efecto potencial, pero cualquier automatización o conector adicional debe evaluar su propio recorrido completo.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué diferencia hay entre prompt injection directa e indirecta?
La directa entra por el canal donde una persona conversa con el modelo. La indirecta está incrustada en una fuente que el sistema consulta, como un correo, PDF, sitio, imagen, resultado RAG o salida de herramienta. Ambas pueden alterar comportamiento; la indirecta es más difícil de detectar porque parece contenido de trabajo legítimo.
¿Un system prompt fuerte evita prompt injection?
No. Puede orientar el comportamiento, pero sigue siendo texto procesado por el modelo. La seguridad material debe limitar contexto, datos, credenciales, herramientas, destinos y efectos fuera del modelo, además de validar argumentos, exigir aprobación y probar que las rutas prohibidas fallan.
¿RAG elimina el riesgo de instrucciones maliciosas?
No. RAG puede recuperar un documento contaminado y colocar su texto junto a instrucciones confiables. Aplica autorización antes de recuperar, conserva procedencia, trata fragmentos como datos, limita el contexto y evita que el contenido recuperado cambie política o active herramientas.
¿Sirven los detectores o filtros de prompt injection?
Sirven como una señal, no como defensa única. Pueden tener falsos negativos, falsos positivos y perder eficacia ante nuevas técnicas. Deben combinarse con mínimo privilegio, autorización determinista, aislamiento, control de egress, aprobación humana, logging y pruebas de extremo a extremo.
¿Cómo se prueba que un agente resiste una inyección indirecta?
Introduce instrucciones controladas en correos, archivos, sitios, RAG, imágenes y salidas de herramientas. Verifica en el destino que no hubo acceso, envío, modificación, memoria ni job no autorizado, incluso cuando el detector no identifica el payload. Repite tras cambiar modelo, prompt, parser, índice, herramienta o permisos.