💬 NLP

Code as a Weapon: A Consensus-Labeled Prompt Bank for Measuring Coding-Model Compliance with Malicious-Code Requests

Este artículo presenta un banco de prompts con etiquetas de consenso que distingue entre código malicioso ejecutable y conocimiento de seguridad dañino para proporcionar una referencia fiable y estandarizada para medir si los modelos especializados en codificación cumplen con los estándares de rechazo más estrictos necesarios para prevenir la generación de armas funcionales.

Autores originales: Richard J. Young, Gregory D. Moody

Publicado 2026-05-28

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Richard J. Young, Gregory D. Moody

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

La Gran Idea: Texto vs. La Cosa Real

Imagina que le pides a un chatbot general: "¿Cómo hago una bomba?". Si responde, te da una receta. Todavía tienes que ir a la tienda, comprar los ingredientes y mezclarlos tú mismo. Es información peligrosa, pero son solo palabras.

Ahora, imagina que le haces la misma pregunta a una IA especializada en programación. Si responde, no solo te da una receta; te entrega una bomba completamente ensamblada y funcional lista para explotar en el momento en que presiones "ejecutar".

Los autores de este artículo argumentan que, dado que las IAs de programación pueden entregar "armas funcionales" (como virus o software espía) instantáneamente, deberían ser mucho más estrictas al decir "No" que los chatbots comunes. Pero actualmente, nadie tiene una buena manera de medir si realmente están diciendo "No" lo suficiente.

El Problema: Mezclar Manzanas con Naranjas

Para probar si estas IAs son seguras, los investigadores han estado utilizando listas de preguntas (prompts). Pero estas listas han sido desordenadas. Mezclan dos tipos muy diferentes de solicitudes peligrosas:

Solicitudes de "Arma": "Escríbeme un programa que robe contraseñas". (La IA te da el código).
Solicitudes de "Conocimiento": "Explica cómo funciona el robo de contraseñas". (La IA te da un ensayo).

Si mezclas estas dos y dices: "Esta IA rechazó el 50% de las solicitudes malas", no sabes si rechazó las armas o simplemente las explicaciones. Es como probar a un guardia de seguridad pidiéndole que detenga a un ladrón y que detenga a alguien que pide direcciones. Si el guardia detiene al ladrón pero deja pasar al que pide direcciones, no puedes decir si hace bien su trabajo solo mirando el número total de personas detenidas.

La Solución: Un Banco de Prompts con "Etiquetado por Consenso"

Los autores crearon una lista masiva, limpia y organizada de 6,675 preguntas peligrosas. Las dividieron en dos categorías claras:

La categoría "CÓDIGO": Preguntas que solicitan software ejecutable y peligroso (las "armas").
La categoría "CONOCIMIENTO": Preguntas que solicitan información o teorías dañinas (las "recetas").

Para asegurarse de que las preguntas se clasificaran correctamente, no pidieron la opinión de una sola persona. Utilizaron un panel de cinco jueces de IA diferentes (como un jurado). Cada juez examinó cada pregunta y votó: "¿Es esta una solicitud de arma?" o "¿Es esta una solicitud de conocimiento?".

El Veredicto: Si al menos 3 de cada 5 jueces estuvieron de acuerdo, la pregunta recibió una etiqueta final.
El Resultado: Terminaron con 4,748 solicitudes de "Arma" confirmadas y 1,923 solicitudes de "Conocimiento" confirmadas.

El "Jurado" y las Sorpresas

Los autores utilizaron cinco modelos de IA diferentes para actuar como jueces. Querían asegurarse de que la prueba fuera económica y accesible para que todos pudieran usarla, por lo que eligieron modelos gratuitos o de código abierto, en lugar de los costosos y de pago.

Durante este proceso, descubrieron dos cosas interesantes:

1. La Paradoja de "Demasiado Fácil"
Para algunas de las listas de preguntas (como la lista ASTRA), casi cada pregunta era obviamente una "Arma". Los jueces estuvieron de acuerdo el 99% de las veces.

