How MPP Fits Into Your Existing AI Agent Stack

Enterprise AI teams are not starting from scratch. They have agents built on established frameworks — LangChain, CrewAI, AutoGen, Semantic Kernel, or custom internal systems. They have tools connected via MCP, or through framework-specific tool-calling interfaces. They have deployment pipelines, monitoring, and operational procedures.

The question is not "should I adopt MPP?" The question is "where does MPP fit in what I already have, and how much do I need to change?"

The answer is less than you think.

Where MPP Sits in the Stack

An AI agent stack has four layers. MPP operates at one of them:

┌─────────────────────────────────────────────────┐
│  Layer 4: Agent Framework                       │
│  LangChain, CrewAI, AutoGen, custom agents      │
│  → Decides which tool to call and when           │
├─────────────────────────────────────────────────┤
│  Layer 3: Tool Protocol                         │
│  MCP (JSON-RPC 2.0), framework-native calls     │
│  → Defines how tools are discovered and invoked  │
├─────────────────────────────────────────────────┤
│  Layer 2: Tool Execution ← MPP OPERATES HERE   │
│  Verification, permissions, sandbox, privacy     │
│  → Defines how tools are secured and run         │
├─────────────────────────────────────────────────┤
│  Layer 1: Infrastructure                        │
│  OS, network, storage, secrets management        │
│  → Provides the underlying compute platform      │
└─────────────────────────────────────────────────┘

MPP does not replace your agent framework (Layer 4). It does not replace MCP as a tool discovery and invocation protocol (Layer 3). It does not manage your infrastructure (Layer 1).

MPP sits at Layer 2: Tool Execution — the boundary between "the agent wants to call a tool" and "the tool code actually runs." This is where verification, permission enforcement, sandboxing, and privacy filtering happen. It is the layer that current architectures lack entirely.

What MPP Replaces

Today, when your agent calls a tool, the execution layer is... nothing. The tool runs as a process, a function, or a server with ambient authority. There is no verification step, no permission check, no sandbox, and no privacy filter.

MPP replaces this absence with a structured pipeline:

| Before MPP | With MPP | |-----------|---------| | Tool runs unverified | Gatekeeper verifies signature + content hash | | Tool has ambient authority | Capability model restricts to declared resources | | Tool runs in host process or server | WASM sandbox isolates execution | | PII flows to agent unfiltered | Privacy filter redacts sensitive data | | No audit trail | Hash-chained log records every invocation | | Trust-on-first-use | Publisher identity verification + HITL |

The business logic of your tools does not change. The agent's decision-making does not change. The tool discovery protocol does not change. What changes is that a security pipeline now exists between the decision and the execution.

What MPP Does Not Replace

Your Agent Framework

MPP does not care which agent framework you use. LangChain, CrewAI, AutoGen, Semantic Kernel, a custom Python script that calls the OpenAI API — all of them can use MPP for tool execution. The framework decides which tool to call. MPP decides whether and how it's safe to run that tool.

MCP

MPP and MCP are complementary, not competing. MCP defines how tools are discovered and invoked — the JSON-RPC 2.0 wire protocol, the tools/list and tools/call methods, the input schema format. MPP defines how tools are packaged, verified, and secured during execution.

A typical deployment uses both:

Agent discovers available tools via MCP (tools/list)
Agent decides to invoke a tool via MCP (tools/call)
The host runtime routes the invocation through the MPP pipeline:
- Gatekeeper verifies the .mpp package
- Permission engine evaluates capabilities
- WASM sandbox executes the tool
- Privacy filter processes the response
The filtered response returns to the agent via MCP's JSON-RPC format

The wire format is identical. The agent doesn't know (or need to know) that MPP is in the pipeline. It sends a JSON-RPC request and receives a JSON-RPC response. The security happens transparently in between.

Your Tool's Business Logic

MPP tools are ordinary functions compiled to WebAssembly. The business logic — parsing input, calling APIs, processing data, formatting output — stays the same. What changes is the packaging:

Before: Your tool runs as a Node.js script, a Python function, or an MCP server process.
After: Your tool runs as a WASM binary inside a signed .mpp package.

The core code is the same. The compilation target changes (from native to wasm32-wasip1), and the tool is wrapped in a manifest that declares its capabilities. For many tools, migration is primarily a packaging step.

The Integration Points

For teams integrating MPP into an existing system, there are two integration paths depending on your role:

Path 1: Host Integration (Platform Teams)

If you build the platform that agents run on — an IDE extension, a CLI agent, a custom enterprise agent framework — you integrate the MPP runtime into your host application.

The MPP runtime is a set of Rust crates that provide the complete security pipeline. A minimal integration requires roughly 50 lines of code:

// 1. Verify the package
let result = Gatekeeper::verify_file(Path::new("tool.mpp"))?;

// 2. Evaluate permissions
let policy = PermissionPolicy::new()
    .trust_package("org.mycompany.internal-tool")
    .auto_approve_low(true);

