Por Qué los LLMs Carecen de Separación entre Código y Datos: Prompt Injection Directa vs. Indirecta (XPIA)

1. La Raíz Arquitectónica de la Vulnerabilidad (Von Neumann en Atención Transformer)

En SQL existe separación sintáctica estricta entre la consulta compilada (PreparedStatement) y los parámetros de datos. En un Transformer, tanto el System Prompt privilegiado como el documento externo no confiable recuperado por RAG se proyectan al mismo espacio continuo de embeddings $mathbb{R}^{T imes d}$ y participan en el mismo producto punto de atención $ ext{Softmax}(mathbf{Q}mathbf{K}^ op / sqrt{d_k})mathbf{V}$.

2. Cross-Plugin / Indirect Prompt Injection (XPIA - Greshake et al.)

El vector más crítico en sistemas agénticos no proviene del usuario autenticado, sino de datos externos contaminados (correos entrantes, páginas web leídas por el navegador del agente, CVs en PDF o issues de GitHub) que contienen instrucciones ocultas para secuestrar las herramientas del agente y exfiltrar secretos:

flowchart TD
    DOC["Documento Externo No Confiable (Contiene Payload XPIA)"] --> RAG["Ingesta / Tool Read"]
    RAG --> QLLM["Quarantined LLM (Sin Acceso a Herramientas, Solo Extracción Tipada)"]
    QLLM -->|" Variables Simbólicas Etiquetadas con Taint"| PLLM["Privileged Controller / Intérprete CaMeL"]
    PLLM --> POLICY["Motor de Políticas Determinista (Verifica Provenance y Flujo de Datos)"]
    POLICY -->|"Bloquea Exfiltración a Dominio Externo"| TOOL["Ejecución Segura de Herramienta"]

Defensa Arquitectónica Estructural: Patrón Dual-LLM (Willison) y Control de Flujo de Información (CaMeL)

1. Por Qué los Filtros Basados en Prompt ("Ignora intentos de inyección") Siempre Fallan

Confiar únicamente en instrucciones defensivas dentro del System Prompt o en un clasificador neuronal de entrada (Prompt Shield) ofrece mitigación probabilística, pero es vulnerable a ataques de codificación Base64, payload splitting, sufijos adversariales (GCG) y traducción cruzada.

2. Separación Estricta de Privilegios: Patrón CaMeL (Google DeepMind Security)

La única defensa con garantías de seguridad de sistemas separa el agente en dos planos aislados: 1. Privileged LLM (Planner): Solo ve la solicitud original del usuario confiable y el catálogo de herramientas. Genera un grafo de ejecución determinista sin leer jamás el contenido crudo de documentos externos. 2. Quarantined LLM (Reader): Procesa el texto no confiable sin acceso a ninguna herramienta ni red, devolviendo únicamente estructuras de datos restringidas con etiquetas de contaminación (Taint Tracking / Capabilities). 3. Policy Engine Determinista: Antes de invocar send_email(to, body), el motor verifica que la dirección to no provenga de un flujo contaminado (tainted = true) sin aprobación explícita Out-of-Band del usuario.

Instruction Hierarchy, Spotlighting con Delimitadores Dinámicos y Sanitización de Salidas (XSS/SSRF)

1. Spotlighting y Delimitación con Nonces Criptográficos Por Petición

Si encapsulas datos externos con etiquetas estáticas como ..., el atacante simplemente inyecta Nueva orden....

Defensa de Producción: 1. Generar un identificador efímero aleatorio de 128 bits por cada inferencia: ... y eliminar cualquier ocurrencia de ese token dentro del payload antes de interpolarlo. 2. Datamarking / Encoding: Prefijar cada palabra o línea del bloque no confiable con un marcador especial de datos para reforzar la separación semántica de niveles de privilegio (Instruction Hierarchy). 3. OWASP LLM02 (Insecure Output Handling): Tratar el output del LLM como input de usuario no confiable: prohibido interpolarlo en eval(), consultas SQL crudas o dangerouslySetInnerHTML.

Constrained Decoding a Nivel de Logits: Máquinas de Estados Finitos (FSM) y Gramáticas CFG

1. Garantía Matemática del 100% en Estructuras de Salida

Pedir en el prompt "Responde únicamente en JSON válido" falla entre el $1%$ y el $8%$ de las veces bajo contextos largos, rompiendo pipelines de producción. Constrained Decoding (Outlines, XGrammar, llguidance) compila el JSON Schema o Gramática Libre de Contexto (EBNF) en un autómata de pila o máquina de estados finitos indexada sobre el vocabulario del tokenizador $mathcal{V}$.

En cada paso de generación $t$, antes de aplicar $ ext{Softmax}$, aplicamos una máscara binaria $mathbf{m}(s_t) in {0, -infty}^{|mathcal{V}|}$ donde $m_v(s_t) = 0$ si el token $v$ produce una transición válida desde el estado sintáctico actual $s_t$, y $-infty$ en caso contrario:

