Python en sandbox con WASM y MicroPython

Si tú mantienes un editor con plugins, una plataforma de automatización o una herramienta de IA que ejecuta snippets de terceros, tarde o temprano aparece el mismo problema: necesitas correr código Python sin darle acceso total al sistema. No basta con “tener cuidado”. Si el código viene de usuarios, extensiones o prompts, el aislamiento tiene que ser real, medible y fácil de operar.

La propuesta de usar MicroPython dentro de WebAssembly apunta justo a eso. En vez de ejecutar Python nativo en el servidor o en el navegador con permisos amplios, compilas un runtime pequeño, lo metes en un sandbox de WASM y limitas lo que puede hacer. El resultado no es una caja mágica invulnerable, pero sí una base mucho más sólida para plataformas que necesitan ejecutar lógica ajena sin abrir la puerta completa al host.

El problema real: ejecutar Python ajeno sin regalar el sistema

Cuando una app permite scripts, plugins o automatizaciones, el riesgo no es solo el clásico os.system("rm -rf"). También están los accesos a red, lectura de archivos, consumo de CPU, loops infinitos y fugas de memoria. Si tu producto atiende equipos en Latinoamérica, donde muchas veces se despliega en infraestructura compartida o con presupuestos ajustados, un incidente de aislamiento mal resuelto pega doble: seguridad y costo operativo.

Hay varias formas de aislar código, pero no todas sirven para el mismo caso. Un contenedor ayuda, sí, pero sigue siendo un proceso con muchas capacidades si no lo configuras bien. Un sandbox del sistema operativo puede ser más fuerte, aunque también más complejo de mantener. Para un editor en el navegador, además, necesitas algo que funcione en el cliente o en un entorno portable, sin depender de una VM pesada.

Ahí entra WebAssembly. WASM no es un lenguaje, sino un formato de ejecución pensado para correr código con límites claros de memoria y capacidades. Si encima metes dentro un runtime de Python reducido como MicroPython, puedes ofrecer un entorno controlado para scripts cortos, automatizaciones y extensiones. La idea no es reemplazar Python completo, sino ejecutar una parte útil de Python con restricciones explícitas.

Qué significa “sandbox” en este contexto

Aquí sandbox no quiere decir solo “un proceso aparte”. Quiere decir que el código no ve el sistema de archivos del host, no puede abrir sockets arbitrarios, no puede invocar binarios del sistema y tiene límites de memoria y tiempo. Si tu plataforma necesita, por ejemplo, transformar texto, validar reglas de negocio o formatear contenido, eso suele ser suficiente.

La diferencia práctica está en qué controlas desde fuera. Tú decides qué módulos expone el host, qué datos entran, cuánto tiempo corre cada script y qué pasa cuando falla. En vez de confiar en que el plugin sea bueno, diseñas el runtime para que sea difícil hacer daño incluso si el plugin no lo es.

Por qué MicroPython encaja mejor que CPython en WASM

MicroPython nació para dispositivos con poca memoria, así que ya trabaja con una filosofía de recorte. Eso lo vuelve atractivo para WASM: menos dependencias, menos superficie y un runtime más pequeño. CPython también puede correr en WebAssembly en ciertos escenarios, pero normalmente arrastra más peso, más complejidad y más compatibilidad de la que necesitas si tu caso de uso es ejecutar scripts limitados.

La ventaja no es solo el tamaño. MicroPython suele ser más fácil de empaquetar cuando quieres un entorno predecible. Si tu plataforma solo necesita un subconjunto de Python, te conviene aceptar esa limitación desde el principio. En productos de edición, CMS o automatización interna, la mayoría de los scripts no usa todo el estándar; usa cadenas, listas, diccionarios, fechas, validaciones y poco más.

Eso sí, hay que ser honesto: MicroPython no es Python completo. Algunas librerías estándar faltan o funcionan distinto. Si tu promesa comercial es “ejecuta cualquier paquete de PyPI”, esta ruta no te sirve. Si tu promesa es “ejecuta lógica Python segura para tareas acotadas”, entonces sí puede ser una base muy razonable.

