Inyectando lógica personalizada en el borde con WebAssembly (Wasm) proxies

Deja de desplegar middleware pesado solo para analizar un token o reescribir una carga útil. Compilar tu lógica de enrutamiento en WebAssembly te permite ejecutar funciones proxy personalizadas en el borde de la red con una latencia casi nula — y en 2026, el ecosistema finalmente ha madurado lo suficiente para hacerlo en producción.

En arquitecturas modernas nativas en la nube, el borde de la red se ha transformado de un simple punto de entrada en un límite inteligente y altamente programable. Durante años, los ingenieros de plataformas enfrentaron un dilema arquitectónico persistente: ¿dónde debe residir la lógica de negocio personalizada cuando una solicitud llega a la puerta de enlace API o al proxy inverso? Históricamente, si necesitabas implementar validación propietaria de tokens, eliminar PII de una carga útil o ejecutar enrutamiento complejo basado en contexto, tenías dos opciones poco favorables. Podías bifurcar el código fuente de tu proxy — generalmente escrito en C++ o Go — y mantener una compilación personalizada, o desplegar un microservicio middleware separado y forzar al proxy a hacer un salto de red antes de enrutar el tráfico a su destino final.

Ambos enfoques conllevan costos significativos. Bifurcar un proyecto como Envoy genera una enorme deuda técnica y pesadillas de actualización. Desplegar middleware externo introduce latencia de red, aumenta la superficie de fallo y complica la huella de despliegue.

Ingresa WebAssembly (Wasm). Al compilar lógica personalizada en WebAssembly e insertarla directamente en proxies en el borde, los ingenieros de plataformas están cambiando cómo se maneja el tráfico en el ingreso. Este paradigma — a menudo llamado ** proxies en el borde potenciados por Wasm** — permite a los desarrolladores ejecutar código seguro y de velocidad casi nativa directamente dentro del espacio de proceso del proxy sin tocar la base de código principal del proxy.

---

¿Qué son los proxies en el borde potenciados por Wasm?

WebAssembly es un formato de instrucciones binario para una máquina virtual basada en pila, originalmente diseñado para aplicaciones de alto rendimiento en navegadores web. Es un objetivo de compilación portátil para Rust, C++, Go, AssemblyScript y otros lenguajes. Cuando se aplica al networking del lado del servidor, Wasm actúa como un sistema de plugins universal para computación en el borde.

En lugar de mantener microservicios separados para modificar encabezados, validar tokens o transformar datos a medida que pasan por un proxy, los desarrolladores escriben su lógica en un lenguaje de su elección y la compilan a un binario .wasm. Ese binario se inyecta directamente en un proxy inverso moderno como Envoy. Debido a que Wasm se ejecuta en una sandbox segura y aislada, el proxy puede ejecutar el código personalizado de forma segura. Si el plugin Wasm se bloquea, el propio proxy permanece intacto — la sandbox se destruye, se devuelve un error 500 para esa solicitud específica, y el proxy continúa procesando sus conexiones sin interrupciones.

Esto convierte al proxy inverso en una puerta de enlace API altamente extensible basada en Wasm, capaz de ejecutar tareas personalizadas y computacionalmente intensivas en el momento exacto en que un paquete llega al borde de la red.

La ABI Proxy-Wasm

El catalizador para esta arquitectura es la Interfaz Binaria de Aplicación Proxy-Wasm (ABI). Antes de Proxy-Wasm, escribir un plugin para un proxy significaba escribir código estrechamente acoplado a la API interna de ese proxy específico. Proxy-Wasm define una interfaz estandarizada entre proxies y máquinas virtuales Wasm: cómo un proxy pasa encabezados HTTP, cargas útiles del cuerpo y metadatos de conexión al módulo Wasm, y cómo el módulo Wasm instruye al proxy para actuar — bloquear esta solicitud, agregar este encabezado, enrutar a este upstream.

La versión recomendada y ampliamente implementada de la ABI es v0.2.1. Esto es lo que Envoy, Istio, MOSN, Higress y API7 implementan hoy en día. Un plugin Proxy-Wasm escrito contra v0.2.1 puede teóricamente ejecutarse en cualquier proxy que implemente la misma ABI.

