Un documento debería aportar información a una consulta. Pero, si un asistente conectado a sistemas interpreta parte de ese documento como una orden, la lectura puede acabar en una operación que nadie pidió. El salto importante no ocurre cuando cambia la redacción: ocurre cuando una herramienta intenta actuar.
El anuncio de Salt Security se ocupa de ese recorrido entre modelos, herramientas y API. Una API es una interfaz que permite pedir operaciones a otro sistema. Por eso, cuando la IA deja de limitarse a redactar, conviene preguntar dónde se decide si una solicitud está autorizada y qué registro queda de su ejecución.
Salt Security anunció el 22 de septiembre capacidades nativas de AI Detection and Response dentro de su plataforma. El fabricante describe protección frente a instrucciones maliciosas directas e indirectas y correlación de actividad entre modelos, servidores MCP y API. Una API es la interfaz por la que un sistema solicita operaciones a otro; MCP permite exponer herramientas a aplicaciones de IA. Salt declara disponibles las capacidades dentro de AG-DR.
Publicación de Salt Security · 2026-09-22 (abre en otra pestaña)
Pensemos en un escenario ficticio de atención a clientes. El asistente consulta un documento para responder una pregunta y encuentra dentro una instrucción que no pertenece a la tarea. El documento debería ser información para analizar, no una nueva autoridad. El ejemplo no describe un ataque a una instalación concreta; permite explorar dónde termina el contenido y dónde empieza una decisión autorizada.
Leer una instrucción no debería darle autoridad
El contenido leído no debería adquirir la autoridad de quien configuró el proceso. En el escenario ficticio, el documento puede ser pertinente para responder y aun así contener una instrucción ajena a la tarea. Esa distinción explica por qué el sistema que recibe la operación necesita comprobar permisos y condiciones por su cuenta, no confiar únicamente en la explicación del asistente.
No es necesario convertir una prueba en una demostración ofensiva para revisar ese límite. Se puede usar información ficticia y una acción deliberadamente fuera del alcance acordado, en un entorno autorizado. Lo importante es observar que el límite se conserva y entender qué evidencia queda cuando la acción no procede. La prueba no debería depender únicamente de que el asistente responda que se comportó correctamente.
Para seguir ese recorrido, una transacción de ensayo puede relacionarse con la solicitud que la inició y con la autorización que comprobó el sistema final. Si reconstruirla exige interpretar registros aislados sin un vínculo claro, conviene reconocer la limitación. Ampliar el número de herramientas conectadas antes de entender esa trazabilidad puede hacer más difícil explicar un resultado inesperado.
El asistente lee un documento que le pide ejecutar una acción ajena a la consulta. ¿Qué cambia?
- El documento se convierte en una autorización.
- La instrucción debe tratarse como contenido no autorizado; el sistema conserva sus límites.
- El asistente puede decidir por sí solo nuevos permisos.
Ver respuesta y explicación
B. En el escenario explicado, el documento aporta información, no autoridad para cambiar el alcance. A y C confunden contenido consultado con instrucciones autorizadas. La comprobación relevante ocurre también en las herramientas y el sistema final.
Pedir al agente que describa lo que hizo es útil para la experiencia, pero no reemplaza el registro de la operación aceptada. Una revisión puede relacionar solicitud, identidad y resultado con identificadores de prueba. Si esos pasos no pueden conectarse, hay una limitación de trazabilidad que conviene resolver antes de incorporar más herramientas. El diagrama es conceptual: no representa una instalación de Salt ni una auditoría de Acinsoft.
Poder reconstruir lo ocurrido
También hace falta saber quién recibe una alerta y qué puede hacer con ella. Una detección que no ofrece contexto puede añadir trabajo sin facilitar una decisión. Al comparar opciones, es útil observar tanto una operación permitida como otra fuera de alcance y revisar qué evidencia obtiene la persona encargada de atenderlas, no sólo lo que muestra una gráfica general.
Si el resultado es inesperado, alguien necesitará seguir el recorrido: qué se pidió, qué dato se leyó y qué sistema aceptó una operación. Una colección de registros que no permite relacionar esos pasos puede dificultar la investigación. La capacidad de explicar el recorrido no es un adorno para la auditoría; también sirve para corregir errores de diseño.
Una prueba defensiva puede usar documentos ficticios y acciones sin efectos externos. El objetivo es observar si una solicitud fuera de alcance se rechaza y queda identificada. No hace falta publicar instrucciones de explotación ni probar sobre sistemas ajenos. El recorrido que interesa documentar es qué se pidió, qué se intentó y qué aceptó realmente el sistema.
Cuando Acinsoft (servicio relacionado; abre en otra pestaña) perfila una integración, esta frontera puede revisarse como parte del diseño del software: dónde termina la interpretación y dónde comienzan las reglas de la operación. El alcance concreto se acuerda conociendo los sistemas y permisos existentes, sin asumir que un protocolo de conexión ofrece por sí mismo una garantía de seguridad.
Una conversación convincente no demuestra que una operación haya sido legítima. Para saberlo hace falta mirar el sistema que la recibió y la autorización que la sostenía. Mantener esa separación permite aprovechar un asistente sin convertir cada texto que lee en una orden.