Lo que sí ganas

• Menor superficie de ataque que un runtime Python completo.
• Un paquete más pequeño para distribuir en navegador o en servidor.
• Mejor control sobre memoria y tiempo de ejecución.
• Más facilidad para integrar con un host que expone solo APIs concretas.

Lo que no ganas

• Compatibilidad total con el ecosistema de Python.
• Acceso libre a archivos, red o procesos del sistema.
• Un sandbox perfecto por sí solo. Igual necesitas políticas alrededor.

La documentación oficial de MicroPython te ayuda a entender qué parte del lenguaje y de sus módulos está disponible: MicroPython documentation. Para WebAssembly, vale la pena revisar el estándar y las capacidades del runtime que uses, porque el comportamiento cambia según el host: WebAssembly specification.

Cómo se vería una arquitectura útil para productos reales

La arquitectura más práctica suele ser sencilla: tu app principal prepara entrada, arranca el runtime WASM, le pasa datos por una interfaz controlada y recibe salida estructurada. El plugin o script no toca nada fuera de ese contrato. Si necesitas más capacidades, no las expones por defecto; las agregas como funciones host explícitas.

Una versión típica para un editor podría verse así:

1. El usuario escribe un script en Python.
2. Tu app lo manda al runtime MicroPython compilado a WASM.
3. El runtime recibe solo texto, JSON o buffers limitados.
4. El script devuelve una respuesta o error.
5. El host decide si guarda, muestra o descarta el resultado.

Ese flujo funciona muy bien para validaciones, transformaciones de contenido, reglas personalizadas y pequeñas automatizaciones. También sirve para plugins que necesitan leer el documento actual, calcular una salida y nada más. No le das al script una API general de sistema; le das herramientas puntuales.

Interfaz host: menos es más

La parte más delicada no es compilar WASM. Es diseñar la interfaz entre el host y el sandbox. Si expones demasiadas funciones, conviertes el sandbox en un atajo para volver a tener acceso amplio. Si expones pocas, el sistema se vuelve inútil. El punto medio suele ser un conjunto pequeño de primitivas: leer entrada, escribir salida, registrar logs, pedir fecha actual y, si hace falta, consultar una lista cerrada de recursos.

Eso también ayuda a auditar. Si el plugin solo puede llamar cinco funciones, revisar su comportamiento es mucho más simple que inspeccionar cualquier importación de Python. Para equipos que operan productos con varios clientes, esa trazabilidad vale mucho más que una promesa vaga de seguridad.

Límites prácticos: rendimiento, compatibilidad y mantenimiento

No conviene vender esta idea como si resolviera todo. WASM añade una capa extra, y esa capa tiene costo. El arranque del runtime, la serialización de datos y la ejecución dentro del sandbox pueden ser más lentos que correr Python nativo. Para scripts de pocos milisegundos, ese overhead importa. Para tareas que tardan decenas o cientos de milisegundos, suele ser aceptable.

También hay que pensar en compatibilidad. Si tu comunidad de usuarios espera instalar paquetes externos, usar numpy, pandas o integraciones de red complejas, MicroPython no va a cubrirlo. En cambio, si tu objetivo es un lenguaje de automatización embebido, el recorte juega a favor. Menos compatibilidad significa menos sorpresas de seguridad y menos dependencia de bibliotecas que no controlas.

Otro punto es el mantenimiento. Una solución basada en WASM necesita que vigiles actualizaciones del runtime, límites de memoria, comportamiento del host y cambios en el navegador o en el motor que uses. No es una pieza que montas una vez y olvidas. Pero si comparas ese trabajo con mantener contenedores por usuario, o con aislar extensiones dentro de un proceso de backend grande, muchas veces el balance sale mejor.

Tabla comparativa rápida

