Protegiendo al Agente: Inyectando marcas de agua de alucinaciones en túneles localhost

Un agente alucinante no es solo un problema — es una responsabilidad empresarial. A medida que los agentes de IA autónomos acceden a bases de datos, sistemas de archivos y entornos de ejecución a través de túneles localhost y servidores Model Context Protocol (MCP), la pregunta de qué pasa cuando el modelo está equivocado ha pasado de ser una cuestión filosófica a una de seguridad operativa. Este artículo explora cómo implementar un Verification Proxy dentro de tu túnel: una verificación de cordura en tiempo real para cada token que produce tu modelo local, antes de que toque tu infraestructura.

---

El panorama de amenazas 2026: Por qué los túneles localhost están en la mira

La integración de agentes en entornos locales y empresariales se ha acelerado mucho más allá de lo que la mayoría de los equipos de seguridad anticiparon. Los desarrolladores usan rutinariamente herramientas como ngrok, Cloudflare Tunnels y integraciones directas MCP para conectar LLMs alojados o autoalojados — modelos como Llama 3, Mistral y Granite — con entornos de ejecución internos.

Las cifras ya no son solo teóricas. Según el Informe Estado de Seguridad de Agentes de IA 2026 de Gravitee (febrero de 2026), el 80.9% de los equipos técnicos han pasado de la fase de planificación a pruebas activas o despliegues en producción de agentes autónomos. Sin embargo, solo el 14.4% de esos agentes se lanzan con aprobación completa de seguridad y TI. Una encuesta de Cloud Security Alliance publicada en abril de 2026 encontró que el 82% de las organizaciones tienen agentes de IA desconocidos operando en su infraestructura de TI, y casi dos de cada tres han experimentado un incidente relacionado con un agente de IA en los últimos 12 meses.

El ecosistema MCP, que creció explosivamente a finales de 2025 y en 2026, se ha convertido en un punto crítico. Solo entre enero y febrero de 2026, investigadores de seguridad reportaron más de 30 CVEs dirigidos a servidores MCP, clientes e infraestructura. Un análisis de Endor Labs de 2,614 implementaciones MCP encontró que:

• 82% usan operaciones de archivos propensas a ataques de traversal de rutas
• 67% usan APIs relacionadas con inyección de código
• 34% usan APIs susceptibles a inyección de comandos

Estos no son riesgos teóricos. Cada categoría tiene al menos un CVE confirmado con un exploit público.

El problema de la implementación de referencia MCP

Quizá el hallazgo más alarmante fue que el servidor Git MCP de referencia de Anthropic incluía tres vulnerabilidades críticas (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145), divulgadas públicamente en enero de 2026. Estas fallas permitían traversal de rutas fuera del alcance del repositorio configurado, inyección de argumentos controlados por el usuario en GitPython y sobrescritura arbitraria de archivos — que, combinadas con el servidor Filesystem MCP, generaban ejecución remota de código mediante un .git/config malicioso. Si la implementación de referencia tiene estas fallas, cualquier servidor MCP de terceros construido con menos recursos debe ser considerado sospechoso desde el primer día.

En abril de 2026, investigadores de OX Security divulgaron una vulnerabilidad arquitectónica sistémica que afecta el SDK MCP de Anthropic en Python, TypeScript, Java y Rust — afectando paquetes de software con más de 150 millones de descargas combinadas y exponiendo a más de 200,000 servidores accesibles públicamente a posibles tomas de control mediante inyección de comandos a través de la interfaz STDIO.

Los límites de los controles de seguridad tradicionales

Firewalls, políticas DLP y RBAC asumen un flujo predecible y lineal: llega una solicitud, un sistema la procesa y se devuelve una respuesta. Los agentes de IA no siguen este modelo.

Un agente puede recibir una sola solicitud del usuario y posteriormente ejecutar una docena de acciones ocultas en múltiples sistemas antes de que un humano vea la salida. Los vectores de amenaza principales cuando un agente accede a un túnel localhost son:

Mal uso de herramientas vía alucinación. El modelo genera con confianza una llamada API sintácticamente válida pero catastrófica en contexto — una consulta DROP TABLE, un rm -rf, o una exportación masiva de datos — sin ser consciente de que ha cometido un error peligroso.

