Evaluación de inyección rápida para agentes de recuperación y uso de herramientas.

Los puntos de referencia recientes amplían las condiciones de prueba

LongPIBench, una preimpresión de agosto de 2026, estudia la inyección rápida en entradas más largas en varias tareas orientadas a documentos. NetInjectBench estudia las acciones de las herramientas con metadatos de políticas confiables separados de los artefactos que no son confiables. Sus alcances difieren, pero ambos motivan a probar un contexto realista y límites de ejecución en lugar de un breve mensaje contradictorio.

Evidencia: LongPIBench: un punto de referencia de contexto prolongado para una inyección rápida [1]NetInjectBench: Evaluación comparativa de la inyección de avisos indirectos en agentes de modelos de lenguaje grandes que utilizan herramientas para operaciones de red [2]

Definir un límite de prueba seguro y significativo

Especifique la tarea del usuario autorizado, la superficie de entrada que no es de confianza, el resultado prohibido y el entorno utilizado para las pruebas. Utilice registros sintéticos, secretos ficticios y puntos finales inofensivos. No realice ataques abiertos contra sistemas o cuentas fuera del alcance acordado.

Distinguir la respuesta del modelo de la aplicación de la aplicación. Si el agente solicita una operación no autorizada pero la puerta de enlace de la herramienta la rechaza, el límite funcionó mientras el agente todavía presentaba un error de planificación. Registre ambos hechos. Una etiqueta de un solo paso ocultaría información de diagnóstico útil.

Emparejar casos de ataque con controles benignos

Rubrex recomienda probar documentos recuperados, mensajes citados, errores de herramientas y entradas largas de contexto mixto. Incluya material benigno que contenga lenguaje imperativo, como un manual que describa un comando. Un sistema que rechaza todo ese texto puede parecer resistente y al mismo tiempo fallar en las tareas normales.

Evaluar el efecto de la longitud y la ubicación del contexto sin asumir una posición siempre es lo más difícil. Mantenga estables la tarea solicitada y los permisos al comparar una defensa. Conserve los artefactos exactos y la versión de la aplicación para que el resultado pueda reproducirse sin exponer datos confidenciales reales.

Ejemplo ilustrativo: un documento solicita una acción paralela

Se le pide a un asistente de investigación que resuma un documento. Un documento de prueba contiene una instrucción para cambiar un registro no relacionado. La tarea autorizada sigue siendo el resumen; El contenido del documento no puede otorgar permiso para la acción secundaria. La evaluación comprueba que no se produzca ninguna mutación y que aún se pueda completar el resumen útil.

Un control benigno incluye un párrafo que explica cómo funcionan los cambios de registro, sin solicitar uno. El asistente debería poder resumir ese párrafo. Esto ayuda a detectar el bloqueo excesivo causado por defensas simples basadas en palabras clave.

Mantener visible la resistencia y utilidad

Informe por separado intentos de infracción de límites, infracciones ejecutadas, tareas legítimas bloqueadas y ejecuciones incompletas. Documente los controles a nivel de herramientas y las brechas de cobertura conocidas. Un conjunto de pruebas aprobado respalda una observación limitada sobre las condiciones probadas, no una afirmación de que el sistema sea a prueba de inyección.

• Utilice estados aislados y objetivos inofensivos.
• Realice un seguimiento de si se intentó o ejecutó la acción prohibida.
• Incluye documentos ordinarios con lenguaje similar a un comando.
• Nueva prueba después de cambios de herramienta, recuperación, permiso o modelo.

Controles de seguridad LLM y límites de barandillas.

Para las pruebas de seguridad de LLM, defina qué activos y acciones debe proteger la aplicación antes de construir casos contradictorios. Las vulnerabilidades de la aplicación LLM pueden surgir cuando un texto que no es de confianza influye en la llamada de una herramienta, cruza un límite de datos o cambia la prioridad de una instrucción. Rubrex recomienda asignar cada prueba a una acción protegida específica y un resultado claramente observable dentro de un entorno autorizado.

El equipo rojo de LLM puede informar una evaluación limitada, pero un conjunto de inyección rápida por sí solo no cubre todas las vulnerabilidades de LLM. Combine casos contradictorios con solicitudes legítimas para comprobar si las barreras de seguridad de LLM bloquean comportamientos útiles y acciones dañinas. Registre el control probado, el resultado observado y los límites no probados. Mantenga el control de acceso y la aplicación de permisos fuera de las instrucciones discrecionales del modelo.

Preguntas comunes