Seguridad LLM y ataques de bots: un plan de prueba práctico

¿Qué tipo de ataque estás intentando detener?

La seguridad de LLM cubre la aplicación en torno al modelo, así como sus respuestas. La inyección rápida intenta hacer que la entrada que no es de confianza actúe como una instrucción. El abuso de bots utiliza la automatización para hacer un mal uso de un flujo de trabajo, potencialmente sin ningún aviso especial. La misma aplicación puede experimentar ambas cosas, pero un control que detecte lenguaje sospechoso no necesariamente detendrá solicitudes repetidas que parezcan legítimas.

El proyecto de amenazas automatizadas de OWASP incluye explícitamente el uso indebido de la funcionalidad válida de la aplicación. Su guía de riesgos LLM describe la inferencia excesiva como una ruta hacia la degradación del servicio y la pérdida económica. Utilice esas distinciones al clasificar un incidente: identifique el activo afectado y el resultado antes de decidir si el problema pertenece al comportamiento del modelo, al acceso a la cuenta, a la autorización o a la gestión de recursos.

Evidencia: Amenazas automatizadas de OWASP a aplicaciones web [1]LLM10:2025 Consumo ilimitado [2]

Escriba el límite de prueba antes de elegir un escáner.

Para el flujo de trabajo de evaluación propuesto por Rubrex, nombre la versión de la aplicación, el entorno, los puntos de entrada, la configuración del modelo, las fuentes de recuperación y las herramientas habilitadas. Identificar al propietario de cada recurso protegido. Escriba una oración para el resultado que nunca debe ocurrir, como que un usuario de soporte vea el ticket de otro inquilino o que un asistente de solo lectura envíe un mensaje.

Utilice un entorno de prueba con cuentas, documentos y destinos de herramientas sintéticos. Acuerde el límite de solicitud, el límite de gasto, la ventana de ejecución y las condiciones de detención con el propietario del sistema. Una cuota configurada baja puede ejercer la aplicación de la ley sin producir una inundación de tráfico. Mantenga un pequeño conjunto de tareas ordinarias del cliente como controles y registre el estado de los datos iniciales para poder restablecer las pruebas posteriores. Este es un plan de prueba de la aplicación, no un permiso para escanear servicios no relacionados.

Inyección de solicitud de prueba con permisos de herramientas reales

OWASP recomienda tratar las barreras de seguridad basadas en modelos como una capa junto con herramientas restringidas, validación y privilegios mínimos. Su guía excesiva de agencia coloca la autorización en los sistemas posteriores en lugar de dejar que el modelo decida si se permite una acción. Una instrucción sólida es un contexto útil, pero no puede sustituir una verificación de permiso.

En una prueba de soporte ilustrativa, una nota sintética recuperada le pide al asistente que cambie el propietario de un ticket aunque el usuario solo solicitó un resumen. Reemplace la herramienta de escritura en vivo con una implementación de prueba instrumentada. Registre si el modelo solicitó la escritura, si el límite de la herramienta lo permitió y si algún registro cambió. Un rechazo de modelo y una solicitud de herramienta rechazada son observaciones diferentes; preservar ambos.

Luego envíe una actualización legítima a través de una cuenta de prueba autorizada. Si la solución propuesta bloquea todas las actualizaciones, ha cambiado el contrato del producto en lugar de demostrar una protección utilizable. Para acciones que requieren aprobación, verifique que el objetivo y los argumentos aprobados sean los que se ejecutan y que cambiarlos requiera una nueva decisión.

Evidencia: Hoja de referencia para la prevención inmediata de inyecciones de LLM [3]LLM06:2025 Agencia excesiva [4]

Controle el abuso del bot antes de que genere costos de modelo o herramienta

La guía de consumo de recursos API de OWASP exige límites explícitos en la carga de trabajo y el gasto de terceros. Para una solicitud de LLM, evalúe el costo de una tarea completa, incluida la recuperación, las llamadas de modelo, las operaciones de herramientas y los reintentos. Limitar el número de solicitudes entrantes no es suficiente si una solicitud aceptada puede desencadenar un trabajo posterior ilimitado.

Rubrex recomienda documentar los límites de admisión y los límites de ejecución por separado. Al ingresar, asocie la solicitud con una cuenta o inquilino verificado y verifique su asignación. Durante la ejecución, se limita el tamaño de entrada, el presupuesto de salida, el trabajo simultáneo, los pasos de la herramienta y los reintentos. Aplique una fecha límite y defina qué significa la cancelación para el trabajo ya en cola o enviado a un proveedor. Utilice controles de gastos de proveedores cuando estén disponibles; una alerta de facturación por sí sola no detiene el consumo.

Como verificación aritmética ilustrativa, si una política de prueba permite tres llamadas de modelo por tarea y como máximo dos reintentos por llamada, el presupuesto debe permitir hasta nueve intentos de llamadas de modelo. Ésa no es una configuración de producción recomendada ni una estimación de costos. Es una forma de descubrir una discrepancia entre una cuota por solicitud y el trabajo que la aplicación realmente puede programar. Incluya los presupuestos de recuperación y de herramientas externas por separado.

Evidencia: API4:2023 Consumo de recursos sin restricciones [5]LLM10:2025 Consumo ilimitado [2]

Ejemplo ejecutado: carrera de cuota, corrección y nueva prueba

Ejecutamos el dispositivo Node.js sin modelo vinculado el 3 de octubre de 2026. Utiliza dos solicitudes simultáneas y una asignación de una unidad sintética. En el escenario vulnerable, una barrera obliga a ambas solicitudes a llegar a la misma pausa antes de que cualquiera de ellas continúe. No hay solicitudes salientes, registros de usuarios reales, llamadas de modelos pagas ni objetivos de sitios en vivo; las llamadas del proveedor se cuentan mediante un resguardo en la memoria.