Inyección de prompt indirecta. El agente lee datos externos no confiables (un email, una página web, un issue en GitHub) que contienen instrucciones maliciosas incrustadas por un atacante. La investigación de Lakera AI de noviembre de 2026 demostró que fuentes de datos envenenadas pueden corromper la memoria a largo plazo de un agente, haciendo que desarrolle creencias falsas persistentes sobre políticas de seguridad — creencias que defiende activamente cuando se le cuestiona, creando un escenario de “agente durmiente”.

Incremento de privilegios. El Informe Estado de Seguridad de Agentes de IA 2026 encontró que el 45.6% de los equipos aún dependen de claves API compartidas para autenticación entre agentes, y solo el 21.9% trata a los agentes de IA como entidades independientes con identidad propia. Frecuentemente, los agentes operan como cuentas de servicio con credenciales amplias, saltándose el principio de menor privilegio.

Envenenamiento de la cadena de suministro. Investigadores de OX Security lograron envenenar nueve de once marketplaces MCP con un servidor malicioso de prueba de concepto. Una sola entrada MCP maliciosa podría ser instalada por miles de desarrolladores antes de ser detectada, otorgando al atacante ejecución arbitraria de comandos en cada máquina de los desarrolladores.

Asegurar flujos de trabajo autónomos requiere detener acciones maliciosas o alucinadas antes de que el entorno localhost las procese. No puedes confiar en que el modelo se autorregule. Necesitas una capa de validación independiente.

---

¿Qué es un Verification Proxy?

Un Verification Proxy es una capa de middleware ligera, de confianza cero, que se sitúa directamente entre tu motor de inferencia (el LLM que produce la salida) y tu entorno de ejecución de herramientas (el túnel localhost o servidor MCP).

En lugar de enrutar directamente la carga útil de llamada a herramientas del agente a tus APIs locales, el proxy intercepta la carga JSON y realiza una verificación rigurosa, matemática, de cordura. No solo pregunta “¿Es esto JSON válido?” o “¿Existe este endpoint?”. Hace una pregunta más profunda: “¿Qué confianza tenía el modelo cuando generó los tokens exactos que componen este comando?”

Al interceptar el tráfico, el Verification Proxy aplica una autorización dinámica y contextual. Asegura que operaciones de alto riesgo — eliminación de archivos, exportaciones masivas de datos, escrituras en bases de datos, reinicios del sistema — sean bloqueadas cuando el modelo muestra incertidumbre interna, creando un interruptor programable para workflows alucinados.

---

Entendiendo la marca de agua de confianza en LLM

Para que funcione el Verification Proxy, confiamos en un concepto llamado marcas de agua de confianza en LLM: la extracción de metadatos de probabilidad a nivel de token del motor de inferencia, que luego se vincula criptográficamente a la carga útil de llamada a la herramienta.

La matemática de la probabilidad de tokens

Cuando un LLM genera una respuesta, no piensa en frases completas. Predice el siguiente token basado en una distribución de probabilidad sobre su vocabulario completo. Estas probabilidades se exponen como log probabilities (logprobs) por servidores de inferencia modernos.

La intuición matemática es sencilla. La Probabilidad de Log de Secuencia (Seq-Logprob) es la suma de las probabilidades condicionales logarítmicas de cada token en la salida:

Seq-Logprob = Σ log P(yₖ | y<k, x, θ)   para k = 1 a L

Cuando un modelo genera un token sobre el cual está genuinamente inseguro, el logprob de ese token será significativamente menor, reduciendo el Seq-Logprob total para ese tramo. Investigaciones de Deepchecks y la librería UQLM de CVS Health confirman que puntajes bajos de Seq-Logprob correlacionan fuertemente con contenido alucinatorio, sirviendo como una señal de advertencia para salidas que puedan contener información incorrecta o fabricada.

Alta entropía (una distribución de probabilidad plana y dispersa entre muchos tokens posibles) es un indicador matemático principal de una alucinación. Cuando el modelo está confiado, un token domina la distribución. Cuando está adivinando, la distribución se aplana.