La Metáfora: Imagina un examen de matemáticas donde cada pregunta es "¿Cuánto es 2+2?". Todos sacan 100%. No puedes medir realmente qué tan "inteligentes" son los estudiantes porque el examen era demasiado fácil.
El Hallazgo: En estadística, cuando todos están de acuerdo en todo, la puntuación habitual para el "acuerdo" (llamada Kappa) se rompe y parece un cero o un número negativo. Los autores tuvieron que inventar una forma especial de reportar esto: "Oye, todos estuvieron de acuerdo perfectamente, pero la puntuación matemática parece extraña porque el examen era demasiado fácil".

2. El Fallo del "Guardián"
Uno de los cinco jueces de IA (un modelo gratuito de OpenAI) comenzó a negarse a responder ninguna de las preguntas, incluso aquellas que se suponía debía juzgar. Seguía chocando contra un cartel de "Alto" de la empresa que lo aloja.

La Metáfora: Imagina un jurado donde un jurado sigue siendo expulsado del tribunal por hacer demasiadas preguntas.
La Solución: Dado que la regla era "3 de cada 5", los otros cuatro jueces aún podían decidir el veredicto. Los autores lo anotaron como una peculiaridad del mundo real: a veces las herramientas gratuitas que usas para probar la seguridad tienen sus propios filtros de seguridad que bloquean la prueba antes de que siquiera comience.

Por Qué Esto Importa

Este artículo no trata sobre probar una IA específica para ver si es segura hoy. En cambio, se trata de construir la regla que todos los demás pueden usar.

Antes de esto, los investigadores intentaban medir la seguridad con una regla rota que mezclaba "armas" y "recetas". Ahora, tienen una regla estandarizada y de alta calidad (el banco de prompts) que separa claramente ambos conceptos. Esto permite que cualquiera pruebe las IAs de programación y diga: "Bien, esta IA rechazó el 90% de las armas reales", lo cual es una verificación de seguridad mucho más significativa que antes.

Resumen

Objetivo: Crear una lista limpia de preguntas peligrosas para probar si las IAs de programación son seguras.
Método: Utilizar un "jurado" de 5 IAs para clasificar 6,675 preguntas en "Armas" (Código) y "Recetas" (Conocimiento).
Resultado: Una base de datos pública de 4,748 solicitudes de armas confirmadas y 1,923 solicitudes de conocimiento.
Insight Clave: No puedes medir la seguridad adecuadamente si mezclas "hacer una bomba" con "leer sobre bombas". Este artículo corrige esa confusión.

Resumen Técnico: Código como Arma: Un Banco de Prompts Etiquetado por Consenso para Medir el Cumplimiento de Modelos de Codificación con Solicitudes de Código Malicioso

Declaración del Problema

El artículo aborda una asimetría crítica en la seguridad de la IA: mientras que un modelo de lenguaje de propósito general que responde a una consulta dañina devuelve texto, un modelo especializado en codificación que cumple con la misma intención puede generar "armas" ejecutables (por ejemplo, registradores de teclas, goteros de ransomware, cargas útiles de explotación). Las pruebas de referencia actuales para medir la negativa a código malicioso no logran distinguir entre solicitudes de software ejecutable (CÓDIGO) y solicitudes de conocimiento de seguridad dañino (CONOCIMIENTO). Los corpus existentes mezclan estos tipos de solicitudes distintos, lo que hace que las estadísticas únicas de tasa de cumplimiento sean ininterpretables y evita las comparaciones directas entre corpus. Además, los esfuerzos anteriores etiquetados por consenso tenían un alcance limitado (cuatro corpus) y dependían de APIs comerciales de pago, lo que dificultaba la replicabilidad y la extensión rentable.

Metodología

Los autores presentan la v2 de un banco de prompts etiquetado por consenso, expandiendo el alcance de cuatro a ocho corpus aguas arriba y actualizando el panel de evaluación para utilizar modelos de peso abierto o de nivel gratuito con costo marginal cero.

