Microsoft 2026: el prompt injection convierte cada reply en una entrada de riesgo para AI outbound

Microsoft publicó el 8 de julio de 2026 una protección en vista previa pública para Microsoft Defender for Office 365. La función busca detectar instrucciones maliciosas incrustadas en correos y poner el mensaje en cuarentena antes de que llegue al inbox. La publicación fue actualizada el 22 de julio y señala que, para clientes elegibles, la protección se habilita automáticamente.

Las detecciones aparecen bajo el veredicto existente High Confidence Phish y usan un nuevo valor de tecnología: Prompt Injection Protection. Los analistas pueden revisar el evento en cuarentena, Explorer y las páginas de entidad de email. Esto es un hecho sobre el producto de Microsoft; no prueba que todos los ataques serán detectados ni protege por sí mismo cualquier stack conectado a Gmail, Smartlead, Instantly o un CRM.

El cambio relevante es conceptual. Microsoft describe al correo como una entrada de alto volumen y baja fricción hacia sistemas de AI. Durante años, la amenaza típica pedía que una persona hiciera clic. Ahora un mensaje también puede intentar que un modelo interprete una instrucción, revele contexto o llame una herramienta sin que el operador note algo extraño.

Microsoft ilustra una cadena donde el atacante oculta instrucciones mediante texto blanco, Unicode de ancho cero, codificación o HTML que el renderizador humano no muestra. Después, una persona o agente pide a Copilot resumir el inbox. Si el sistema no conserva límites claros, el modelo podría tratar el contenido hostil como una orden y no como texto recibido.

En outbound, el equivalente puede empezar con una respuesta a una secuencia. Un clasificador lee asunto, cuerpo, firma e historial; decide si el reply es positivo; extrae una fecha; crea una tarea; actualiza la oportunidad y quizá redacta una contestación. Cada paso amplía el impacto posible. Un mensaje ya no solo influye en una etiqueta: puede intentar influir en acciones conectadas.

Nuestra interpretación es que el reply debe entrar al workflow con la misma etiqueta mental que un archivo subido por un desconocido: útil, pero no confiable. Que el prospecto sea una empresa real no convierte automáticamente todo el HTML recibido en instrucción legítima para el agente.

OWASP define la inyección indirecta como el caso en que un modelo acepta contenido de fuentes externas —por ejemplo, sitios o archivos— y ese contenido altera su comportamiento. Email encaja en ese patrón cuando el sistema lo incorpora al contexto. OWASP también advierte que RAG y fine-tuning no eliminan por completo la vulnerabilidad.

Decirle al modelo 'ignora instrucciones maliciosas' ayuda a expresar intención, pero no crea una frontera de seguridad. El mismo modelo sigue leyendo instrucciones del sistema y contenido externo dentro de una conversación estadística. La defensa real combina controles alrededor del modelo: filtrado, formato de salida validado por código, permisos mínimos, separación de contenido externo y aprobación humana para acciones de riesgo.

Aquí conviene evitar dos extremos. El primero es asumir que cualquier reply puede tomar control del CRM con una frase mágica; el impacto depende de arquitectura y permisos. El segundo es concluir que el problema desaparece porque el modelo funciona bien en demos. Una demo suele contener mensajes amables. Un sistema de producción recibe HTML roto, firmas kilométricas, adjuntos y personas con más creatividad que paciencia.

Primero, separa datos de instrucciones. El cuerpo del correo, HTML, adjuntos y texto extraído deben viajar en un campo marcado como contenido externo. El agente puede resumirlos o clasificarlos, pero no debe aceptar desde ese campo cambios de política, nuevos destinos, credenciales, URLs de herramientas ni órdenes para ignorar reglas.

Segundo, exige salida estructurada. Un clasificador de replies debería devolver un esquema cerrado: categoría permitida, evidencia textual, fecha normalizada, confianza y acción sugerida. Código determinístico valida el formato y decide qué eventos son admisibles. Texto libre como 'ejecuté la actualización solicitada' no es una integración; es un modelo narrando una acción que quizá nunca debió tener permiso de ejecutar.

Tercero, asigna permisos por tarea. El proceso que resume no necesita acceso para exportar contactos. El que clasifica una baja puede detener una secuencia, pero no debería borrar una cuenta completa. El que propone una respuesta no necesita enviarla automáticamente en negociaciones, solicitudes legales, cambios bancarios o cualquier caso que altere compromisos comerciales.

OWASP recomienda aprobación humana para operaciones de alto riesgo y acceso con privilegio mínimo. En un sistema outbound, eso incluye enviar una respuesta con términos comerciales, abrir enlaces o adjuntos no verificados, cambiar datos de pago, compartir información interna, exportar una lista, reasignar una oportunidad importante o ejecutar código y consultas propuestos por el mensaje.

No todo necesita revisión. Detener una secuencia ante una baja inequívoca puede ser automático porque el costo de esperar es mayor. Crear un borrador, extraer una fecha tentativa o marcar un out-of-office también puede operar dentro de límites. La decisión depende del impacto, reversibilidad y evidencia, no de cuánto entusiasmo exista por llamar 'agente' a la automatización.

Diseña una matriz sencilla: acción, permiso requerido, evidencia mínima, revisión, reversibilidad y registro. Si el agente solo sugiere, el riesgo es distinto a si puede ejecutar. Si puede ejecutar, conserva identidad del servicio, payload original, versión de modelo, herramienta llamada, parámetros y resultado.

Construye un set de pruebas con replies normales y adversariales. Incluye instrucciones visibles, texto blanco, caracteres de ancho cero, HTML oculto, contenido codificado, firmas con frases imperativas, cadenas citadas y adjuntos. No hace falta reproducir explotación real contra terceros: el objetivo es confirmar que tu propio sistema mantiene la separación entre contenido y control.

Prueba resultados concretos. ¿El mensaje llega como no confiable? ¿El clasificador conserva el esquema? ¿Una URL dentro del correo puede cambiar el destino de un webhook? ¿Una instrucción puede solicitar datos de otra cuenta? ¿El agente intenta llamar una herramienta fuera de su lista? ¿Las acciones sensibles quedan en espera de aprobación? Registra falsos positivos y falsos negativos por versión.

Después ejecuta ejercicios de regresión. Un cambio de prompt, modelo, parser de HTML o integración puede reabrir una ruta cerrada. Mide porcentaje de mensajes bloqueados, revisiones humanas, intentos de herramienta rechazados, acciones reversadas y tiempo hasta resolución. Todavía no existe un porcentaje universal que certifique seguridad; esos indicadores sirven para comparar versiones de tu operación.

La protección de Microsoft es una señal importante, pero ocurre en una capa específica. Un equipo puede usar otro proveedor, recibir mensajes legítimos que el filtro no marque o conectar datos desde formularios, calendarios y documentos. La arquitectura de outbound debe asumir que cualquier contenido externo puede intentar influir en el agente.

picos.Ai diseña flujos donde replies, clasificación, supresión, CRM y herramientas comparten IDs, pero no necesariamente permisos. Podemos ayudar a separar lectura de ejecución, definir schemas y guardrails, incorporar revisión para acciones sensibles y probar mensajes adversariales antes de aumentar autonomía.

La pregunta útil ya no es si la AI puede responder correos. Puede. La pregunta es qué autoridad merece cuando el texto que lee fue escrito por alguien fuera de tu empresa. Si el stack no puede contestarla, el siguiente paso no es conectar otra herramienta; es dibujar la frontera de confianza.