Pydantic's Monty 1.2 adds match statements to its Rust Python sandbox

Pydantic released Monty v1.2.0 on 18 October 2026, and the same version went to PyPI, npm and crates.io that day. Maintainer Samuel Colvin announced it on X the same evening. It is the first time we have covered the project.

What Monty is

The repository describes Monty as “a secure Python sandbox, written in Rust, for code written by AI.” It is a bytecode interpreter you embed in a Python, JavaScript or TypeScript, or Rust program. A model writes a short script, and Monty runs it in-process. The README says Monty runs Code Mode in Pydantic AI, and the documentation covers each language binding.

It does not run all of Python. The limitations page says: “Monty is a sandbox, not a Python implementation aiming for completeness. It implements enough Python for a model to express what it wants to do, and deliberately stops there.” What it does implement is meant to behave like CPython 3.14. Third-party packages are among the unsupported items.

The isolation model, in the project’s words

The security page is direct: “Monty is a language-level sandbox, not an OS-level one. There is no container, no seccomp filter and no virtual machine.” With no mounts and no host functions configured, it says, sandboxed code “cannot read a file, read an environment variable, open a socket, or spawn a process,” because the interpreter has no such operations. The clock and OS entropy are the default exceptions, and both can be turned off.

The page is just as direct about the host side. A host function you pass in “runs on the host with your process’s full authority”, and “a host function that takes a path and reads it, or takes a URL and fetches it, is an unconstrained filesystem or network primitive that you wrote.” Validate those inputs yourself. For Monty combined with OS-level isolation, the docs point to Full Monty, Pydantic’s commercial version.

What 1.2.0 adds

From the release notes and linked PRs:

• Language: match statements, list slice assignment, ordering comparisons for set and frozenset, and many more dunder methods on user classes.
• Dataclasses: field(), default_factory and __post_init__.
• Standard library: csv, tomllib, hashlib, bisect, os.path, and json.load and json.dump. re.split() now includes capture groups.
• Host modules: PR #942 lets sandboxed code import modules the host provides. The external_modules setting names the modules a session may import, and the security page says imports are answered “only from that mapping” and never from the host’s own import system.
• Limit hardening: PR #842 adds size checks to binascii and base64, because a conversion could allocate past the hard memory limit inside one instruction and exit the process instead of raising MemoryError. PR #1027 caps a restored snapshot’s resource limits at the restoring worker’s own limits, so a snapshot from a roomier worker cannot bring bigger budgets with it.

Those two fixes are hardening in the release notes. The repository’s security-advisory list was empty when we checked, and neither PR is labeled a vulnerability.

Speed claims

The README says a new sandbox takes “under 1ms” from a running pool, “compared to around 1500ms for a sandbox service.” Its alternatives page compares Docker, Pyodide, WASI and hosted services. These are the project’s own measurements on its own setup. On 19 October the repository showed 8,720 GitHub stars and an MIT license.

Where it fits

A microVM sandbox such as Perplexity’s SPACE or Modal’s VM sandboxes gives code a whole machine and walls it off at the OS. Monty gives code almost nothing, then lets you hand in exactly the functions it may call. That is fast and small, but its safety depends on the interpreter having no bugs and on the host functions you write. OpenCode 2.0’s Code Mode takes a similar approach with a small JavaScript interpreter. If you build on Pydantic AI, our guide to testing agents with a fake model pairs well with it.