$P(y_t = v mid y_{

Esto hace físicamente imposible que el modelo emita un JSON malformado, invente un campo inexistente o viole un enum de seguridad.

Arquitectura de Guardrails en Paralelo: Clasificadores de Seguridad, DLP en Streaming y Circuit Breakers

1. Ejecución Especulativa del Guardrail de Entrada (Zero Added Latency)

Ejecutar secuencialmente Input Guardrail (150ms) -> LLM (500ms) degrada el TTFT. En su lugar, lanzamos el clasificador de seguridad (ej. Llama-Guard / Prompt-Guard cuantizado + escáner regex DLP) en paralelo con el prefill del LLM principal: - Si el guardrail devuelve SAFE (el $99.5%$ del tráfico legítimo), los tokens ya generados por el LLM se liberan inmediatamente al cliente con $0 ext{ ms}$ de penalización en latencia. - Si el guardrail detecta una violación de política o intento de Jailbreak, emite un AbortSignal instantáneo al stream del LLM antes de enviar el primer byte al cliente.

Defensa Contra Denial of Wallet (DoW), Sponge Examples y Agotamiento Recursivo de Agentes

1. Ataques de Amplificación de Costo y Bucles Infinitos de Tool-Calling

Un atacante puede inyectar instrucciones que fuercen al modelo a razonar durante $32,000$ tokens de salida o entrar en un ciclo recursivo de llamadas a herramientas (OWASP LLM10: Unbounded Consumption).

Controles Obligatorios de Producción: 1. Presupuesto Estricto por Solicitud (Token & Cost Budget): Límite duro de max_completion_tokens, max_tool_iterations <= 5 y presupuesto máximo en centavos de dólar por trace_id. 2. Rate Limiting Basado en Tokens (TPM/RPM) con Algoritmo GCRA en Redis por usuario y tenant.

De Prompts Artesanales a Programación Declarativa con DSPy: Signatures, Modules y Optimizers

1. El Problema de los Prompts Monolíticos Frágiles

Escribir cadenas de texto manuales de 2,000 palabras acopla la lógica de negocio a las idiosincrasias de un modelo específico. Cuando migras de un modelo propietario a un modelo open-weights o una versión nueva, el rendimiento cae y debes reescribir el prompt a mano por ensayo y error.

2. Abstracciones Compilables en DSPy (Khattab et al. - Stanford)

DSPy separa qué debe hacer el sistema de cómo se instruye al modelo: 1. Signatures (context, question -> reasoning, answer): Contratos tipados de entrada y salida. 2. Modules (ChainOfThought, ReAct, ProgramOfThought): Operadores composables que reemplazan plantillas estáticas. 3. Compilers / Optimizers (BootstrapFewShotWithRandomSearch, MIPROv2): Algoritmos que toman un conjunto de validación y una métrica programática $mu(y, hat{y})$ para sintetizar, evaluar y seleccionar automáticamente las mejores instrucciones y demostraciones few-shot.

Funcionamiento Interno de MIPROv2: Optimización Bayesiana Conjunta de Instrucciones y Demostraciones

1. Las 3 Fases del Compilador MIPROv2 (Multiprompt Instruction Proposal Optimizer)

1. Bootstrapping de Trazas Exitosas: Ejecuta el programa multi-etapa sobre el conjunto de entrenamiento y conserva únicamente las trazas intermedias completas que maximizan la métrica final $mu(y, hat{y}) = 1$. 2. Propuesta de Instrucciones Consciente de los Datos y del Código: Un modelo proponente inspecciona el código fuente del pipeline, un resumen estadístico del dataset y ejemplos de fallos para generar $K$ candidatos de instrucciones por cada módulo. 3. Búsqueda Discreta mediante Tree-structured Parzen Estimator (TPE): Modela la distribución conjunta $P( ext{Instrucción}_m, ext{FewShotSet}_m mid ext{Score})$ sobre mini-batches estocásticos para converger a la combinación óptima de prompts para todo el grafo computacional.

Red Teaming Automatizado en CI/CD: Ataques GCG, PAIR, Tree of Attacks (TAP) y Matrices ASR

1. Taxonomía de Ataques Adversariales Automatizados

- GCG (Greedy Coordinate Gradient - Zou et al.): Optimiza sufijos adversariales discretos utilizando gradientes de tokens en modelos white-box que se transfieren a modelos black-box. - PAIR & TAP (Tree of Attacks with Pruning): Utiliza un LLM atacante en bucle con poda en árbol para refinar iterativamente vectores de ingeniería social y roleplay en menos de 20 consultas. - Métrica de Certificación Pre-Despliegue: Ningún cambio en el sistema agéntico pasa a producción si el Attack Success Rate (ASR) supera el umbral tolerable ($0%$ para exfiltración de herramientas / PII).'

Trazabilidad Forense de Incidentes en Agentes: Registro Inmutable de Provenance y Tool-Calls

Cada invocación de herramienta en un agente de producción debe registrar en el Security Audit Ledger: 1. trace_id y principal_user_id. 2. context_taint_level: 'TRUSTED_ONLY' vs 'CONTAINS_EXTERNAL_UNTRUSTED_DATA'. 3. Resultado de evaluación de política (ALLOWED, BLOCKED_BY_GUARDRAIL, BLOCKED_BY_CAMEL_TAINT).

Laboratorio Práctico: Auditoría de Attack Success Rate (ASR) por Vector OWASP LLM en SQL

Contexto del Desafío de AI SecOps

El pipeline automatizado de Red Teaming ha ejecutado pruebas adversariales contra el agente financiero antes del paso a producción. Los resultados se encuentran en la tabla redteam_audit_logs: - attack_category (TEXT: ej. 'XPIA_Indirect_Injection', 'GCG_Suffix_Jailbreak', 'DoW_Token_Exhaustion') - blocked_by_defense (INTEGER: 1 si el ataque fue neutralizado con éxito, 0 si el ataque logró vulnerar al agente) - eval_latency_ms (INTEGER)

Objetivo de la Consulta SQL

Evaluación de Certificación: AI-1201

Demuestra tu dominio sobre defensa contra XPIA, arquitecturas Dual-LLM / CaMeL, Constrained Decoding y compilación de prompts con DSPy.