Es importante ser honestos sobre la historia de la especificación: la ABI Proxy-Wasm estuvo en uso activo por Envoy e Istio durante años sin documentación formal adecuada. A mediados de 2023, los mantenedores del repositorio de la especificación lo reconocieron públicamente en GitHub y se comprometieron a documentar correctamente la ABI v0.2.1. Ese esfuerzo de documentación ha continuado en 2024 y 2025, con el repositorio recibiendo commits activos hasta octubre de 2025. La ABI en sí misma es estable en la práctica — la superficie no ha cambiado materialmente para despliegues en producción — pero los desarrolladores que actualizan SDKs o runtimes en versiones principales de Envoy deben probar contra errores de la clase WASM missing Proxy-Wasm ABI version, que surgen cuando la versión ABI compilada no coincide con lo que espera el proxy host.

---

¿Por qué Wasm está reemplazando al middleware tradicional?

1. Erradicación de la latencia de red

En una arquitectura de microservicios tradicional, una solicitud entrante activa una llamada HTTP o gRPC fuera del proceso. El proxy recibe la solicitud del usuario, pausa, envía encabezados a un servicio “AuthZ”, espera una respuesta y entonces enruta el tráfico. Este salto de red interno se agrava en altas tasas de transferencia.

Con extensiones Envoy Wasm, la lógica vive en la memoria del proxy. La documentación de Envoy confirma que las extensiones pueden entregarse y recargarse en tiempo de ejecución directamente desde el plano de control, sin actualizar ni redeployar el binario del proxy. La ejecución de la lógica personalizada ocurre con una latencia casi nula: el proxy mapea los datos de la solicitud en la memoria de la VM Wasm, la validación se ejecuta, y el proxy enruta inmediatamente la solicitud.

2. Lenguaje agnóstico y velocidad de desarrollo

Los equipos de plataforma ya no necesitan expertos en C++ para escribir filtros de Envoy. Un ingeniero de seguridad puede escribir un algoritmo de limitación de tasa en Rust, un equipo de identidad puede crear un analizador JWT en Go (a través de TinyGo), y un equipo de plataforma puede escribir lógica de manipulación de encabezados en AssemblyScript.

La cadena de herramientas principal para el desarrollo Proxy-Wasm hoy:

• Rust — proxy-wasm-rust-sdk con el objetivo wasm32-wasip1 (antes wasm32-wasi; renombrado en el compilador Rust en marzo de 2024). Es la vía más madura.
• Go — proxy-wasm-go-sdk, que requiere TinyGo en lugar de Go estándar. El SDK de Go lleva el nombre del lenguaje pero depende de TinyGo debido al soporte incompleto de WASI en Go estándar para este caso de uso.
• C++ — a través del SDK WASI basado en Clang/LLVM.

Una vez compilados a Wasm, los módulos se distribuyen como imágenes de contenedor. Usando registros compatibles con OCI, los equipos pueden subir y descargar módulos Wasm e integrarlos en sus pipelines CI/CD existentes.

3. Aislamiento de fallos y seguridad

Un módulo Wasm no puede acceder al sistema de archivos del sistema operativo host, a primitivas de red o a memoria fuera de su espacio asignado. Si un plugin se bloquea o filtra memoria, la VM termina el sandbox. La especificación Proxy-Wasm también indica que el host debe rastrear las tasas de fallos y limitar la creación de plugins que se bloquean repetidamente, evitando que un plugin roto cause una denegación de servicio consumiendo recursos en un ciclo de fallos.

Esto hace que desplegar lógica personalizada en componentes de red críticos sea mucho más seguro que las extensiones nativas.

---

Runtimes Wasm dentro de Envoy

Envoy soporta tres implementaciones de runtime Wasm: V8, WAMR (WebAssembly Micro Runtime, desarrollado por Intel) y Wasmtime. En las imágenes oficiales de lanzamiento de Envoy, V8 es el predeterminado y el único runtime compilado por defecto. WAMR y Wasmtime están presentes en el código, pero no incluidos en la compilación oficial.