Es importante notar una limitación real: investigaciones publicadas en enero de 2026 en arXiv advierten que la entropía a nivel de token tradicional no detecta alucinaciones de alta confianza, donde la distribución del modelo está fuertemente concentrada en una respuesta incorrecta. Para estos casos, el Error de Calibración Esperada (ECE) — que mide la brecha sistemática entre la confianza declarada por el modelo y su precisión real — proporciona una señal complementaria crítica. Un Verification Proxy robusto debe incorporar ambas.

Detección de alucinaciones lista para producción

Esto ya no es solo teórico. Varias aproximaciones están disponibles a velocidad de producción:

Probabilidad de token en caja blanca (vLLM, Ollama, TGI). Los servidores de inferencia modernos exponen logprobs junto con el texto generado. La librería UQLM de CVS Health los estandariza en una puntuación de confianza [0,1]. La sobrecarga es insignificante — estos puntajes solo requieren las probabilidades de tokens de la generación original, sin llamadas adicionales al modelo.

HaluGate (Blog vLLM, diciembre 2025). Un pipeline de detección de alucinaciones a nivel de token, en dos etapas, construido sobre la infraestructura de inferencia de vLLM. La primera etapa clasifica si una consulta requiere verificación factual (saltando detección costosa para código o tareas creativas). La segunda aplica verificación NLI a nivel de token. La sobrecarga total es de 76–162ms — insignificante comparado con los tiempos típicos de generación de LLM de 5–30 segundos, haciéndolo práctico para solicitudes síncronas.

Observabilidad LLM de Datadog. El producto de detección de alucinaciones en producción de Datadog usa métodos de caja negra (sin acceso a internos del modelo) para soportar toda la gama de proveedores, incluyendo APIs cerradas. Monitorea distribuciones de confianza en producción y alerta sobre cambios que puedan indicar deriva del modelo o decaimiento del prompt.

Para 2025, el campo ha cambiado de perseguir cero alucinaciones a gestionar la incertidumbre de manera medible y predecible. Gartner proyecta que más del 40% de los proyectos de IA agentica serán cancelados para finales de 2027 por preocupaciones de fiabilidad — haciendo que la instrumentación de confianza no sea solo una característica de seguridad, sino también de continuidad del negocio.

Inyectando la marca de agua

La marca de agua de confianza en el contexto de la seguridad agentica lleva la extracción de logprob un paso más allá:

1. El motor de inferencia genera una carga útil de llamada a la herramienta (por ejemplo, {"command": "rm -rf /temp"}).
2. El motor calcula la media del logprob y la varianza de entropía para los tokens específicos en los campos sensibles de esa carga.
3. El motor genera un HMAC criptográfico de la carga concatenada con la puntuación de confianza.
4. La carga firmada y combinada se envía al Verification Proxy.

Firmar criptográficamente la puntuación de confianza en la capa de inferencia evita que un prompt de inyección sofisticado falsifique una etiqueta de metadatos “alta confianza” en una carga en la que el modelo realmente estaba inseguro.

---

Arquitectura de la defensa: implementación paso a paso

Fase 1: Mapeo de Control de Acceso Basado en Políticas (PBAC)

Categoriza las herramientas disponibles en tu túnel localhost por severidad de riesgo. No todas las herramientas requieren el mismo nivel de escrutinio.

Nivel de Riesgo	Herramientas de ejemplo	Umbral mínimo de confianza
Bajo (Solo lectura)	get_weather, read_log_file, search_docs	> 70%
Medio (Alteración de estado)	update_ticket, send_email, create_record	> 85%
Alto (Destructivo / Sistema)	execute_sql_write, delete_user, run_bash_script	> 95%
Crítico (Irreversible)	drop_table, rm -rf, bulk_export	> 98% + revisión humana

Este modelo escalonado refleja la guía OWASP Agentic Top 10 para el alcance de confianza en herramientas, que recomienda explícitamente que los permisos deben limitarse al mínimo necesario para la acción específica.

Fase 2: La lógica de interceptación del proxy

Cuando el LLM decide usar una herramienta, genera una carga que es interceptada por el proxy. El proxy realiza las siguientes verificaciones en milisegundos:

Verificación de firma. Valida la marca de agua HMAC para asegurar que la carga y los logprobs fueron realmente producidos por el motor de inferencia aprobado y no han sido manipulados en tránsito.

Análisis de intención. Identifica qué herramienta local intenta llamar el agente y la mapea al nivel PBAC correspondiente.

Evaluación de umbral. Compara la puntuación de confianza marcada con la umbral PBAC para esa herramienta. Una llamada write_database con 82% de confianza que llega con un umbral del 95% — se bloquea.

Heurísticas contextuales. Evalúa la carga en busca de firmas conocidas de inyección de prompt: codificación base64 anómala, encadenamiento de comandos con operadores shell, estructuras de argumentos inesperadas, o valores de parámetros que coinciden con patrones de inyección conocidos (por ejemplo, secuencias de traversal como ../..).

Fase 3: El interruptor de apagado y la degradación controlada

Si el proxy bloquea una ejecución, no interrumpe el flujo de trabajo. En su lugar, devuelve un error estructurado al LLM:

{
  "status": "blocked",
  "agent_feedback": "Ejecución bloqueada: la puntuación de confianza 0.82 está por debajo del umbral requerido de 0.95 para write_database. Solicite aprobación humana o use primero un paso de verificación de solo lectura."
}

Esto obliga al agente a volver a solicitar aclaraciones al usuario humano, recopilar más contexto o usar una herramienta de menor riesgo para confirmar su intención antes de intentar la acción destructiva nuevamente.

Código conceptual: El Verification Proxy en Python

La siguiente conceptualización con FastAPI ilustra cómo funciona como un guardián para tu túnel localhost.

import hashlib
import hmac
import json
from fastapi import FastAPI, HTTPException, Request

app = FastAPI()

# Clave secreta compartida SOLO entre el motor de inferencia y el proxy
SECRET_KEY = b"enterprise_secure_agent_key_2026"

# Umbrales de confianza por nivel de riesgo
TOOL_THRESHOLDS = {
    "read_database":   0.70,
    "update_ticket":   0.85,
    "send_email":      0.85,
    "write_database":  0.95,
    "execute_bash":    0.97,
    "delete_record":   0.98,
}

def verify_watermark(payload: str, confidence: float, signature: str) -> bool:
    """Valida que la puntuación de confianza fue firmada criptográficamente por el LLM."""
    message = f"{payload}:{confidence}".encode("utf-8")
    expected_sig = hmac.new(SECRET_KEY, message, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected_sig, signature)

@app.post("/proxy/execute")
async def execute_tool(request: Request):
    data = await request.json()

    tool_name          = data.get("tool_name")
    payload            = data.get("payload")
    confidence_score   = data.get("confidence_score")
    cryptographic_sig  = data.get("signature")

    # 1. Verificar que la marca de agua no ha sido manipulada
    if not verify_watermark(json.dumps(payload), confidence_score, cryptographic_sig):
        raise HTTPException(
            status_code=403,
            detail="Verificación de integridad de la marca de agua fallida. Ejecución detenida."
        )

    # 2. Aplicar umbrales PBAC
    required_confidence = TOOL_THRESHOLDS.get(tool_name, 0.99)  # Seguridad máxima por defecto

    if confidence_score < required_confidence:
        print(
            f"[SEGURIDAD] Bloqueado: {tool_name} requiere {required_confidence:.0%} "
            f"de confianza. El agente proporcionó {confidence_score:.0%}."
        )
        return {
            "status": "blocked",
            "agent_feedback": (
                f"La puntuación de confianza {confidence_score:.0%} está por debajo del umbral "
                f"requerido de {required_confidence:.0%} para {tool_name}. "
                "Solicite aprobación humana o recopile más contexto antes de reintentar."
            ),
        }

    # 3. Enviar a través del túnel localhost
    print(f"[TUNNEL] Ejecutando {tool_name} con confianza validada {confidence_score:.0%}")
    # execute_in_local_environment(tool_name, payload)

    return {"status": "success", "data": "Herramienta ejecutada de forma segura."}

Esta arquitectura trata al LLM no como un usuario interno confiable, sino como una entidad externa potencialmente comprometida que requiere verificación continua — el principio fundamental de confianza cero.