En la versión vulnerable, cada solicitud verifica la asignación restante, espera la barrera y luego disminuye. Ambos pasan la verificación: se admiten dos, se realizan dos llamadas de resguardo y la asignación restante se convierte en -1. En la versión fija, la solicitud reserva su unidad de forma síncrona antes de la primera espera. Sólo se admite una solicitud y la otra se rechaza antes del talón; la asignación restante es cero.

Descargue el script y ejecute node cuota-race-demo.mjs con Node.js 22. Imprime cuatro escenarios; el registro de resultados contiene la salida observada, el tiempo de ejecución, la fecha y el hash SHA-256 del script exacto. El control de presupuesto cero rechaza ambas solicitudes; el control presupuestario suficiente admite ambas cosas. Esos controles verifican que la solución no sea simplemente bloquear cada solicitud.

Esto demuestra un defecto de programación y una solución de proceso único. No es una implementación de cuota distribuida: JavaScript sincrónico no puede serializar solicitudes entre trabajadores o réplicas. La admisión de producción necesita una reserva atómica en el almacenamiento compartido, idempotencia para los reintentos y conciliación explícita al finalizar o cancelar. Las solicitudes de modelos de costo variable también necesitan una reserva conservadora y un ajuste de uso final. Verifique esos comportamientos por separado; Este dispositivo no prueba el aislamiento de los inquilinos, la inyección rápida ni la infraestructura de producción de Rubrex.

• Descargue el dispositivo de carrera de cuota ejecutable (Node.js)
• Descargue la ejecución grabada y el hash del script (JSON)

Un pequeño conjunto de pruebas con condiciones de aprobación observables.

Los siguientes casos son una hoja de cálculo inicial propuesta, no resultados de un cliente de Rubrex ni un reclamo de cobertura completa. Reemplace los límites del ejemplo con el contrato escrito del producto. Registre el resultado esperado antes de ejecutar cada caso e incluya una referencia a la evidencia después.

Para las pruebas de cuota, configure una asignación deliberadamente pequeña en un entorno aislado y mantenga el volumen de solicitudes bajo. Para las pruebas de permisos, utilice dos inquilinos sintéticos y marcadores únicos no confidenciales. Para una prueba de reintento, simule una falla de reconocimiento después de que una herramienta falsa haya completado su operación. Estos dispositivos permiten inspeccionar los límites sin depender de una interrupción real, datos reales del cliente o un efecto secundario destructivo.

Mantener el acceso a los datos separado del juicio del modelo.

La guía de autorización a nivel de objeto de OWASP requiere verificaciones de los registros a los que accede una persona que llama autenticada. Aplique ese principio a las fuentes de datos que utiliza un asistente: un inicio de sesión válido no implica permiso para todos los documentos, respuestas almacenadas en caché o resultados de herramientas. La recuperación debe utilizar el alcance permitido de la persona que llama, y ​​las operaciones posteriores deben validar ese alcance nuevamente cuando acceden a objetos protegidos.

Para el ejemplo de dos inquilinos, coloque un marcador inofensivo diferente en el material de prueba de cada inquilino. Pruebe los documentos admitidos y las rutas de conversación de la aplicación, luego inspeccione el contenido devuelto y las decisiones de acceso asociadas. Repita después de que el otro inquilino haya llenado la caché. Registre qué caminos se probaron; una verificación de aislamiento exitosa no establece que todas las rutas de recuperación o almacenamiento estén aisladas.

Evidencia: API1:2023 Autorización de nivel de objeto roto [6]

Convierta un hallazgo en una solución que alguien pueda verificar

Un hallazgo útil explica qué se esperaba, qué ocurrió, por qué es importante y qué evidencia respalda la conclusión. Mantenga juntos la versión del sistema, el caso de prueba, la función de la cuenta, la configuración, el estado observado y el identificador de ejecución. Separe una sospecha generada por el modelo de una falla de límite reproducida. Describa el impacto utilizando los datos o acciones accesibles, en lugar de la redacción dramática del mensaje.

Para un hallazgo de cuota ilustrativo, el resultado esperado es el rechazo antes de llamar al proveedor. La falla observada podría ser una llamada de proveedor registrada después de que se agote la asignación de la cuenta. Un candidato fijo podría reservar el subsidio antes de la admisión. La nueva prueba debe incluir el caso original, concurrencia controlada en torno a la asignación final y una solicitud legítima con cuota suficiente. Registre si el resultado es fijo, parcialmente fijo, no reproducido o no probado; esas etiquetas no son intercambiables.

Medir la protección y la usabilidad del producto juntas

Para la lectura de la evaluación, informe violaciones de límites, solicitudes denegadas, tareas incompletas, bloqueos falsos en casos legítimos y uso de recursos. Indique el número y tipo de casos detrás de cada tarifa. Preservar las diferencias de configuración entre la línea base y la candidata. Una puntuación agregada puede ocultar la única acción no autorizada que la prueba pretendía evitar.

Para operaciones en curso, decida quién recibe una alerta y qué pueden cambiar. Una respuesta útil puede ser pausar una herramienta costosa, reducir la asignación de un inquilino o exigir temporalmente una revisión en un camino delicado. Mantenga controlado el acceso a los registros de investigación y evite copiar conversaciones completas de los clientes en un canal de alerta general. Después de un incidente confirmado, agregue un caso de regresión desinfectado y verifique el límite relevante nuevamente después de cambios de modelo, solicitud, recuperación o herramienta.

Preguntas comunes