Back to Blog

Introducing MPP: Containerization for AI Tool Execution

MPP Protocol·February 18, 2026·6 min read
MPPAI SecurityWASMOpen Spec

The story of containerization in software is well known. Before Docker, deploying software meant managing host dependencies, wrestling with environment drift, and praying that the production server looked like the laptop it was built on. Containers solved the isolation and reproducibility problem so thoroughly that the industry barely remembers what came before.

AI agent tooling is at the same inflection point, just earlier in the timeline, and with higher stakes.


The Problem: Tools Without Borders

When an AI agent executes a tool today, it typically invokes a function in its own process, or calls an MCP server over a local socket. Either way, the tool runs with whatever permissions the host process has. It can read any file the agent can read. It can call any API the agent can call. It can spawn subprocesses, exfiltrate data, and modify state, all without the host ever knowing what happened inside.

This isn't a hypothetical. MCP's own documentation acknowledges that tool descriptions can contain instructions that hijack the agent. Supply-chain attacks on AI tool repositories are a near-future certainty. And the surface is expanding every week as more tools, more models, and more autonomous workflows enter production.

The security primitives that the cloud-native world takes for granted, image signing, namespace isolation, capability-based access control, audit logs, simply don't exist yet for AI tool execution.

MPP is our attempt to change that.


What MPP Is

Model Package Protocol is a licensed protocol for AI tool artifacts, developed and commercialised by Quantum 2x.

Signed Artifacts

Every MPP package is signed with Ed25519. Before execution, the host runtime verifies the signature against the publisher's known public key. If the package has been tampered with post-publication, even one byte, execution is refused.

This is directly analogous to what gpg --verify does for Linux packages, or what Apple's notarisation does for macOS binaries. It gives the runtime a trust anchor: it knows exactly what it's running, who produced it, and that it hasn't been modified in transit or at rest.

WASM Sandboxing

MPP tools execute inside a WebAssembly sandbox. WASM provides:

  • Memory isolation — the tool operates in its own linear memory; it cannot read the host's heap.
  • Capability restriction — a WASM module has no ambient access to the filesystem, network, or system calls. Everything it can do must be explicitly granted.
  • Deterministic execution — the same inputs produce the same outputs, which aids in replay and audit.

The host runtime instantiates a fresh WASM module per invocation. The tool executes, produces its output, and the module is torn down. No persistent state, no side-channel to the host.

Declared Permission Boundaries

Before a tool can be invoked, it must declare every resource it needs:

permissions:
  filesystem:
    read: ["/tmp/agent-workspace"]
    write: ["/tmp/agent-workspace/output"]
  network:
    outbound: ["api.example.com:443"]
  env: []

The runtime enforces these declarations at the syscall level. If the tool attempts to open a file outside its declared paths, the call returns a permission error. If it attempts to connect to an undeclared host, the connection is refused. The tool cannot escalate its own permissions at runtime.

This is the capability model that operating systems and browsers have used for decades, applied to AI tool execution.

Append-Only Audit Logs

Every tool invocation, its package identity, inputs, outputs, declared permissions, and the result of the permission check, is written to an append-only, structured audit log. The log is designed to be tamper-evident: entries are hash-chained so that any modification or deletion is detectable.

This log is the foundation for compliance reporting, incident response, and over time building the operational confidence to extend agents more autonomy.


What MPP Is Not

MPP is not a model. It does not touch inference, training, fine-tuning, or any part of the AI stack above the tool execution layer. It is specifically and narrowly focused on the boundary between an AI agent and the tools it calls.

MPP is not a replacement for MCP. MCP defines a protocol for discovering and invoking tools. MPP defines a format for packaging and securing them. They are complementary layers, and we expect MPP packages to be distributed and discovered via MCP registries.

MPP is not finished. The v0.1 specification covers the core primitives described above. The roadmap includes runtime policy enforcement, an open registry with publisher identity verification, and SDK support for TypeScript, Python, and Rust.


Enterprise Licensing

MPP is a proprietary protocol developed by Quantum 2x and licensed to enterprise customers for integration into their AI agent stacks. Our goals:

  1. Purpose-built for enterprise — the protocol is designed for production AI deployments where security, auditability, and governance are non-negotiable.
  2. Vendor-agnostic integration — MPP integrates with any AI agent framework without locking customers into a specific runtime or toolchain.
  3. Supported adoption — licensed customers receive integration support, SDK access, and a direct relationship with the Quantum 2x team.

For licensing and integration enquiries, contact us via the contact page.


Why Now

Three trends are converging:

1. Autonomous agents are entering production. The demo era is over. Teams are running agents in production with real system access, and the first incidents are being reported privately. The window to establish a security baseline before widespread adoption is closing.

2. The tool ecosystem is fragmenting. MCP has driven rapid growth in the number of published tools, thousands of servers, tens of thousands of capabilities. Without a standard security model, that ecosystem is a supply-chain attack waiting to happen.

3. Regulatory pressure is coming. The EU AI Act, NIST AI RMF, and emerging sector-specific requirements all point toward auditability and controlled tool execution as baseline requirements for AI systems with real-world consequences. Organizations that build on a sound security foundation now will have a significant advantage when regulation arrives.

MPP is our contribution to getting the foundation right.


Read the full technical specification in the documentation, or get in touch if you're building on AI tools and want to talk through how MPP fits your use case.