Para equipos que construyen sobre distribuciones de Envoy más allá del binario oficial — como Higress, basado en Istio y Envoy y ampliamente adoptado en Alibaba Cloud — hay un interés creciente en WAMR. Cuando Higress cambió su runtime de plugins Wasm de V8 a WAMR con compilación anticipada (AOT) habilitada, el rendimiento de los plugins mejoró en un promedio del 50%, con algunos plugins con lógica compleja duplicando su velocidad. La razón: la dependencia de Envoy en V8 está fijada a una versión de 2022, lo que impide aprovechar funciones más nuevas de Wasm como WasmGC, mientras que WAMR en modo AOT genera código máquina para la plataforma objetivo mediante una pipeline de optimización personalizada, logrando un rendimiento comparable a binarios nativos en tiempo de ejecución.

---

La arquitectura de despliegue: Envoy e Istio

Envoy

El ciclo de vida de una extensión Envoy Wasm en un clúster Kubernetes en producción sigue un camino bien definido:

1. Desarrollo — Un desarrollador escribe la extensión en Rust usando el proxy-wasm-rust-sdk, implementando el trait HttpContext con callbacks para on_http_request_headers y on_http_response_body.
2. Compilación — El código Rust se compila usando rustup target add wasm32-wasip1 y cargo build --target wasm32-wasip1 --release, produciendo un binario .wasm compacto.
3. Distribución — El binario .wasm se sube a un registro de contenedores compatible con OCI.
4. Configuración — La configuración de la cadena de filtros de Envoy referencia la URI del módulo Wasm, especificando el runtime (envoy.wasm.runtime.v8 por defecto) y cualquier configuración del plugin.
5. Instanciación — Cuando Envoy inicia o recarga su configuración, obtiene e instancia el módulo Wasm dentro de una VM.
6. Ejecución — Las solicitudes HTTP fluyen a través de la cadena de filtros de Envoy y alcanzan el filtro Wasm. Envoy mapea los datos de la solicitud en la memoria lineal de la VM Wasm, el plugin ejecuta, modifica encabezados o cuerpo, y devuelve el control a Envoy.

CRD WasmPlugin de Istio

Al ejecutarse dentro de una malla de servicios, Istio proporciona el recurso personalizado WasmPlugin bajo el grupo API extensions.istio.io/v1alpha1, introducido en Istio 1.12. El CRD WasmPlugin abstrae la configuración de la cadena de filtros de Envoy y soporta direccionamiento por selector de carga de trabajo o mediante el campo targetRefs de la API Gateway de Kubernetes, que permite apuntar a proxies waypoint en despliegues de Ambient Mesh.

Un recurso WasmPlugin mínimo se ve así:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: basic-auth
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
  phase: AUTHN
  pluginConfig:
    basic_auth_rules:
      - prefix: "/api"
        request_methods: ["GET", "POST"]
        credentials:
          - "dXNlcjpwYXNz"

El agente de Istio interpreta la configuración del WasmPlugin, descarga el módulo Wasm del registro OCI e inyecta el filtro HTTP en el sidecar de Envoy (o proxy waypoint, en despliegues de Ambient) haciendo referencia al archivo local. La integridad del plugin puede asegurarse especificando el hash sha256 esperado del módulo en la especificación.

---

Casos de uso transformadores

Autenticación y autorización avanzadas

Los gateways API estándar validan JWTs mediante endpoints JWKS estándar. Wasm habilita una clase diferente de lógica de autenticación: formatos de tokens legados propietarios, verificación criptográfica en múltiples pasos o esquemas HMAC empresariales que de otro modo requerirían un viaje de ida y vuelta a un servicio de autenticación interno. El plugin Wasm intercepta la solicitud, realiza las matemáticas criptográficas localmente, y ya sea bloquea la conexión en el borde o pasa la solicitud aguas abajo. El tráfico malicioso y los intentos de DDoS nunca alcanzan los servicios internos.

Transformación dinámica de cargas útiles y redacción de datos

Un plugin Wasm puede interceptar cuerpos de respuesta HTTP salientes y realizar operaciones DLP (Prevención de Pérdida de Datos) antes de que la respuesta llegue al cliente. Usando el procesamiento de cadenas seguro en memoria de Rust, el módulo escanea la carga útil, enmascara o elimina PII como números de tarjeta de crédito o números de Seguro Social, y vuelve a calcular el encabezado Content-Length. Esto garantiza cumplimiento sin modificar las aplicaciones internas legadas que emiten los datos en bruto.

Enrutamiento consciente del contexto

