Localhost no es identidad: controles para las API locales del agente

Una API que escucha solo en la máquina local ha reducido su alcance de red. No ha autenticado el proceso de llamada, la página abierta en el navegador, la extensión instalada o el agente que se ejecuta dentro de un sandbox. loopback es una propiedad de enrutamiento; la identidad y la autoridad son propiedades de seguridad diferentes.

Este Evidence Brief compara dos disclosures recientes para derivar un contrato defensivo para API locales. No publica pasos ofensivos, no compara la seguridad general de los productos ni convierte una vulnerabilidad en un incidente. Estado: aprobado para publicación el 11 de septiembre de 2026 a las 09:00 BRT. Ningún control descrito aquí se declara implantado, probado u operativo en Trustyu Forge.

Alcance factual

El 8 de septiembre de 2026, OX Security publicó el disclosure de CVE-2026-82533 en DeepSeek Harness. Según la investigación, las versiones hasta 0.1.1-rc.2 expuso una API local sin autenticación y utilizó la información proporcionada por el cliente como señal de confianza. En la configuración predeterminada, un comando de agente ejecutado dentro de la caja de arena llegó a la interfaz local y cambió la política de la sesión en sí. OX informa corrección en la línea 0.1.2-alpha.1 y un retest el 30 de agosto.

O GHSA-96p9-rh4f-92cf describe otra composición en winml-cli: versiones anteriores a 0.4.0 exponer comandos a través de HTTP local sin autenticación y permitir fuentes web amplias. La condición previa registrada es la persona que mantiene activo el servicio y visita una página controlada por un tercero. El aviso indica 0.4.0 como versión corregida.

Los casos tienen distintas superficies, clasificaciones y condiciones previas. El denominador son dos divulgaciones, no una muestra de mercado. La mención de más de 215.000 estrellas en GitHub, presente en el texto OX, mide la atención al repositorio en ese corte; no mide instalaciones, usuarios, entornos vulnerables o víctimas.

No se encontró evidencia pública de explotación activa, número de víctimas, fuga confirmada o pérdida financiera en ambos casos hasta el 09/09/2026. Corregir la versión reduce el riesgo descrito; no prueba una auditoría completa o la ausencia de otros fallos.

Modelo de confianza

origem/processo ── autenticação ── autorização por capacidade ── efeito
       │                  │                    │                    │
       └──── contexto ────┴──── política ──────┴──── receipt ──────┘

La dirección local participa solo en el contexto de alcance. El servidor debe establecer las demás propiedades antes del efecto:

1. Origen efectivo: navegador, extensión, proceso, contenedor, sandbox u operador.
2. Identidad: principal verificable conectado a la sesión y el canal correctos.
3. Capacidad: acción tipada, objetivo delimitado y consecuencia conocida.
4. Política: límite máximo de autoridad independiente del input del cliente y del workspace.
5. Evidencia: decisión, versión, identidad, alcance y resultado reconstruibles.

Invariante 1: el transporte no autentica a la persona que llama

127.0.0.1, el socket local o el enlace de interfaz restringen las rutas posibles. No distinguen todos los procesos que comparten la máquina ni prueban que la llamada vino de la interfaz esperada. Host, Origin, el nombre del proceso y los campos enviados por el cliente son contextuales; si se usan solos, se convierten en declaraciones autocertificadas.

Un contrato defensivo requiere:

• identidad de sesión generada por el servidor y conectada al canal correcto;
• credencial efímera, restringida a la audiencia y no reutilizable por origen arbitrario;
• la verificación por pares y de transporte como señales adicionales, no la identidad completa;
• fallar de forma cerrada cuando identidad, canal o sesión no coinciden;
• rotación e invalidación cuando la interfaz se reinicia o la política cambia.

Pruebas negativas

• los encabezados que afirman ser de origen local no convierten a un cliente desconocido en uno de confianza;
• otra página, extensión o proceso no reutiliza la sesión autorizada;
• las llamadas internas a la caja de arena no heredan la identidad del operador;
• una sesión caducada o de otra instancia falla antes de tomar medidas.

Invariante 2 — CORS no reemplaza la autenticación

CORS indica al navegador qué orígenes pueden leer respuestas y, en algunos casos, enviar solicitudes. No autentica clientes fuera del navegador ni autoriza acciones privilegiadas. Una allowlist de orígenes puede reducir la superficie web; aun así debe combinarse con identidad, protección de sesión, validación de contenido y autorización en el servidor.

Pruebas negativas

• origen no permitido se rechaza sin reflejar arbitrariamente la cantidad recibida;
• origen permitido sin sesión válida también se rechaza;
• los clientes no sujetos a CORS siguen atravesando los mismos gates de identidad y autorización;
• el preflight, la redirección y los errores no revelan datos o capacidades adicionales.

Invariante 3 — la API de control no pertenece al mismo plano que el agente

Cuando el sandbox puede alcanzar la interfaz que modifica su propia política, datos y control comparten la misma frontera. El plano que ejecuta input no confiable no debería tener la capability de ampliar su propio confinamiento.

agent data plane ── pedido tipado ── policy mediator ── control plane
        │                                  │                  │
        └──────── sem credencial ──────────┘      autoridade humana/serviço

El mediador debe impedir que una identidad de ejecución:

• aumentar los permisos de la sesión en sí;
• deshabilitar aprobaciones o auditorías;
• leer conversaciones, secretos o sesiones de otro principal;
• emitir credenciales con una autoridad superior;
• cambiar la política que evaluará la siguiente acción.

La política efectiva debe permanecer source-bound y aplicarse en el punto del efecto. El harness puede separar identidad transitoria, capabilities y mediación de runtime, pero esta propiedad debe demostrarse mediante contrato y evidencia, no inferirse de la arquitectura declarada. [HARNESS31-C2]

