Architecture

Overview

MPP is built around four components that form a complete trust chain:

1. The Registry — stores signed package metadata and enforces immutable publication records
2. The KMS — manages the attestation signing key and is the root of trust for signature verification
3. The Runtime — downloads, verifies, and sandboxes tool execution
4. The Audit Log — records every invocation in an append-only, tamper-evident log

The Registry

The registry is a content-addressable store of package metadata. When a tool author publishes a package, the CLI computes a SHA-256 hash of the package bundle and signs it with the author's private key. The registry validates the signature against the author's registered public key, then stores the hash and signature as an immutable record.

Package records are append-only — a published version cannot be modified or deleted. This is a deliberate security property: the attestation record for any version is permanent.

The KMS

The attestation signing private key lives in a cloud Hardware Security Module (HSM). It never exists in code, environment variables, or files. When a package is signed, the system sends a signing request to the HSM and receives the signature — the raw private key is never exposed.

This means a breach of the application servers cannot produce forged attestation certificates. The root of trust is hardware-isolated. Verification uses a published public key that any party can check independently.

The Runtime

When an agent loads a tool, the MPP runtime retrieves the package's attestation record from the registry, verifies the content hash matches, and confirms the signature is valid. The tool then runs inside a WebAssembly sandbox configured with the package's capability manifest.

The WASM sandbox intercepts all system calls — file I/O, network requests, environment variable access — and allows only what the manifest declares. Any attempt to access something outside the declared scope terminates the process immediately.

The Audit Log

Every tool invocation is recorded to an append-only table. Entries capture: which tool was invoked, by whom, at what time, which capability was exercised, and whether the invocation succeeded, was blocked, or errored.

The log is write-protected at the database level — no application code can modify or delete entries. This makes it suitable as forensic evidence for security reviews and compliance audits.

The Trust Chain

Publisher signs package → Registry stores hash + signature (immutable)
Agent loads tool       → Runtime verifies hash + signature against registry
Runtime enforces       → WASM sandbox enforces capability manifest at runtime
Tool executes          → Every invocation written to append-only audit log

No step trusts the previous step without verification. A tampered package fails the hash check. A revoked attestation fails the registry lookup. A capability violation fails in the sandbox and is logged.

What This Means in Practice

Q2X operates as a certificate authority, not a runtime host. We certify that a package is what its publisher says it is and has not changed since attestation. The tool runs in your infrastructure — in your cloud account, on your servers — and we have no access to what it does once it is running.

For the complete picture of Q2X's responsibilities versus yours, see Security & Trust.