Si tu producto está en fase de crecimiento, esta tabla ayuda a decidir sin caer en el reflejo de “usar lo más poderoso”. Muchas plataformas no necesitan una VM completa; necesitan un runtime pequeño, auditable y suficiente.

Casos de uso donde sí tiene sentido

El escenario más claro es un editor con extensiones. Piensa en un CMS donde cada cliente puede definir reglas para procesar contenido antes de publicarlo. O en un editor de datos donde el usuario quiere limpiar texto, convertir formatos o generar campos derivados. En ambos casos, el código es útil, pero no debería tocar el sistema.

También encaja en plataformas de IA que ejecutan herramientas definidas por el usuario. Si tú permites que un agente llame a scripts personalizados, el sandbox evita que ese script se convierta en un acceso libre al host. El agente puede transformar un payload, validar una respuesta o preparar un archivo temporal, pero dentro de límites claros.

En educación y laboratorios de programación, esta combinación también tiene valor. Puedes ofrecer Python en el navegador sin levantar infraestructura por estudiante, y sin darle acceso a red o filesystem. Para cursos, demos y pruebas rápidas, eso reduce fricción. En equipos pequeños de Ecuador, México, Colombia o Perú, donde cada hora de soporte cuenta, simplificar despliegue puede ser tan importante como la seguridad.

Ejemplos concretos

• Un editor de publicaciones que permite scripts para normalizar títulos y metadatos.
• Un sistema de plugins para CRM que calcula campos derivados desde JSON.
• Una herramienta interna que valida archivos antes de importarlos.
• Un playground educativo que ejecuta ejercicios de Python sin acceso al host.

En todos esos casos, el patrón se repite: entrada controlada, salida controlada y cero acceso libre a recursos del sistema. Si necesitas enviar datos a servicios externos, mejor hacerlo desde el host con políticas propias, no desde el script.

Implementación: una ruta mínima para empezar

Si quieres probar la idea sin construir una plataforma completa, empieza por un prototipo muy acotado. No intentes soportar todo Python desde el día uno. El objetivo es confirmar si tu caso de uso entra en el subconjunto que MicroPython maneja bien y si el costo de integración te conviene.

Un plan razonable sería este:

1. Define 3 o 4 tareas reales que hoy quieras delegar a scripts.
2. Identifica qué módulos de Python usan esas tareas.
3. Revisa si MicroPython cubre esas necesidades según su documentación oficial.
4. Compila o integra el runtime WASM que prefieras.
5. Expón solo funciones host mínimas.
6. Añade límites de memoria, tiempo y tamaño de entrada.
7. Registra errores y métricas desde el host, no desde el script.

Para una integración básica, el intercambio suele ser JSON. Es fácil de depurar y funciona bien para scripts pequeños. Un ejemplo conceptual podría verse así:

# script dentro del sandbox
import json

def transform(payload):
    data = json.loads(payload)
    title = data.get("title", "").strip().upper()
    return json.dumps({"title": title, "ok": True})

Y desde el host, tú solo pasas un string y recibes otro string. No hace falta abrir archivos ni sockets para algo así. Si más adelante necesitas más capacidad, la agregas de forma explícita.

Qué medir desde el primer día

• Tiempo de arranque del runtime: idealmente por debajo de 100ms en tareas cortas, aunque depende del entorno.
• Tamaño máximo de entrada: por ejemplo, 64 KB o 256 KB según tu caso.
• Límite de ejecución: 50ms, 200ms o el umbral que tu producto soporte.
• Memoria máxima por script: definida por política, no por intuición.

Esos números no son universales, pero sí te obligan a pensar en límites reales. Sin límites, el sandbox es solo una promesa de marketing.

Tabla resumen

La decisión no debería basarse en moda técnica, sino en riesgo y operación. Si tu plataforma necesita correr código de terceros con control fino, MicroPython en WASM te da una base más seria que ejecutar scripts nativos sin barreras. Si necesitas compatibilidad total con el ecosistema Python, probablemente debas combinar esta idea con otros mecanismos o elegir otro enfoque.