Invariante 4 — la autorización acompaña a la consecuencia y al objetivo

Una ruta administrativa no debe considerarse protegida solo porque la interfaz gráfica normalmente pida confirmación. Toda forma de provocar el mismo efecto debe atravesar el mismo gate en el servidor.

Una solicitud privilegiada debería incluir:

{
  "principal": "ephemeral-session",
  "capability": "typed-action",
  "target": "bounded-resource",
  "policy_digest": "sha256:...",
  "approval_ref": "immutable-or-null",
  "expires_at": "rfc3339",
  "request_nonce": "single-use"
}

El ejemplo describe campos, no una implementación completa. El approval_ref necesita vincular la identidad humana o de servicio, la consecuencia, el objetivo y la validez. El nonce y la caducidad reducen la repetición; no reemplazan la autenticación del canal ni la verificación de políticas.

Pruebas negativas

• acción equivalente por CLI, UI y API recibe la misma decisión;
• la aprobación para la lectura no autoriza la ejecución o el cambio de política;
• un objetivo, capability o policy digest diferentes invalidan la aprobación;
• se rechazan el replay y el uso concurrente de la misma solicitud;
• la respuesta de error no incluye token, conversación, ruta confidencial o política integral.

Invariante 5 — sandbox incluye red y plano de control

Confinar solo el sistema de archivos deja otras autoridades disponibles. El modelo de amenazas debe decidir explícitamente sobre loopback, DNS, red externa, sockets, IPC, servicios de metadatos, proxies e interfaces de control en el host.

El diseño mínimo para una tarea no confiable es:

1. espacio de nombres o política de red dedicada cuando sea compatible;
2. egress default-deny, permitido por destino y finalidad;
3. interfaz de control inaccesible para el agente principal;
4. credenciales faltantes por defecto y, cuando sea indispensable, efímeras y task-scoped;
5. límites de tiempo, volumen, proceso y almacenamiento;
6. evidence receipt producido fuera de la autoridad del agente.

Una interfaz local puede seguir siendo necesaria para la experiencia de desarrollo. En este caso, el controlador debe sobrevivir al hecho de que el navegador, la extensión y el agente comparten el host.

Evidence Packet mínimo

{
  "service_version": "immutable-ref",
  "transport": "local-interface",
  "authenticated_principal": "opaque-id",
  "origin_context": "browser|process|sandbox|operator",
  "requested_capability": "typed-action",
  "effective_scope": "bounded-scope",
  "policy_digest": "sha256:...",
  "decision": "allowed|blocked|failed|inconclusive",
  "effect_receipt": "immutable-ref"
}

El receipt no debe conservar secretos, PII innecesaria, payload ofensivo ni el contenido completo de la sesión. Debe permitir reconstruir qué versión, principal, política, capability y resultado participaron en la decisión.

Gate de release

1. ¿La dirección local se trata solo como una restricción de rango?
2. ¿Cada cliente tiene una identidad verificable y vinculada a la sesión?
3. ¿El CORS está restringido y separado de la autenticación y autorización?
4. ¿El agente no puede alcanzar ni obtener credenciales para el plano de control que ampliaría su propio confinamiento?
5. ¿Las capacidades privilegiadas se escriben, delimitan y evalúan en el servidor?
6. ¿UI, CLI y API atraviesan el mismo gate según la consecuencia?
7. ¿El sandbox incluye interfaces de red, loopback, sockets y host en el modelo de amenazas?
8. ¿Los tokens son efímeros, audience-bound, no exportables e invalidados en el cambio de política?
9. ¿Las pruebas negativas cubren el navegador, la extensión, el proceso y el agente dentro de la caja de arena?
10. ¿El Paquete de Evidencia diferencia entre bloqueo, falla operativa, inconclusión y éxito?

Superar este gate demuestra solo el alcance probado. No demuestra seguridad total, ausencia de vulnerabilidades, preparación para producción ni operación continua.

Limitaciones y conflicto de intereses

• OX vende seguridad de aplicaciones y ha publicado la investigación que ha realizado. La ejecución comparativa y la repetición de pruebas fortalecen la divulgación, pero no son una corroboración independiente.
• El segundo caso está en un advisory público del proyecto Microsoft y tiene su propia clasificación. Su severidad baja no debe compararse directamente con el CVSS 9,4 asignado por OX al otro producto.
• Este informe generaliza las propiedades arquitectónicas a partir de dos casos; no estima la prevalencia.
• El texto omite puertos, comandos, cargas útiles, URL de explotación y secuencia ofensiva.
• Ningún caso autoriza la acusación de negligencia, intención, explotación activa o daño confirmado.
• No se indica que ningún control propuesto esté desplegado u operando en Trustyu Forge.

Fuentes directas

1. OX Research — CVE-2026-82533.
2. Microsoft/GitHub — GHSA-96p9-rh4f-92cf.
3. DeepSeek Harness — lanzamientos oficiales.
4. winml-cli — releases oficiales.

Nota editorial y de responsabilidad

Los hechos sobre productos y versiones se atribuyen a las fuentes anteriores. Los invariantes, el contrato y las pruebas negativas son análisis profesional del autor, no hechos universales ni alegaciones de controles ya operativos. Este contenido es informativo y no sustituye una evaluación técnica, jurídica o de seguridad. Trustyu y Tech Human trabajan comercialmente en temas relacionados. La investigación, la estructura y la redacción tuvieron asistencia de IA; Fernando Parreiras confirmó la revisión factual y autoral y la aprobación final el 9 de septiembre de 2026. No hubo revisión humana independiente adicional.