1. Expansión del Corpus

El conjunto de datos se amplió de 3.133 prompts (v1) a 6.675 prompts mediante la integración de cuatro nuevos corpus publicados recientemente:

ASTRA: 1.995 prompts con solicitudes de texto a código de un solo turno decoradas con jailbreak.
Scam2Prompt (Innoc2Scam-bench): 1.377 prompts de elicitación indirecta que disfrazan la intención maliciosa como solicitudes inofensivas de desarrolladores.
JailbreakBench (subconjunto de codificación): 10 prompts dirigidos específicamente a la generación de código ejecutable.
RedCode: 160 prompts dirigidos a las trayectorias de agentes de intérprete de código.
Los corpus de la v1 (RMCBench, MalwareBench, CySecBench y AdvBench/harmful_behaviors) se reclasificaron bajo el nuevo panel para garantizar la continuidad.

2. Panel de Evaluadores y Protocolo

Se ensambló un panel de cinco evaluadores de cinco familias de proveedores distintas, seleccionados por su costo marginal cero en la API y su accesibilidad a través de OpenRouter y Ollama Cloud:

NVIDIA: Nemotron-3-Super (Propósito general)
Alibaba: Qwen3-Coder-Next (Especializado en codificación)
DeepSeek: DeepSeek-V4-Pro (Propósito general)
OpenAI: GPT-OSS-120B (Pesos abiertos, propósito general)
Zhipu AI: GLM-5.1 (Propósito general)

Protocolo de Clasificación:

Plantilla: Un esquema binario que distingue CÓDIGO (solicitudes de software/arma ejecutable) de CONOCIMIENTO (solicitudes de información/explicaciones basadas en texto). La plantilla es idéntica en bytes a la v1 para evitar desviaciones.
Regla de Consenso: Una regla de mayoría de 3 de 5. Un prompt se etiqueta como CÓDIGO o CONOCIMIENTO si al menos tres evaluadores están de acuerdo; de lo contrario, se etiqueta como AMBIGUO.
Métrica de Fiabilidad: $\kappa$ de Fleiss con un intervalo de confianza del 95% mediante bootstrap de 10.000 iteraciones, calculado en el subconjunto donde los cinco evaluadores devolvieron etiquetas válidas (6.552 prompts).

Contribuciones Clave

1. El Banco Etiquetado por Consenso Expandido

El artefacto publicado comprende:

4.748 prompts de CÓDIGO por consenso (una expansión de 3,1 $\times$ de la v1).
1.923 prompts de CONOCIMIENTO por consenso (una expansión de 5,0 $\times$ de la v1).
4 prompts AMBIGUOS (publicados con votos por evaluador para reumbralización aguas abajo).
El conjunto de datos se publica bajo una licencia OpenRAIL++ con restricciones específicas que prohíben el uso de los datos para entrenar sistemas de generación de software malicioso.

2. Hallazgos Metodológicos

El artículo documenta dos observaciones metodológicas significativas derivadas de la construcción de la v2:

La Paradoja de Alto Acuerdo y Bajo- $\kappa$ : En cuatro corpus sesgados por prevalencia (ASTRA, MalwareBench, RedCode, RMCBench), donde el consenso es >99% CÓDIGO, el $\kappa$ de Fleiss degenera a valores cercanos a cero o negativos a pesar del alto acuerdo observado ( $P_o$ ). Los autores atribuyen esto a la paradoja de Feinstein-Cicchetti, donde el acuerdo esperado por azar ( $P_e$ ) se aproxima a 1,0. En consecuencia, el artículo propone una convención de informe de doble estadística: reportar $\kappa$ para corpus mezclados por prevalencia y el acuerdo observado ( $P_o$ ) para corpus sesgados por prevalencia.
Negativas de Política de Contenido del Lado del Proveedor: Un evaluador (GPT-OSS-120B enrutado a través del proveedor OpenInference de OpenRouter) devolvió negativas deterministas HTTP 403 en el 1,84% de los prompts (123 en total), concentradas fuertemente en el corpus harmful_behaviors. El artículo identifica esto como una propiedad estructural de los proveedores de enrutamiento de nivel gratuito que aplican filtros de contenido antes de que el modelo procese el prompt. La regla de consenso de 3 de 5 absorbió con éxito estas negativas sin generar etiquetas AMBIGUAS, pero los autores lo señalan como un factor crítico para los investigadores que replican el panel.

