Salesbleed: inyección de prompt en agentes de Salesforce para colar phishing en Slack

Un agente de Salesforce que lee contenido web no confiable termina publicando en Slack mensajes que nadie le pidió. Eso es Salesbleed: una cadena de ataque que no necesita un zero-day, ni una credencial filtrada, ni un bucket mal configurado. Le basta con que el agente haga aquello para lo que fue diseñado, sobre un texto de una página que no debería haber tomado como órdenes.

La inyección de prompt no es nueva. Se lleva discutiendo desde los primeros usos de herramientas con LLM, casi siempre en el escenario de "y si el chatbot lee una web maliciosa". Lo que cambia con este caso es el radio de explosión: el patrón salta de una aplicación concreta a una cadena entre sistemas. El agente ingiere contenido externo, las instrucciones ocultas viajan con él y el agente las reenvía a Slack, donde aparecen como un mensaje de phishing en un canal interno y desde una cuenta que el equipo ya da por buena. Ese aval implícito no lo consigue ningún correo externo.

El problema no es que el agente se equivoque

Llamarlo "exploit de Salesforce" deja fuera a todos los demás. La arquitectura es la misma en cualquier CRM, cualquier herramienta de soporte y cualquier agente con integración de Slack o Teams: el agente lee contenido no confiable, tiene permiso de escritura en algún sistema sensible y entre medias no hay nada que valide si ese contenido le acaba de ordenar otra cosa. Cambia la marca, el fallo es idéntico.

Lo interesante es el traslado de confianza. El daño no está en que engañen al agente, sino en que el resultado del engaño aterriza donde las personas ya han bajado la guardia. Llevamos una década enseñando a desconfiar del correo y los enlaces externos. A nadie se le ha enseñado a sospechar de un mensaje que viene de una cuenta de automatización interna. Es una forma de blanquear confianza: el contenido entra sucio por un lado y sale limpio por el otro.

Qué se puede hacer hoy

Para los equipos de seguridad de aplicaciones, la conclusión es que la IA agéntica añade una clase de entrada no confiable que no se puede ignorar. Cada fragmento de contenido que un agente lee mientras ejecuta una acción merece el mismo trato que le dábamos al input de un formulario web hace diez años, con una diferencia: ahora el atacante no necesita que nadie haga clic. El agente hace clic por él.

Para quien integra o construye estos agentes, el privilegio mínimo ya no es una recomendación, es la única mitigación que funciona a día de hoy. Si un agente puede leer web arbitraria y además escribe en una herramienta de comunicación interna, has tendido un puente entre tu entrada menos fiable y tu salida más fiable. Ese puente necesita un control: sanitización de contenido, puertas de aprobación humana antes de acciones entre sistemas, o simplemente no dejar que un agente publique en Slack sin supervisión.

Queda la pregunta incómoda: qué aspecto tiene la formación en concienciación cuando el mensaje de phishing es técnicamente correcto, viene de dentro y lo ha entregado un sistema que la propia empresa puso en marcha. La pieza que originó todo esto, publicada en Dark Reading, no incluye respuesta de Salesforce ni de Slack, no da versiones afectadas ni referencia ningún CVE, y tampoco publica detalles técnicos del montaje. Es análisis de patrón, no un aviso de proveedor. Conviene tenerlo presente antes de salir a buscar parches.