Carmen Labs

Security Model

What parsers and components are and aren't allowed to do, and why the runtime owns file I/O.

Security Model

Parser and component code may be generated by an LLM and re-run automatically when a source file changes. The spec treats that code as untrusted by default and puts the runtime, not the parser or component, in charge of anything privileged.

The core rule

The runtime owns file I/O. Neither the parser nor the component reads the source file, or any other file, directly.

runtime  →  reads source file, normalizes it
runtime  →  calls parser(input, context)
runtime  →  passes parser's output as `data` to the component
runtime  →  renders the component

If a parser or component needs something beyond input / data and context.settings, that needs to be a capability the runtime explicitly grants — not a filesystem call or a bare fetch() inside generated code.

Requirements

  • Parser and component code MUST NOT be given unrestricted filesystem access.
  • Parser and component code MUST NOT perform arbitrary network requests (fetch, XHR, WebSocket) without the runtime granting explicit, scoped permission.
  • The runtime MUST catch parser errors and render errors separately, and present the user with a controlled error state rather than crashing the host application.
  • The runtime MUST offer a way to regenerate the parser or component independently after a failure.

Execution strategies (non-normative)

The spec does not mandate how a runtime isolates parser/component execution — only the guarantees above. Reasonable approaches, in increasing order of isolation:

  1. Compile with Vite/esbuild and load as a module in the host process, relying on the contract (no fs/network APIs passed in) rather than hard sandboxing.
  2. Execute inside an iframe with a restrictive sandbox attribute.
  3. Execute inside a Web Worker with no DOM or filesystem access, message-passing data in.
  4. Precompile at MView-creation time and treat the compiled artifact as the thing that ships, re-running codegen (not the compiled output) when regeneration is requested.

Pick the strategy that matches your host environment's trust model — a browser-based tool and a desktop app with local file access have different constraints. The invariant that must hold regardless of strategy: a compromised or buggy parser/component cannot read or write files the user didn't explicitly expose to it.

Regeneration

Because the parser and component are independently generatable, a runtime should expose regeneration as three distinct actions, not one:

  • Regenerate Parser — when the source file's shape changed (e.g. a renamed column) but the visual design is still correct.
  • Regenerate Component — when the data model is fine but the presentation needs to change.
  • Regenerate Full MView — start over from the source file.

Modelo de seguridad

Qué pueden y no pueden hacer parsers y componentes, y por qué el runtime es dueño de la E/S de archivos.

Modelo de seguridad

El código de parser y componente puede ser generado por un LLM y volver a ejecutarse automáticamente cuando cambia un archivo fuente. La especificación trata ese código como no confiable por defecto y deja al runtime, no al parser ni al componente, a cargo de todo lo privilegiado.

La regla central

El runtime es dueño de la E/S de archivos. Ni el parser ni el componente leen directamente el archivo fuente ni ningún otro archivo.

runtime  →  lee el archivo fuente, lo normaliza
runtime  →  llama a parser(input, context)
runtime  →  pasa la salida del parser como `data` al componente
runtime  →  renderiza el componente

Si un parser o componente necesita algo más allá de input / data y context.settings, eso debe ser una capacidad que el runtime conceda explícitamente: no una llamada al filesystem ni un fetch() directo dentro del código generado.

Requisitos

  • El código del parser y del componente MUST NOT recibir acceso irrestricto al filesystem.
  • El código del parser y del componente MUST NOT realizar solicitudes de red arbitrarias (fetch, XHR, WebSocket) sin que el runtime conceda permiso explícito y acotado.
  • El runtime MUST capturar errores del parser y errores de render por separado, y presentar al usuario un estado de error controlado en lugar de romper la aplicación host.
  • El runtime MUST ofrecer una forma de regenerar el parser o el componente de manera independiente después de una falla.

Estrategias de ejecución (no normativas)

La especificación no exige cómo un runtime aísla la ejecución de parser/componente; solo exige las garantías anteriores. Enfoques razonables, de menor a mayor aislamiento:

  1. Compilar con Vite/esbuild y cargar como módulo en el proceso host, confiando en el contrato (sin entregar APIs de fs/red) en lugar de usar un sandbox fuerte.
  2. Ejecutar dentro de un iframe con un atributo sandbox restrictivo.
  3. Ejecutar dentro de un Web Worker sin acceso al DOM ni al filesystem, pasando data por mensajes.
  4. Precompilar al momento de creación de la MView y tratar el artefacto compilado como lo distribuido, reejecutando codegen (no la salida compilada) cuando se solicite regeneración.

Elige la estrategia que calce con el modelo de confianza de tu entorno host: una herramienta basada en navegador y una app desktop con acceso a archivos locales tienen restricciones distintas. La invariante que debe mantenerse sin importar la estrategia: un parser/componente comprometido o defectuoso no puede leer ni escribir archivos que el usuario no expuso explícitamente.

Regeneración

Como parser y componente pueden generarse de manera independiente, un runtime debería exponer la regeneración como tres acciones distintas, no una sola:

  • Regenerar parser — cuando cambió la forma del archivo fuente (por ejemplo, una columna renombrada) pero el diseño visual sigue siendo correcto.
  • Regenerar componente — cuando el modelo de datos está bien, pero la presentación debe cambiar.
  • Regenerar MView completa — partir de nuevo desde el archivo fuente.