3. Estabilidad entre Paneles

El panel de la v2 (peso abierto/nivel gratuito) se comparó con el panel de la v1 (APIs comerciales de pago) en los 3.133 prompts superpuestos. Los paneles alcanzaron un 94,45% de acuerdo en las etiquetas de consenso, con un $\kappa$ de Cohen de 0,952 ("casi perfecto") en el subconjunto binario-binario. Esto valida que el panel de costo cero sirve como un sustituto robusto del panel comercial en corpus compartidos.

Resultados

Fiabilidad General: En el subconjunto de panel completo (6.552 prompts), el $\kappa$ de Fleiss es 0,767 [IC 95%: 0,755, 0,777], situándose en la banda de acuerdo "sustancial" de la escala de Landis-Koch.
Fiabilidad por Corpus:
- Mezclados por Prevalencia: Scam2Prompt ( $\kappa=0,768$ ), CySecBench ( $\kappa=0,664$ ) y harmful_behaviors ( $\kappa=0,910$ ) muestran un acuerdo interpretable.
- Sesgados por Prevalencia: ASTRA, MalwareBench, RedCode y RMCBench muestran valores de $\kappa$ cercanos a cero o negativos debido a la degeneración de la distribución marginal, a pesar de que el acuerdo observado medio ( $P_o$ ) oscila entre 0,850 y 0,989.
Robustez del Evaluador: El análisis de exclusión de uno confirma que ningún evaluador individual domina el panel. Eliminar al evaluador más divergente (Nemotron-3-Super) en realidad aumentó el $\kappa$ a 0,832, confirmando que el desacuerdo introducido por este evaluador es trabajo de casos límite significativo y no ruido.
Niveles de Acuerdo: El 76,9% de los prompts alcanzó un acuerdo unánime de 5/5; el 95,0% alcanzó al menos un acuerdo de 4/5.

Significado y Afirmaciones

El artículo afirma proporcionar un sustrato estable de construcción para medir el cumplimiento de los modelos de codificación con solicitudes de código malicioso. Al desambiguar las solicitudes de software ejecutable de las solicitudes de conocimiento, el banco permite evaluaciones de seguridad más precisas que las pruebas de referencia anteriores de corpus mixtos.

Los autores posicionan modestamente el trabajo como una expansión y refinamiento metodológico de su publicación anterior de cuatro corpus [1], en lugar de una reevaluación del eje subyacente CÓDIGO-versus-CONOCIMIENTO. El significado principal radica en:

Escalabilidad y Replicabilidad: Demostrar que el etiquetado por consenso de alta fiabilidad puede lograrse utilizando modelos de peso abierto con costo marginal cero, eliminando las barreras financieras para los investigadores aguas abajo.
Estandarización: Establecer un protocolo para manejar corpus sesgados por prevalencia (informe de doble estadística) y documentar comportamientos de filtrado del lado del proveedor que afectan la disponibilidad de evaluadores de nivel gratuito.
Disponibilidad de Datos: Publicar un conjunto de datos significativamente más grande, con múltiples evaluadores y cuantificado en fiabilidad (6.675 prompts) para permitir comparaciones entre corpus que anteriormente no eran directamente interpretables.

El artículo declara explícitamente que no aborda la pregunta conductual de cómo responden los LLMs de codificación objetivo al banco v2, señalando que tales evaluaciones son el ámbito de trabajos aguas abajo separados.