match policy.evaluate(&result.manifest) {
    PolicyDecision::Granted(token) => {
        // 3. Execute in sandbox
        let config = SandboxConfig {
            memory_limit_bytes: result.manifest.runtime.memory_limit_mb as u64 * 1024 * 1024,
            timeout: Duration::from_millis(result.manifest.runtime.timeout_ms as u64),
            stdin_data: request_bytes,
            env_vars: extract_approved_env_vars(&token),
            dir_mappings: extract_approved_dirs(&token),
            capability_token: Some(token),
            allowed_network_domains: result.manifest.capabilities.network.clone(),
        };
        let sandbox = WasmSandbox::new()?;
        let output = sandbox.execute(&result.wasm_binary, config)?;

        // 4. Apply privacy filters
        let engine = PrivacyFilterEngine::from_config(
            &result.manifest.privacy_filters.patterns,
            &custom_patterns,
        )?;
        let (filtered, applied) = engine.redact_json(&response.result.content);
    }
    PolicyDecision::RequiresConfirmation { capabilities, security_level } => {
        // Show HITL dialog, then proceed if approved
    }
    PolicyDecision::Denied { reason } => {
        // Block execution
    }
}

The runtime crates handle all the complexity: cryptographic verification, WASM instantiation, WASI configuration, network filtering, and PII redaction. Your integration code wires these components together and provides the UI for HITL dialogs.

Path 2: Tool Migration (Tool Authors)

If you author tools that agents use, migration involves repackaging your tool as an MPP package. The steps:

Compile to WASM. If your tool is in Rust, add the wasm32-wasip1 target and compile. If it's in another language, use the appropriate WASM compilation toolchain (Emscripten for C/C++, TinyGo for Go, etc.).
Write a manifest. Declare your tool's identity, capabilities, and privacy filters in manifest.json. This is the step where you explicitly state what your tool needs — which is probably a fraction of what it had access to before.
Use the MPP SDK. Replace your tool's I/O layer with the MPP SDK's tool_handler. The SDK handles JSON-RPC framing, stdin/stdout communication, and error serialisation.
Sign and publish. Generate an Ed25519 keypair, sign the package, and publish to a registry.

For a tool with simple dependencies that compiles cleanly to WASM, this is a day of work. For tools with complex native dependencies, it may require more effort — particularly if those dependencies don't have WASM-compatible alternatives.

Common Integration Patterns

IDE Extension

VS Code, JetBrains, and similar IDEs with AI assistant features are natural MPP hosts. The pattern:

The extension maintains a local store of installed .mpp packages (~/.mpp/packages/)
When the AI model requests a tool, the extension runs the MPP pipeline
HITL dialogs appear as native IDE notifications or modal dialogs
The KV store provides per-tool persistence in the workspace
Audit logs integrate with the IDE's output panel or a dedicated log view

Performance optimisation: cache AttestationResult for frequently-used tools and pre-compile WASM modules to skip the compilation step on re-invocation.

CLI Agent

A command-line AI agent (think: an autonomous coding assistant or an ops automation tool) integrates MPP as a library:

Packages are installed via mpp install and stored locally
Permission policy is configured once (trusted publishers, auto-approve settings)
HITL prompts map to terminal confirmations (Y/N for simple approvals)
Audit logs write to a structured file or forward to a logging service

For CI/CD pipelines where interactive HITL is not possible, configure the policy to auto-approve trusted internal packages and deny everything else. The pipeline runs with a curated set of pre-approved tools.

Custom Enterprise Platform

Large organisations building their own AI agent platforms integrate MPP as a runtime component:

A centralised MPP registry hosts approved internal tools
Platform administrators manage the trusted publisher keystore
Permission policies are defined centrally and pushed to all agent hosts
Audit logs flow to the organisation's SIEM for correlation and alerting
Privacy filter patterns include organisation-specific identifiers

This is the pattern that gives the most governance control. The platform team controls which tools are available, who can publish them, what capabilities are approved, and what data protection patterns are enforced.

What About Non-Rust Tools?

MPP tools compile to WebAssembly, and the SDK is currently in Rust. This raises an obvious question: what if your existing tools are in Python, TypeScript, or Go?

Rust tools have the most straightforward path. The MPP SDK is native Rust, the wasm32-wasip1 target is a first-class compilation target, and the resulting WASM binaries are small and fast.

C and C++ tools compile to WASM via Emscripten or wasi-sdk. The resulting binaries are fully compatible with MPP's WASM sandbox. You write a thin adapter layer that reads JSON-RPC from stdin and writes responses to stdout.

Go tools compile to WASM via TinyGo (which targets wasm32-wasi). Standard library support is partial but improving. I/O-heavy tools work well; tools that depend on cgo or platform-specific packages may need adaptation.

Python and TypeScript tools have experimental WASM support (Pyodide for Python, JCO/ComponentModel for JS). These produce larger binaries and have runtime overhead, but they work for tools where rewriting in Rust is not practical.

The pragmatic approach: start by migrating your highest-risk tools (those with network access, credential usage, or PII exposure) regardless of language. The security benefit of sandboxing and capability enforcement applies to all tools equally. Optimise the runtime characteristics (binary size, startup time) later.

The Migration Is Incremental

You do not need to migrate all your tools at once. You do not need to replace your agent framework. You do not need to abandon MCP. MPP layers into the existing stack at the execution boundary:

Start with one high-risk tool. Package it, sign it, deploy it through the MPP pipeline.
Add more tools as the process becomes familiar. Build packaging into your CI/CD.
Expand the permission policy as your trusted publisher list grows.
Connect the audit log to your existing monitoring and compliance infrastructure.
Eventually, make MPP execution the default for all agent-invoked tools.

Each step adds security without disrupting what's already working. The agent framework, the discovery protocol, and the business logic remain unchanged. What changes is that a verification, permission, sandboxing, and privacy layer now exists where there was nothing before.

For detailed host integration code, see the Host Developer Guide. For how to migrate an existing MCP tool to MPP, read the companion post From MCP Server to MPP Package (coming soon). For the tool author perspective, read Building Your First MPP Tool.