Wasm permite decisiones de enrutamiento que van mucho más allá de las rutas URL y encabezados HTTP. Un módulo Wasm puede analizar el Árbol de Sintaxis Abstracta de una consulta GraphQL entrante, determinar qué servicios upstream poseen los campos solicitados, y reescribir dinámicamente la selección de upstream. Para SaaS multitenant, un plugin puede ejecutar una búsqueda localizada (a través de una conexión secundaria configurada en el proxy) para determinar el enrutamiento por fragmento de base de datos, asegurando un aislamiento de inquilinos consistente sin introducir un servicio de enrutamiento separado.

Firewalls web personalizados

Los WAF comerciales tienen dificultades con ataques a nivel de negocio en aplicaciones. Wasm permite a los equipos de seguridad escribir plugins que implementen lógica de detección altamente específica y con estado: rastrear la velocidad de parámetros en múltiples solicitudes para detectar bots de scraping, implementar límites de tasa algorítmicos dirigidos a patrones específicos de abuso de API, o hacer cumplir invariantes en la forma de las solicitudes que un WAF genérico no puede codificar.

---

Estado del ecosistema en 2026

WebAssembly 3.0

El 17 de septiembre de 2025, el Grupo Comunitario y el Grupo de Trabajo de WebAssembly del W3C anunciaron el lanzamiento de WebAssembly 3.0 como el nuevo estándar en vivo. Los autores de la especificación lo describieron como una actualización sustancialmente mayor que la 2.0, con varias funciones que estaban en desarrollo desde hace seis a ocho años. Las principales adiciones incluyen:

• Espacio de direcciones de 64 bits (memory64) — las memorias y tablas ahora pueden usar i64 como tipo de dirección, ampliando el espacio de direcciones teórico de 4 GB a 16 EB.
• WasmGC — soporte nativo de recolección de basura en el motor host. Lenguajes como Java, Kotlin, Scala y Dart ahora pueden compilarse a Wasm sin incluir un runtime completo de GC en el binario, reduciendo drásticamente el tamaño del módulo.
• Manejo de excepciones — propagación estructurada de excepciones estandarizada.
• Llamadas tail — optimización adecuada de llamadas tail para implementaciones recursivas.
• SIMD de 128 bits — operaciones vectoriales estandarizadas para cargas de trabajo intensivas en cómputo.

Para trabajo en proxies y plugins en el borde, los cambios más relevantes son la extensión de memoria a 64 bits (eliminando restricciones de tamaño en plugins intensivos en memoria) y el soporte mejorado de lenguajes para equipos que no usan Rust o C++.

WASI 0.2 y el Modelo de Componentes

WASI 0.2 (también llamado WASIp2 o Vista previa 2) fue lanzado por la Bytecode Alliance el 25 de enero de 2024. Introdujo el Modelo de Componentes de WebAssembly y WIT (Tipos de Interfaz de WebAssembly), agregando soporte de red mediante wasi:http y wasi:sockets en comparación con el WASI 0.1, que era solo POSIX. WASI 0.2 es el objetivo estable para producción en 2026. Wasmtime fue el primer runtime importante en soportar completamente módulos del Modelo de Componentes y APIs de WASI 0.2.

El Modelo de Componentes es directamente relevante para cargas de trabajo en proxy. Define un mecanismo para enlazar múltiples módulos Wasm — potencialmente escritos en diferentes lenguajes — y comunicarse mediante interfaces tipadas WIT, sin necesidad de marshaling de memoria manual o código FFI. En un contexto de gateway, esto significa que un componente de autenticación JWT en Go, un limitador de tasa en Rust y un transformador de datos en Python podrían componerse dentro del runtime de Wasm del proxy sin sobrecarga de red.

WASI 0.3 y I/O asíncrono nativo

WASI 0.3.0 fue lanzado en febrero de 2026, con soporte en vista previa en Wasmtime 37+. La característica principal es I/O asíncrono nativo integrado directamente en el Modelo de Componentes mediante tipos explícitos stream<T> y future<T> en el ABI Canónico. Antes de 0.3, WASI 0.2 requería que los desarrolladores gestionaran manualmente handles pollable — creando handles, llamando a poll(), esperando la finalización, emparejando índices devueltos con handles, extrayendo resultados — con solo una tarea pudiendo hacer poll() a la vez. Esto hacía que las cargas de trabajo I/O intensivas en Wasm fueran difíciles de escribir y limitaba la concurrencia.