---

Asegurando flujos multi-agente: el problema en cascada

La necesidad de un Verification Proxy escala exponencialmente en sistemas multi-agente. En una arquitectura típica de 2026, podrías tener un Agente Investigador navegando por la web, un Agente Programador generando scripts basados en la investigación, y un Agente DevOps ejecutando esos scripts en el túnel localhost.

El análisis de Stellar Cyber de marzo de 2026 sobre las principales amenazas de IA agentica identifica ataques en cascada de alucinaciones como una de las clases de amenaza más peligrosas emergentes: si un solo agente de recuperación de datos se ve comprometido o alucina, alimenta datos corruptos a los agentes descendentes. Estos, confiando en la entrada, amplifican el error en todo el sistema a velocidad de máquina. A diferencia de fallos en pipelines tradicionales, la cadena de razonamiento es opaca — ves la mala decisión final, pero no puedes rastrear fácilmente qué agente introdujo la corrupción.

Propagando metadatos de confianza a través del pipeline

En un flujo de trabajo multi-agente seguro, las marcas de agua de confianza deben viajar con los datos, no solo con la llamada final a la herramienta.

Cuando el Agente Investigador escribe hallazgos en la memoria compartida del agente, sus metadatos de confianza se añaden a ese bloque de datos. Cuando el Agente DevOps formula su llamada final a la herramienta en el túnel localhost, el Verification Proxy calcula una puntuación de confianza compuesta — un promedio ponderado de los metadatos de confianza de todos los agentes upstream que contribuyeron a esa decisión.

Si algún agente upstream produjo una salida de baja confianza, el proxy penaliza la solicitud de ejecución downstream, incluso si el agente final generó una secuencia de tokens de alta confianza. Esto crea un sistema inmunológico sistémico para la pipeline autónoma: el movimiento lateral de un agente upstream comprometido se detiene en el perímetro de la red en lugar de propagarse silenciosamente a la ejecución.

---

La brecha en gobernanza de identidades

Una realización fundamental que impulsa la seguridad de agentes de IA en 2026 es que los agentes son identidades — y la mayoría de los sistemas IAM no están preparados para ellos.

El Informe Estado de Seguridad de Agentes de IA 2026 encontró que el 27.2% de los equipos técnicos aún dependen de lógica personalizada codificada para gestionar la autorización de agentes, y solo el 21.9% trata a los agentes como entidades independientes con identidad propia. Cuando los agentes comparten credenciales o usan cuentas de servicio permanentes, la responsabilidad colapsa. Si un agente crea y asigna tareas a otro agente — una capacidad que tienen el 25.5% de los agentes desplegados — la cadena de mando se vuelve imposible de auditar en sistemas IAM tradicionales.

El Verification Proxy cierra esta brecha aplicando provisión Just-In-Time (JIT) en el límite de ejecución de herramientas. Las decisiones de acceso se toman en tiempo de ejecución, adaptando permisos en base a:

• La identidad del usuario humano que inició el prompt original
• La clasificación de sensibilidad de los datos accedidos
• La certeza matemática de la intención generada por el agente (la marca de agua de confianza)
• La línea de confianza de las contribuciones de agentes upstream

Los permisos no se congelan en el momento de la provisión. Evolucionan con el flujo de trabajo — una distinción crítica en entornos donde una sola pipeline de agentes puede tocar una docena de sistemas con diferentes perfiles de riesgo.

---

Limitaciones conocidas y controles complementarios

La marca de agua de confianza es poderosa, pero no es una bala de plata. Hay dos modos de fallo que vale la pena señalar claramente:

Alucinaciones de alta confianza. Como se señala en la investigación de arXiv de enero de 2026, la entropía a nivel de token falla cuando un modelo está sistemáticamente sobreconfiante en una respuesta incorrecta. Las verificaciones de calibración basadas en ECE y la verificación secundaria con el IA como juez son complementos necesarios en dominios de alta responsabilidad.