Con WASI 0.3, cualquier función a nivel de componente puede implementarse y llamarse de forma asíncrona usando patrones idiomáticos en Rust, JavaScript o Python, sin máquinas de estado manuales. Esta es la última gran brecha ergonómica entre Wasm y los runtimes de servidor convencionales para cargas de trabajo I/O.

WASI 1.0 — el estándar estable a largo plazo — está previsto para 2026. El soporte de threading sigue siendo un elemento pendiente.

Plataformas en el borde en producción

Los plugins Proxy-Wasm no son el único modelo de despliegue. Plataformas en la nube que ejecutan Wasm nativamente en el borde — Cloudflare Workers, Fastly Compute, Vercel Edge Functions y Fermyon Spin — manejan miles de millones de solicitudes diarias. Cloudflare Workers funciona en más de 330 ciudades en todo el mundo, con isolates V8 que ofrecen arranques en milisegundos y amplio soporte de lenguajes Wasm mediante wasm32-wasip2. Fastly Compute ejecuta Wasm de forma nativa con casi cero penalizaciones por arranque en frío gracias a la precompilación; su modelo de precompilación elimina pausas por recolección de basura y la planificación de isolates V8, siendo muy adecuado para pipelines de entrega con latencia crítica. Fermyon fue adquirida por Akamai para ejecutar funciones serverless Wasm en más de 4,000 ubicaciones globales.

Para el modelo de plugins en servidor y en proceso, la historia de herramientas y observabilidad también ha mejorado significativamente. Los desarrolladores ahora pueden ejecutar simuladores locales de host Wasm para depurar código de plugins en Rust o Go antes de desplegar en un proxy. Los plugins Wasm pueden emitir métricas personalizadas, spans de trazabilidad distribuida y logs estructurados directamente en los flujos de telemetría de Envoy — convirtiéndolos en ciudadanos de primera clase en las pilas modernas de observabilidad.

---

Consideraciones honestas

Los proxies potenciados por Wasm no están exentos de limitaciones, y es importante reconocerlas.

Fragmentación de ABI entre hosts. Aunque Proxy-Wasm v0.2.1 es el estándar de facto, la portabilidad entre implementaciones de proxy — Envoy, MOSN, API7 — requiere verificar el soporte de ABI en cada host. El objetivo wasm32-wasip2 del Modelo de Componentes y las interfaces basadas en WIT ofrecen un camino hacia una mayor portabilidad entre hosts, pero la adopción del ecosistema proxy del Modelo de ABI aún está en proceso.

Sobrecarga de memoria a escala. Cada instancia de VM Wasm requiere su propio bloque de memoria asignada. A escala, ejecutar miles de instancias aisladas consume más memoria total que una alternativa de tiempo compartido. El costo por instancia es bajo comparado con contenedores, pero no es cero, y se acumula en grandes flotas.

I/O bloqueante en Proxy-Wasm. La ABI Proxy-Wasm es sincrónica. Los plugins que necesitan hacer llamadas externas (por ejemplo, a un sideband Redis para enrutamiento multitenant) deben usar dispatch_http_call de Envoy y el modelo de callbacks, lo que añade complejidad arquitectónica. La I/O asíncrona nativa en WASI 0.3 es una mejora a nivel de plataforma, pero no cambia directamente el modelo de ejecución del filtro Proxy-Wasm.

Opacidad en depuración. A pesar de las mejoras, depurar un plugin en un contenedor Envoy en producción requiere habilitar logs de depuración en el nivel Wasm (istioctl proxy-config wasm o en la API de administración de Envoy en /logging?wasm=debug) y correlacionar la salida de logs estructurados. La experiencia es mucho mejor que en 2021, pero aún es más compleja que depurar servicios nativos en Go o Rust.

---

Conclusión

El cambio hacia plugins proxy reverso con WebAssembly representa un cambio fundamental en cómo se entrega lógica personalizada en el límite de la red. Al compilar lógica de autenticación, transformación y enrutamiento en Wasm e insertarla en el proceso del proxy, las organizaciones logran menor latencia, un aislamiento de fallos más fuerte y mayor velocidad de desarrollo — sin bifurcar bases de código del proxy ni desplegar microservicios adicionales.

Las normas subyacentes ahora son realmente estables. La ABI Proxy-Wasm v0.2.1 está documentada y es la interfaz de producción implementada por todos los proxies principales que soportan extensiones Wasm. WebAssembly 3.0 estandarizó nueve funciones en producción en septiembre de 2025. WASI 0.2 proporcionó el Modelo de Componentes y la composición tipada entre módulos. WASI 0.3.0, lanzado en febrero de 2026, cerró la brecha de I/O asíncrono para cargas de trabajo en servidor.

El resultado práctico: compilar lógica personalizada de enrutamiento, autenticación y transformación en WebAssembly ya no es un experimento. Las cadenas de herramientas son maduras, los runtimes son estables y la historia de observabilidad ha avanzado. Si tu tráfico pasa por un proxy en el borde, el caso para Wasm ahora es una decisión de ingeniería que vale la pena — no un proyecto de investigación.

---

Cambios en el contenido

Las siguientes correcciones y extensiones fácticas se hicieron al borrador original:

#	Afirmación original	Corrección / Adición
1	“los componentes centrales de la especificación Proxy-Wasm han alcanzado un alto nivel de estabilidad” (sin calificación)	Aclarado: el estándar de facto es ABI v0.2.1, que es estable y ampliamente implementado. Sin embargo, la especificación carecía de documentación formal hasta un esfuerzo en 2023–2024 para documentar correctamente v0.2.1. La ABI vNEXT nunca fue completamente implementada. Los errores de versión de ABI incompatibles siguen siendo un problema operativo real. Fuentes: proxy-wasm/spec GitHub issues #38, #41; docs de Envoy.
2	Envoy usa “V8, Wasmtime o WAMR” (implicando igualdad de disponibilidad)	Corregido: V8 es el runtime predeterminado y el único compilado en la imagen oficial de Envoy. WAMR y Wasmtime están en el código, pero no en la compilación oficial. Fuentes: docs oficiales de Envoy; issue en GitHub #29827.
3	El objetivo de compilación se describe como wasm32-wasi	Corregido: este objetivo fue renombrado a wasm32-wasip1 en el compilador Rust en marzo de 2024. El objetivo del Modelo de Componentes es wasm32-wasip2. Fuentes: documentación del rustc.
4	Los plugins proxy-wasm en Go usan Go nativo	Aclarado: el proxy-wasm-go-sdk usa TinyGo, no Go estándar. Go estándar tiene soporte incompleto de WASI para este caso de uso. Fuentes: docs de WasmEdge; documentación de wasm-nginx-module.
5	La transición de experimental a producción completa está terminada para Proxy-Wasm	Calificado: v0.2.1 es de grado producción. El repositorio de especificaciones está activo pero con issues abiertos (soporte de temporizadores, mapas de encabezados multi-valor, verificaciones de existencia de claves KVS). La situación real se describe con precisión.
6	Estado de WebAssembly 3.0	Añadido: WebAssembly 3.0 se convirtió en estándar vivo del W3C el 17 de septiembre de 2025, estandarizando WasmGC, manejo de excepciones, llamadas tail, memoria de 64 bits, SIMD de 128 bits y otras funciones. Fuente: webassembly.org/news/2025-09-17-wasm-3.0/.
7	WASI y Modelo de Componentes descritos de forma vaga como “el futuro inmediato”	Ampliado con cronología verificada: WASI 0.2.0 lanzado el 25 de enero de 2024 (Modelo de Componentes, WIT, networking). WASI 0.3.0 lanzado en febrero de 2026 (I/O asíncrono nativo, tipos stream<T> y future<T>, en Wasmtime 37+). WASI 1.0 previsto para 2026. Fuentes: wasi.dev/roadmap; bytecodealliance; devtoollab.com.
8	Contexto de plataformas en el borde ausente	Añadido: despliegues en Cloudflare Workers, Fastly Compute, Vercel Edge Functions y Fermyon/Akamai en producción, como contexto del ecosistema Wasm en el borde.
9	No se discuten los trade-offs	Añadido: sección de trade-offs honestos que cubre: fragmentación de ABI, sobrecarga de memoria por instancia, modelo de filtro sincrónico Proxy-Wasm y complejidad en depuración.
10	Versión API del CRD WasmPlugin de Istio	Verificado como extensions.istio.io/v1alpha1. Añadido: targeting mediante targetRefs en despliegues Ambient Mesh / proxy waypoint. Fuentes: docs oficiales de Istio.