Proveedores de modelos caja negra. Las APIs de código cerrado (GPT-4o, Claude Sonnet vía la API de Anthropic) no siempre exponen logprobs para todos los tipos de salida, especialmente JSON estructurado de llamadas a herramientas. En estos casos, los métodos de detección caja negra — muestreo de consistencia (generar la misma salida varias veces y medir la varianza), puntuación de fidelidad basada en NLI, y monitoreo de comportamiento estilo Datadog — sirven como capa de confianza en lugar del acceso directo a logprobs.

Combinar estas capas — watermarking de logprobs en caja blanca cuando esté disponible, muestreo de consistencia en caja negra para modelos cerrados, y monitoreo de comportamiento en tiempo de ejecución como respaldo — ofrece una defensa en profundidad contra todo el espectro de riesgos de alucinación.

---

Recomendaciones prácticas

Antes de desplegar agentes en cualquier túnel localhost o servidor MCP, las organizaciones deben actuar sobre lo siguiente:

Auditar tu superficie de ataque MCP inmediatamente. Dado que Endor Labs encontró riesgos de traversal de rutas en el 82% de las implementaciones MCP analizadas y se reportaron más de 30 CVEs en los primeros 60 días de 2026, cualquier servidor MCP debe considerarse código no confiable. Solo instala servidores de fuentes verificadas y auditadas. Aísla todos los servicios habilitados para MCP y restringe privilegios de sistema de archivos y shell al mínimo necesario.

Instrumenta tu capa de inferencia para logprobs. Si ejecutas modelos autoalojados con vLLM, Ollama o TGI, habilita la salida de logprobs y comienza a construir la canalización de datos para la puntuación de confianza. Si usas una API hospedada, evalúa si el proveedor expone logprobs para salidas estructuradas y planifica en consecuencia.

Implementa un mapeo escalonado PBAC antes de que tus agentes entren en producción. Asigna cada herramienta en tu entorno de ejecución a un nivel de riesgo y define el umbral mínimo de confianza aceptable antes de autorizar la ejecución. Una herramienta destructiva o irreversible sin control de confianza es una responsabilidad incontrolada.

Registra todo en el límite del proxy. Cada invocación de herramienta — bloqueada o permitida — debe generar una entrada de log estructurada que incluya el nombre de la herramienta, la puntuación de confianza, el umbral PBAC, el resultado de la firma criptográfica y la identidad del iniciador humano. Esta trazabilidad es tu base forense en caso de incidente.

Trata a los agentes como identidades externas, no como insiders confiables. Cambia de claves API compartidas y cuentas de servicio estáticas. Aplica provisión JIT, limita los permisos al mínimo necesario y revócalos inmediatamente tras completar el flujo de trabajo.

---

Conclusión

El modelo de “fire and forget” de integración de LLM ha terminado. Los riesgos de comandos de infraestructura alucinatorios, deriva silenciosa de workflows y ataques sofisticados de prompt en múltiples turnos son demasiado severos y están bien documentados en 2026 para considerarlos casos aislados.

Inyectar marcas de agua de confianza en los payloads de llamada a herramientas y hacer cumplir esas marcas mediante un Verification Proxy representa un enfoque fundamentado, matemáticamente sólido, para la seguridad agentica. Transforma tu postura de seguridad de reactiva a proactiva — de “detecta la brecha después de que sucede” a “bloquea la acción incierta antes de que se ejecute”.

Los agentes autónomos están aquí. Ya están en producción. Y cometen errores a velocidad de máquina. El Verification Proxy es cómo aseguras que esos errores permanezcan contenidos.

---

Referencias y lecturas adicionales: State of AI Agent Security 2026 (Gravitee, febrero 2026) · OX Security MCP Supply Chain Advisory (abril 2026) · Endor Labs MCP Vulnerability Analysis (enero 2026) · HaluGate: Token-Level Hallucination Detection (Blog vLLM, diciembre 2025) · Detección y mitigación de alucinaciones en LLMs (arXiv:2601.09929, enero 2026) · UQLM: Cuantificación de incertidumbre para modelos de lenguaje (CVS Health, octubre 2025) · Stellar Cyber: Principales amenazas de seguridad IA agentica (marzo 2026) · Seguridad MCP 2026: 30 CVEs en 60 días (PipeLab, abril 2026) · Cloud Security Alliance Encuesta de Seguridad de Agentes de IA (abril 2026)