mpak Trust Framework (MTF) v0.1

MTF is a specification for securing the supply chain of MCP server bundles. It defines controls spanning the full distribution lifecycle: from how bundles are built and signed, to how registries govern namespaces and handle revocations, to how consumers verify and install packages.

Version: 0.1 Status: Draft License: CC BY 4.0

Table of Contents

1. Introduction
2. Threat Model
3. Control Catalog
   • 3.1 Control Format
   • 3.2 Artifact Integrity (AI-)
   • 3.3 Supply Chain (SC-)
   • 3.4 Code Quality (CQ-)
   • 3.5 Capability Declaration (CD-)
   • 3.6 Provenance (PR-)
   • 3.7 Registry Operations (RG-)
   • 3.8 Publisher Identity (PK-)
   • 3.9 Installation (IN-)
   • 3.10 Update Lifecycle (UP-)
4. Manifest Specification
5. Signing & Attestation
6. Implementation Guide
7. Specification Roadmap

• Appendix A: Control Quick Reference
• Appendix B: Controls by Compliance Level
• Appendix C: Open Questions
• Appendix D: Runtime Security Roadmap

1. Introduction

1.1 Purpose

MTF defines security controls for MCP server bundles distributed through package registries. It addresses supply chain threats specific to the MCP ecosystem, including tool description poisoning, credential aggregation, and slopsquatting.

1.2 Scope & Boundaries

What MTF covers:

What MTF does NOT cover:

• Runtime execution (sandboxing, permission enforcement during tool invocation)
• Prompt injection defense (LLM-level input filtering)
• Tool-level permissions (per-invocation authorization)
• MCP client security (host application hardening)
• Network transport (TLS configuration)

These concerns require runtime security controls planned for MTF v0.2+.

1.3 Terminology

MCP bundle: A distributable package representing exactly one MCP server, containing:

Bundle-server invariant: A bundle MUST correspond to exactly one MCP server entrypoint. Bundles MUST NOT contain multiple independently invokable servers.

Requirement levels (RFC 2119):

1.4 Compliance Levels

MTF defines four compliance levels. Each level includes all requirements from previous levels.

1.5 Security Invariants

The following guarantees MUST hold across all MTF versions:

1. Signed content: All executable bundle content is cryptographically signed and integrity-verified before execution (L3+).
2. Dependency transparency: SBOMs enumerate all direct and transitive dependencies with pinned versions.
3. Revocation enforcement: Revoked bundles are blocked at install time; clients MUST check revocation status.
4. Consent for escalation: Permission or scope increases during updates require explicit user consent.

2. Threat Model

2.1 Attack Surface

MCP bundles present attack opportunities across multiple phases:

2.2 Supply Chain Attack Vectors

2.2.1 Typosquatting / Namespace Confusion

Vector: Attacker registers package names similar to legitimate packages.

Mechanism: Exploits human typos (stripe-mcp vs strpe-mcp) or organizational namespace confusion.

Controls: RG-01, RG-02, CQ-06

2.2.2 Slopsquatting (MCP-Specific)

Vector: Attacker registers package names that LLMs hallucinate.

Mechanism: LLMs generate plausible but non-existent package names. Attackers preemptively register these.

Controls: CQ-06, RG-02

2.2.3 Dependency Hijacking

Vector: Attacker compromises a transitive dependency.

Mechanism: Typosquatting internal names, account takeover, malicious upstream contribution.

Controls: SC-02, SC-03, PR-03

2.2.4 Malicious Updates / Account Takeover

Vector: Attacker publishes malicious update using compromised publisher credentials.

Controls: PR-02, PK-02, PK-03, RG-05

2.2.5 Build Provenance Gaps

Vector: Attacker tampers with build pipeline or publishes artifacts without provenance.

Controls: PR-03, AI-04, PR-04

2.2.6 Phantom Bundle Components

Vector: Bundle contains files not declared in manifest.

Controls: AI-05

2.2.7 Metadata / Manifest Manipulation

Vector: Manifest declares benign capabilities while code implements dangerous ones.

Controls: CD-02, CQ-06

2.2.8 Tool Description Poisoning (MCP-Specific)

Vector: Malicious instructions embedded in MCP tool descriptions.

Mechanism: LLMs consume tool descriptions as trusted instructions. Attacker embeds directives to exfiltrate data.

Controls: CD-03

2.2.9 Registry Poisoning

Vector: Attacker compromises registry infrastructure.

Controls: RG-03, RG-04

2.2.10 Unverified Publisher Identity

Vector: Attacker publishes under false identity.

Controls: PR-02, PK-01

2.2.11 Abandoned / Unmaintained Bundles

Vector: Legitimate but abandoned bundle accumulates vulnerabilities.

Controls: UP-03, PK-04

2.2.12 Credential Aggregation (MCP-Specific)

Vector: Compromised MCP server accesses tokens for multiple services.

Mechanism: MCP servers aggregate OAuth tokens creating concentrated breach potential.

Controls: CD-04, CD-05

2.2.13 Initialization-Time Exfiltration (MCP-Specific)

Vector: Malicious code executes during server startup, before any tool invocation.

Controls: CD-02, CQ-06

3. Control Catalog

3.1 Control Format

Each control in this catalog follows a consistent structure:

Note: Some controls are evaluated by multiple actors. The Enforcement field indicates the primary enforcement point for compliance; clients and registries MAY additionally enforce scanner controls.

Control Prefixes:

3.2 Artifact Integrity (AI-)

Artifact integrity controls ensure that bundles are complete, unmodified, and verifiably from the claimed publisher.

AI-01: Manifest Validation

Level: L1 | Enforcement: Scanner

Rationale: The manifest is the foundation for all other controls. Without a valid manifest, bundles cannot be evaluated for compliance, capabilities cannot be declared, and verification cannot proceed.

Requirements:

• Bundle MUST include manifest.json at bundle root
• Manifest MUST validate against mcpb schema
• Manifest MUST include all required mcpb fields

Required Fields (L1):

Additional Required Fields (L2+):

Validation Steps:

1. Parse JSON (reject malformed)
2. Validate against mcpb schema
3. Verify required fields present
4. If both server and mcp_config are present, verify execution targets are consistent (same entrypoint/module)
5. Validate semver format
6. For L2+: Validate scoped name format (@scope/name)

Severity:

Threats Addressed: Metadata manipulation (2.2.7)

AI-03: Bundle Signing

Level: L3 | Enforcement: Scanner

Rationale: Signatures bind bundles to publisher identity. Without signatures, anyone who gains registry access can publish under any name. Signatures provide cryptographic proof of publisher intent.

Requirements:

• Bundle MUST include cryptographic signature
• Signature MUST cover manifest hash and SBOM hash
• Signature MUST be verifiable against publisher identity

What MUST Be Signed:

Signed Payload Format:

{
  "mtf_version": "0.1",
  "payload_type": "bundle_signature",
  "subject": {
    "name": "@scope/package-name",
    "version": "1.0.0",
    "manifest_sha256": "abc123...",
    "sbom_sha256": "def456..."
  },
  "timestamp": "2026-02-06T12:00:00Z",
  "signer_identity": "https://github.com/username"
}

Canonical Serialization:

Payload MUST use RFC 8785 (JSON Canonicalization Scheme) before signing.

Signing Mechanisms:

Signature File Locations:

Severity:

Threats Addressed: Publisher impersonation, malicious updates (2.2.4)

AI-04: Reproducible Builds

Level: L4 | Enforcement: Scanner

Rationale: Reproducible builds allow independent verification that published binaries match source code. If two builders produce identical output from identical input, tampering in the build process is detectable.

Requirements:

• Build process MUST produce bit-identical output from same source
• Manifest MUST declare reproducibility status
• Verification MUST be independently achievable

Manifest Declaration:

{
  "_meta": {
    "org.mpaktrust": {
      "build": {
        "reproducible": true,
        "instructions": "https://github.com/org/repo/blob/main/BUILD.md"
      }
    }
  }
}

Reproducibility Requirements:

Severity:

Threats Addressed: Build tampering, provenance gaps (2.2.5)

AI-05: Bundle Completeness

Level: L2 | Enforcement: Client

Rationale: Attackers may include undeclared files (executables, scripts) that manifest validation doesn’t detect. Completeness verification ensures bundles don’t contain unexpected executable content.

Requirements:

• Clients MUST scan extracted bundles for unexpected executable content
• Undeclared executable content MUST block installation
• Verification MUST occur before extraction to final location

Verification Steps:

1. Extract bundle to temporary location
2. Enumerate all files in bundle
3. Identify files referenced by the manifest (entry points, config files, dependency lockfiles)
4. Flag any executable files not referenced by the manifest
5. BLOCK if unexpected executables found

Expected Files:

Files referenced by the manifest are considered expected:

Always Allowed:

Disallowed Unless Referenced:

Severity:

Threats Addressed: Phantom components (2.2.6)

3.3 Supply Chain (SC-)

Supply chain controls ensure that dependencies are known, tracked, free from vulnerabilities, and sourced from trusted origins.

SC-01: SBOM Generation

Level: L1 | Enforcement: Scanner

Rationale: Software Bill of Materials (SBOM) provides visibility into all components in a bundle. Without an SBOM, vulnerability scanning, license compliance, and incident response are impossible.

Requirements:

• Bundle MUST include an SBOM file
• SBOM MUST enumerate all direct and transitive dependencies
• SBOM MUST use a standardized format

Supported Formats:

Required Component Fields:

Depth Requirements:

Severity:

Threats Addressed: Dependency opacity, incident response gaps

SC-02: Vulnerability Scanning

Level: L2 | Enforcement: Scanner

Rationale: Known vulnerabilities in dependencies are a primary attack vector. EPSS and CISA KEV data help prioritize exploitable vulnerabilities over theoretical ones.

Requirements:

• All components in SBOM MUST be scanned for known vulnerabilities
• Blocking thresholds MUST consider exploitability, not just severity
• Publishers MAY provide VEX statements to document non-applicability

Data Sources:

Blocking Criteria:

A vulnerability MUST block publication if ANY of:

Non-Blocking (Warning):

VEX Statement Handling:

Publishers MAY provide VEX statements to override findings:

Severity:

Threats Addressed: Known vulnerabilities, dependency hijacking (2.2.3)

SC-03: Dependency Pinning

Level: L2 | Enforcement: Scanner

Rationale: Unpinned dependencies allow attackers to inject malicious versions without changing bundle source. Pinning with integrity hashes ensures reproducible, verifiable installations.

Requirements:

• All dependencies MUST be pinned to exact versions
• Dependency lockfiles MUST include integrity hashes
• Version ranges MUST NOT appear in production dependencies

Lockfile Requirements by Ecosystem:

Prohibited Patterns:

Severity:

Threats Addressed: Dependency hijacking (2.2.3), non-reproducible builds

SC-04: Lockfile Integrity

Level: L2 | Enforcement: Client

Rationale: Lockfiles can be tampered with between publication and installation. Clients must verify that installed dependencies match the publisher’s declared lockfile.

Requirements:

• Clients MUST verify installed dependencies against bundle lockfile
• Hash mismatches MUST block installation
• Lockfile MUST be covered by bundle signature (L3+)

Client-Side Lockfile:

{
  "lockfileVersion": 1,
  "installed": "2026-02-06T12:00:00Z",
  "packages": {
    "@acme/mcp-server": {
      "version": "1.2.3",
      "resolved": "https://registry.example/bundles/@acme/mcp-server-1.2.3.mcpb",
      "integrity": "sha256-...",
      "mtf_level": 2
    }
  }
}

Severity:

Threats Addressed: Supply chain tampering, mirror poisoning

SC-05: Trusted Sources

Level: L3 | Enforcement: Scanner

Rationale: Dependencies from untrusted sources bypass ecosystem security controls. Approved registries have malware scanning, account verification, and incident response processes.

Requirements:

• All dependencies MUST be sourced from approved registries or an explicitly configured organizational allow-list
• Non-approved sources MUST block publication unless allow-listed
• Git dependencies require SLSA attestation

Approved Registries:

Restricted Sources (Require Explicit Allow-List):

Severity:

Threats Addressed: Malicious registries, dependency hijacking (2.2.3)

3.4 Code Quality (CQ-)

Code quality controls verify that bundle source code follows secure coding practices and does not contain known malicious patterns.

CQ-01: Secret Detection

Level: L1 | Enforcement: Scanner

Rationale: Secrets committed to bundles are immediately exploitable. API keys, tokens, and credentials in published code are harvested by automated scanners within minutes of publication.

Requirements:

• Scanner MUST detect high-confidence secret patterns in all source files
• Bundle MUST NOT contain detected secrets
• Detection MUST cover at minimum:

Verification:

Severity:

Threats Addressed: Credential exposure, account takeover

CQ-02: Malware Patterns

Level: L1 | Enforcement: Scanner

Rationale: Known malware patterns in package ecosystems are well-documented. Blocking these patterns prevents low-effort attacks that have historically compromised npm, PyPI, and other registries.

Requirements:

• Scanner MUST detect known malicious patterns
• Bundle MUST NOT contain detected malware patterns
• Detection MUST cover:

Verification:

Severity:

Threats Addressed: Malicious packages, supply chain attacks (2.2.3)

CQ-03: Static Analysis

Level: L2 | Enforcement: Scanner

Rationale: Static analysis catches common security anti-patterns (injection, unsafe deserialization, shell commands) before code executes.

Requirements:

• Server code MUST pass static security analysis with no HIGH severity findings
• Analysis applies to server source code only, not bundled dependencies

Tool Requirements:

Severity Mapping:

Exclusions:

• Dependency directories: deps/, node_modules/, vendor/, site-packages/, .venv/
• Test files: *test*, *spec*
• Inline suppressions: # nosec: <reason> or // nosec: <reason> (justification required)

Severity:

Threats Addressed: Injection attacks, unsafe code patterns (2.2.7)

CQ-04: Input Validation

Level: L3 | Enforcement: Scanner

Rationale: MCP tools receive input from LLMs, which may be influenced by malicious prompts. Typed schemas provide a defense layer against malformed or malicious input.

Requirements:

• Tool handlers MUST use typed schemas for input validation
• Validation MUST occur at handler entry point, before business logic

Acceptable Validation Approaches:

What Qualifies:

# Good: Pydantic model
class GetWeatherInput(BaseModel):
    location: str
    units: Literal["celsius", "fahrenheit"] = "celsius"

@tool
def get_weather(input: GetWeatherInput) -> str:
    ...

What Does NOT Qualify:

# Bad: Untyped dict
@tool
def get_weather(input: dict) -> str:
    location = input.get("location")  # No validation
    ...

Severity:

Threats Addressed: Injection via malformed input, type confusion

CQ-05: Safe Execution Patterns

Level: L3 | Enforcement: Scanner

Rationale: Certain code patterns enable arbitrary code execution or command injection. These are rarely necessary in MCP servers and indicate either malicious intent or dangerous design.

Requirements:

• Server code MUST NOT use unsafe execution patterns
• Exceptions require explicit justification via inline suppression

Blocked Patterns - Python:

Blocked Patterns - JavaScript/TypeScript:

Safe Alternatives:

Severity:

Threats Addressed: Command injection, code execution, deserialization attacks

CQ-06: Behavioral Analysis

Level: L4 | Enforcement: Registry

Rationale: Static analysis cannot catch all capability mismatches. Behavioral analysis executes the MCP server in a sandbox and verifies that runtime behavior matches manifest declarations.

Requirements:

• Registry MUST execute bundle in instrumented sandbox before L4 certification
• Observed behavior MUST match declared permissions in manifest
• Violations MUST block publication

Monitored Behaviors:

Test Protocol:

1. Start MCP server in sandbox
2. Monitor all syscalls during initialization phase
3. Invoke each declared tool with valid test inputs
4. Compare observed behavior against manifest declarations
5. Generate behavioral report with pass/fail per requirement

Violation Severity:

Threats Addressed: Metadata manipulation (2.2.7), Initialization exfiltration (2.2.13)

3.5 Capability Declaration (CD-)

Capability declaration controls ensure that bundles transparently declare what they do, what access they require, and that declarations match actual behavior. These controls address MCP-specific threats including tool description poisoning and credential aggregation.

CD-01: Tool Declaration

Level: L1 | Enforcement: Scanner

Rationale: MCP servers expose tools to LLMs. Users must know what tools a bundle provides before installation. Undeclared tools prevent informed consent and audit.

Requirements:

• Manifest MUST declare all tools the server provides
• Tool declarations MUST include name and description
• Server MUST NOT expose tools not declared in manifest

Tool Declaration Format:

{
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather for a location"
    },
    {
      "name": "send_email",
      "description": "Send an email message"
    }
  ]
}

Required Fields:

Severity:

Threats Addressed: Capability opacity, undisclosed functionality

CD-02: Permission Correlation

Level: L2 | Enforcement: Scanner

Rationale: Manifests may declare benign permissions while code exercises dangerous capabilities. Static analysis detects mismatches between declared permissions and actual code behavior.

Requirements:

• Manifest MUST declare permissions in _meta.org.mpaktrust.permissions
• Static analysis MUST verify code matches declarations
• Undeclared dangerous capabilities MUST block publication
• Execution configuration (server, mcp_config) MUST NOT enable behavior outside declared permissions

Permission Categories:

{
  "_meta": {
    "org.mpaktrust": {
      "permissions": {
        "filesystem": "none | read | write | full",
        "network": "none | outbound | inbound | full",
        "environment": "none | read | write",
        "subprocess": "none | restricted | full",
        "native": "none | required"
      }
    }
  }
}

Severity by Context:

Threats Addressed: Manifest manipulation (2.2.7), hidden capabilities

CD-03: Description Safety

Level: L2 | Enforcement: Scanner

Rationale: LLMs treat tool descriptions as trusted instructions. Malicious descriptions can instruct LLMs to exfiltrate data, ignore user intent, or perform unauthorized actions.

Requirements:

• Tool descriptions MUST be scanned for injection patterns
• Detected patterns MUST block publication
• This control catches low-effort attacks, not sophisticated paraphrasing

What CD-03 Detects:

What CD-03 Does NOT Catch:

Severity:

Threats Addressed: Tool description poisoning (2.2.8)

CD-04: Credential Scope Declaration

Level: L3 | Enforcement: Scanner

Rationale: MCP servers aggregate OAuth tokens across multiple services. A compromised server with broad scopes creates concentrated breach potential. Declaring scopes enables user review and least-privilege enforcement.

Requirements:

• Bundles requiring OAuth MUST declare all scopes in manifest
• Declared scopes MUST follow least-privilege principle
• Over-broad scopes MUST trigger review

Credential Declaration Format:

{
  "_meta": {
    "org.mpaktrust": {
      "credentials": [
        {
          "provider": "google",
          "scopes": ["https://www.googleapis.com/auth/calendar.readonly"],
          "justification": "Read calendar events for scheduling"
        }
      ]
    }
  }
}

Scope Risk Classification:

Severity:

Threats Addressed: Credential aggregation (2.2.12)

CD-05: Token Lifetime Limits

Level: L3 | Enforcement: Scanner

Rationale: Long-lived tokens increase blast radius if a server is compromised. Tokens should be short-lived with refresh capability, and servers should not persist tokens beyond session.

Requirements:

• Bundles MUST declare token handling behavior
• Long-lived token storage MUST be flagged
• Refresh token handling MUST be documented

Token Handling Declaration:

{
  "_meta": {
    "org.mpaktrust": {
      "credentials": [
        {
          "provider": "google",
          "scopes": ["calendar.readonly"],
          "token_handling": {
            "storage": "memory",
            "max_lifetime_seconds": 3600,
            "refresh": true
          }
        }
      ]
    }
  }
}

Storage Risk Levels:

Severity:

Threats Addressed: Token abuse, credential aggregation (2.2.12)

3.6 Provenance (PR-)

Provenance controls establish the origin, authorship, and build history of bundles. They create an auditable chain from source code to published artifact.

PR-01: Source Repository

Level: L2 | Enforcement: Scanner

Rationale: Bundles without source repositories cannot be audited, forked, or independently verified. Source access is foundational for security review and incident response.

Requirements:

• Manifest MUST include repository field with valid URL
• Repository MUST be publicly accessible (or attestation-verified for private)
• URL MUST point to recognized hosting platform

Repository Declaration:

{
  "repository": {
    "type": "git",
    "url": "https://github.com/org/repo"
  }
}

Recognized Hosting Platforms:

Severity:

Threats Addressed: Unverifiable origin, audit impossibility

PR-02: Author Identity

Level: L2 | Enforcement: Registry

Rationale: Anonymous publishing prevents accountability during incidents. Verified identity enables contact for security disclosures and establishes trust signals for users.

Requirements:

• Manifest MUST include author field
• Publisher account MUST be verified per identity tier (PK-01)
• L3+ bundles MUST have multi-owner registration

Author Declaration:

{
  "author": {
    "name": "Publisher Name",
    "email": "publisher@example.com",
    "url": "https://example.com"
  }
}

Identity Verification Tiers:

Tier Requirements by Level:

Severity:

Threats Addressed: Unverified publisher (2.2.10), accountability gaps

PR-03: Build Attestation

Level: L3 | Enforcement: Scanner

Rationale: Build attestation proves that a bundle was produced by a trusted build system from specific source code. Without attestation, publishers could inject code not present in the source repository.

Requirements:

• Bundle MUST include SLSA provenance attestation
• Attestation MUST be signed by trusted builder
• Attestation MUST link bundle to source commit

Trusted Attestation Producers:

Attestation Signing/Verification:

Attestations SHOULD be signed and verified using Sigstore (Fulcio + Cosign) or equivalent mechanisms.

SLSA Provenance Format:

Attestations MUST follow SLSA Provenance v1.

Severity:

Threats Addressed: Build tampering, provenance gaps (2.2.5)

PR-04: Commit Linkage

Level: L4 | Enforcement: Scanner

Rationale: Commit linkage binds a bundle to an exact, auditable point in source history. With commit linkage, reviewers can diff the published bundle against the exact source state.

Requirements:

• Manifest MUST declare exact source commit
• Commit MUST be a 40-character lowercase hexadecimal SHA-1 string
• Commit MUST be reachable in declared repository
• Commit SHOULD be signed (GPG or SSH)

Commit Declaration:

{
  "_meta": {
    "org.mpaktrust": {
      "source": {
        "commit": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0",
        "signed": true,
        "tag": "v1.0.0"
      }
    }
  }
}

Severity:

Threats Addressed: Source mismatch, build provenance gaps (2.2.5)

PR-05: Repository Health

Level: L3 | Enforcement: Scanner

Rationale: Repositories with poor security practices are more likely to be compromised. OpenSSF Scorecard measures security hygiene including branch protection, CI security, and dependency management.

Requirements:

• Source repository MUST be analyzed with OpenSSF Scorecard
• Score MUST meet minimum threshold for compliance level
• Critical security checks MUST pass regardless of score

Score Thresholds:

Blocking Checks:

These checks MUST pass regardless of overall score:

Severity:

Threats Addressed: Insecure development practices, CI compromise

3.7 Registry Operations (RG-)

Registry operations controls govern how package registries manage namespaces, maintain index integrity, and handle security incidents. These controls apply to registries that adopt MTF.

Scope: RG controls apply only to MTF-compliant registries. Bundles distributed through other channels (npm, GitHub releases) cannot satisfy RG controls. Clients SHOULD warn when installing from non-compliant sources.

RG-01: Namespace Governance

Level: L2 | Enforcement: Registry

Rationale: Uncontrolled namespaces enable impersonation and confusion attacks. Scoped names (@org/package) establish clear ownership.

Requirements:

• L2+ packages MUST use scoped names (@scope/package-name)
• Organizations MAY reserve namespaces via verification
• Registries MUST block unauthorized use of reserved namespaces

Scoped Name Format:

@scope/package-name

Namespace Reservation Methods:

Severity:

Threats Addressed: Namespace confusion (2.2.1)

RG-02: Name Pattern Review

Level: L2 | Enforcement: Registry

Rationale: High-risk name patterns are prime targets for typosquatting and slopsquatting. Enhanced review catches suspicious registrations.

Requirements:

• Registries MUST analyze new package names for high-risk patterns
• High-risk patterns MUST trigger enhanced review
• Enhanced review requires additional verification

Detection Methods:

High-Risk Patterns:

Enhanced Review Requirements:

Package may proceed if ANY of:

Severity:

Threats Addressed: Typosquatting (2.2.1), Slopsquatting (2.2.2)

RG-03: Index Integrity

Level: L3 | Enforcement: Registry

Rationale: Compromised registry infrastructure could modify the package index. Signed indexes with chain integrity prevent undetected tampering.

Requirements:

• Registry MUST sign the package index
• Index updates MUST include chain integrity (previous hash)
• Clients MUST verify index signature before trusting contents

Signed Index Format:

{
  "version": 12345,
  "timestamp": "2026-02-06T12:00:00Z",
  "previous_hash": "sha256:abc123...",
  "packages": { ... },
  "signature": { ... }
}

Chain Integrity:

Each index contains the hash of the previous index, creating an append-only chain.

Severity:

Threats Addressed: Registry poisoning (2.2.9)

RG-04: Freshness Guarantees

Level: L3 | Enforcement: Registry

Rationale: Stale index data could cause clients to miss security updates or install revoked packages.

Requirements:

• Registries MUST include signed timestamps in index
• Clients MUST reject index data beyond staleness threshold
• Registries MUST update index within defined SLA

Staleness Thresholds:

Severity:

Threats Addressed: Stale data, replay attacks

RG-05: Revocation Feed

Level: L2 | Enforcement: Registry

Rationale: When bundles are compromised, clients must be able to block installation quickly.

Requirements:

• Registries MUST provide signed revocation feed
• Feed MUST be updated within 24 hours of revocation decision
• Clients MUST check revocation before installation

Revocation Feed Format:

{
  "timestamp": "2026-02-06T12:00:00Z",
  "signature": "...",
  "revoked": [
    {
      "package": "@evil/malware",
      "versions": ["*"],
      "reason": "malicious",
      "revoked_at": "2026-02-05T08:00:00Z"
    }
  ]
}

Revocation Reasons:

Takedown Response Times:

Severity:

Threats Addressed: Compromised bundles, malicious updates (2.2.4)

RG-06: Transparency Log

Level: L3 | Enforcement: Registry

Rationale: Transparency logs make registry operations auditable and detectable. If a registry is compromised, the log provides evidence of unauthorized actions. Without transparency, stealth revocations or unauthorized publications may go unnoticed.

Requirements:

• Registry MUST maintain an append-only transparency log of security-relevant events
• Registry MUST publish signed checkpoints (Merkle tree head, size, timestamp)
• Clients SHOULD verify checkpoint signatures
• Clients MAY verify inclusion proofs when available

Logged Events:

Checkpoint Format:

Registries MAY use Sigstore Rekor, RFC 9162 (Certificate Transparency), or equivalent Merkle tree structures.

Severity:

Threats Addressed: Registry poisoning (2.2.9), stealth revocations, unauthorized publications

RG-07: Bundle Digest

Level: L2 | Enforcement: Registry

Rationale: Bundle integrity must be verifiable without relying on content hashes inside the bundle itself. The registry computes a digest of the uploaded archive and serves it alongside download URLs, enabling clients to detect tampering in transit or at rest.

Requirements:

• Registry MUST compute SHA-256 digest of the bundle archive on upload
• Registry MUST store and serve the digest alongside the bundle download URL
• Registry MUST reject re-uploads where the archive content differs but name and version match
• Clients MUST verify the bundle digest after download before extraction

Digest Serving:

Registries MUST include the digest in API responses for package metadata:

{
  "name": "@acme/weather-server",
  "version": "1.0.0",
  "dist": {
    "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "url": "https://registry.example.com/bundles/@acme/weather-server/1.0.0.tar.gz"
  }
}

Client Verification:

1. Download bundle archive
2. Compute SHA-256 of the downloaded archive
3. Compare to the digest provided by the registry
4. BLOCK installation if mismatch; retry download once before failing

Severity:

Threats Addressed: Tampering in transit, registry poisoning (2.2.9)

3.8 Publisher Identity (PK-)

Publisher identity controls govern how publishers verify their identity, manage signing keys, and recover from security incidents.

PK-01: Identity Tiers

Level: L2 | Enforcement: Registry

Rationale: Different verification methods provide different trust levels. Higher-trust identities are required for publishing bundles with dangerous capabilities.

Requirements:

• Publishers MUST verify identity before publishing
• Identity tier MUST match compliance level requirements
• Dangerous permissions require high-trust identity

Identity Tiers:

Permission Restrictions by Tier:

Severity:

Threats Addressed: Unverified publisher (2.2.10)

PK-02: Key Rotation

Level: L3 | Enforcement: Registry

Rationale: Long-lived signing keys accumulate compromise risk. Regular rotation limits the window of exposure.

Requirements:

• Publishers using long-lived keys MUST rotate annually
• Key rotation MUST be announced in advance
• Previous keys MUST remain valid during transition period

Rotation Schedule:

Severity:

Threats Addressed: Key compromise, long-term credential exposure

PK-03: Compromise Recovery

Level: L3 | Enforcement: Registry

Rationale: When publisher credentials are compromised, rapid response limits damage.

Requirements:

• Publishers SHOULD register backup identity for recovery
• Registries MUST have documented compromise response process
• Compromised bundles MUST be revoked within defined SLA

Compromise Response Timeline:

Severity:

Threats Addressed: Account takeover, malicious updates (2.2.4)

PK-04: Account Succession

Level: L3 | Enforcement: Registry

Rationale: Publishers may leave projects or become unreachable. Orderly succession ensures packages remain maintainable.

Requirements:

• Registries MUST provide ownership transfer mechanism
• Transfers MUST include cooling-off period and notification
• Abandoned packages MUST be flagged for users

Ownership Transfer Process:

Abandonment Detection:

Severity:

Threats Addressed: Abandoned packages (2.2.11)

3.9 Installation (IN-)

Installation controls govern client-side verification, user consent, and recovery capabilities.

IN-01: Pre-Installation Checks

Level: L1 | Enforcement: Client

Rationale: Clients are the last line of defense before code executes.

Requirements:

• Clients MUST perform safety checks before installation
• Blocking checks MUST prevent installation
• Non-blocking checks MUST display warnings

Checks by Level:

Severity:

Threats Addressed: Installing revoked/compromised bundles

IN-02: Post-Download Verification

Level: L2 | Enforcement: Client

Rationale: Bundles may be tampered with during download. Post-download verification ensures integrity before extraction.

Requirements:

• Clients MUST verify bundle digest after download (RG-07)
• Clients MUST verify bundle completeness after extraction (AI-05)

Verification Sequence:

1. Download bundle archive
2. Verify bundle digest matches registry-provided digest (RG-07)
3. Extract to temporary location
4. Check for unexpected executables (AI-05)
5. Move to final installation location
6. Update client lockfile

Severity:

Threats Addressed: Tampering in transit, registry poisoning (2.2.9)

IN-03: User Transparency

Level: L1 | Enforcement: Client

Rationale: Users must understand what they’re installing before consenting.

Requirements:

• Clients MUST display package information before installation
• Users MUST explicitly consent to installation
• Critical findings MUST be prominently displayed

Information Display:

Consent Modes:

Severity:

Threats Addressed: Uninformed consent, social engineering

IN-04: Rollback Capability

Level: L2 | Enforcement: Client

Rationale: When an update introduces problems, users need to quickly restore the previous version.

Requirements:

• Clients MUST retain previous version after update
• Clients MUST provide rollback command
• Clients MUST handle compromise detection gracefully

Version Retention:

Rollback Command:

mpak rollback @acme/server         # Previous version
mpak rollback @acme/server@1.0.0   # Specific version
mpak rollback --list @acme/server  # List available

Compromise Response:

When a compromised package is detected:

1. Disable server immediately
2. Notify user with compromise details
3. Offer rollback if clean version available
4. Log incident for security review

Severity:

Threats Addressed: Failed updates, compromise recovery, malicious updates (2.2.4)

3.10 Update Lifecycle (UP-)

Update lifecycle controls govern how packages evolve, including version management, breaking changes, and deprecation.

UP-01: Update Notification

Level: L2 | Enforcement: Registry + Client

Rationale: Users must be informed of available updates, especially security fixes.

Requirements:

• Registries MUST provide update notification mechanism
• Clients MUST check for updates regularly
• Security updates MUST be distinguished from feature updates

Update Types:

Consent-Required Changes:

Automatic updates MUST NOT proceed if:

Severity:

Threats Addressed: Missed security patches

UP-02: Breaking Change Policy

Level: L2 | Enforcement: Registry

Rationale: Breaking changes without warning disrupt users. Semantic versioning provides a contract for predictable updates.

Requirements:

• Publishers MUST follow semantic versioning
• Breaking changes MUST increment major version
• Published versions MUST NOT be modified

MCP-Specific Breaking Changes:

Version Immutability:

Severity:

Threats Addressed: Unexpected breakage, version confusion

UP-03: Deprecation Process

Level: L2 | Enforcement: Registry

Rationale: Deprecated packages with no migration path leave users stranded.

Requirements:

• Deprecation MUST provide minimum notice period
• Deprecation MUST include migration guidance
• Deprecated packages MUST remain installable during notice period

Deprecation Timeline:

Severity:

Threats Addressed: Abandoned packages (2.2.11)

UP-04: Version Monotonicity

Level: L2 | Enforcement: Registry

Rationale: Non-monotonic version publishing enables attacks where old vulnerable content is published under version numbers that appear higher.

Requirements:

• Version numbers MUST be monotonically increasing per semver
• Registries MUST reject non-monotonic version publications
• Version history MUST be immutable

Monotonicity Rule:

V_new > V_existing (per semver ordering)

Valid Sequences:

1.0.0 → 1.0.1 → 1.1.0 → 2.0.0  ✓
1.0.0 → 1.1.0 → 1.0.1          ✗ (1.0.1 < 1.1.0)

Severity:

Threats Addressed: Version confusion, malicious updates (2.2.4)

4. Manifest Specification

4.1 Relationship to mcpb

MTF extends the mcpb manifest format. Bundles MUST be valid mcpb manifests. MTF adds security metadata under the _meta.org.mpaktrust namespace, following mcpb’s extension conventions.

Extension namespace: _meta.org.mpaktrust

MTF fields are placed under this namespace to:

• Avoid collision with future mcpb fields
• Clearly identify MTF-specific metadata
• Follow reverse domain notation conventions

Validation is two-step:

1. Validate manifest against mcpb schema (ensures bundle can execute)
2. Validate _meta['org.mpaktrust'] against MTF extension schema (ensures security metadata is correct)

4.2 mcpb Required Fields

These fields are defined by mcpb. MTF requires them at specified levels.

4.3 MTF Extension Fields

These fields are defined by MTF and live under _meta.org.mpaktrust.

4.3.1 Core Fields

4.3.2 Permission Categories

{
  "_meta": {
    "org.mpaktrust": {
      "permissions": {
        "filesystem": "none | read | write | full",
        "network": "none | outbound | inbound | full",
        "environment": "none | read | write",
        "subprocess": "none | restricted | full",
        "native": "none | required"
      }
    }
  }
}

4.3.3 Credential Fields (L3+)

{
  "_meta": {
    "org.mpaktrust": {
      "credentials": [
        {
          "provider": "google",
          "scopes": ["https://www.googleapis.com/auth/calendar.readonly"],
          "justification": "Read calendar events for scheduling",
          "token_handling": {
            "storage": "memory",
            "max_lifetime_seconds": 3600,
            "refresh": true
          }
        }
      ]
    }
  }
}

4.3.4 Provenance Fields (L3+/L4)

{
  "_meta": {
    "org.mpaktrust": {
      "source": {
        "commit": "a1b2c3d4e5f6...",
        "signed": true,
        "tag": "v1.0.0"
      },
      "build": {
        "builder": "https://github.com/slsa-framework/slsa-github-generator/...",
        "reproducible": true,
        "instructions": "https://github.com/org/repo/blob/main/BUILD.md"
      }
    }
  }
}

4.4 Example Manifests

L1 Basic

{
  "manifest_version": "0.3",
  "name": "my-weather-server",
  "version": "0.1.0",
  "description": "Simple weather lookup",
  "server": {
    "type": "python",
    "entry_point": "server.py"
  },
  "mcp_config": {
    "command": "python",
    "args": ["-m", "weather.server"]
  },
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather for a location"
    }
  ],
  "_meta": {
    "org.mpaktrust": {
      "mtf_version": "0.1"
    }
  }
}

L2 Standard

{
  "manifest_version": "0.3",
  "name": "@acme/weather-server",
  "version": "1.0.0",
  "description": "Production weather service",
  "author": {
    "name": "Acme Corp",
    "email": "mcp@acme.com"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/acme/weather-server"
  },
  "server": {
    "type": "python",
    "entry_point": "server.py"
  },
  "mcp_config": {
    "command": "python",
    "args": ["-m", "weather.server"]
  },
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather for a location"
    }
  ],
  "_meta": {
    "org.mpaktrust": {
      "mtf_version": "0.1",
      "level": 2,
      "permissions": {
        "filesystem": "none",
        "network": "outbound",
        "environment": "read",
        "subprocess": "none",
        "native": "none"
      }
    }
  }
}

L3 Verified

{
  "manifest_version": "0.3",
  "name": "@acme/calendar-sync",
  "version": "2.0.0",
  "description": "Sync calendar events across services",
  "author": {
    "name": "Acme Corp",
    "email": "mcp@acme.com",
    "url": "https://acme.com"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/acme/calendar-sync"
  },
  "server": {
    "type": "python",
    "entry_point": "server.py"
  },
  "mcp_config": {
    "command": "python",
    "args": ["-m", "calendar_sync.server"]
  },
  "tools": [
    {
      "name": "sync_events",
      "description": "Sync events between Google and Outlook calendars"
    }
  ],
  "_meta": {
    "org.mpaktrust": {
      "mtf_version": "0.1",
      "level": 3,
      "permissions": {
        "filesystem": "none",
        "network": "outbound",
        "environment": "read",
        "subprocess": "none",
        "native": "none"
      },
      "credentials": [
        {
          "provider": "google",
          "scopes": ["https://www.googleapis.com/auth/calendar"],
          "justification": "Read and write calendar events for sync",
          "token_handling": {
            "storage": "memory",
            "max_lifetime_seconds": 3600,
            "refresh": true
          }
        }
      ],
      "signature": {
        "type": "sigstore",
        "bundle": ".sigstore/manifest.sig.json"
      }
    }
  }
}

4.5 Schema Location

Normative Schemas:

External Schemas:

5. Signing & Attestation

5.1 Signing Envelope

5.1.1 Canonical Serialization

The signed payload MUST use RFC 8785 (JSON Canonicalization Scheme) to ensure deterministic serialization. Implementations MUST NOT sign pretty-printed or non-canonical JSON.

5.1.2 Payload Structure

{
  "mtf_version": "0.1",
  "payload_type": "bundle_signature",
  "subject": {
    "name": "@scope/package-name",
    "version": "1.0.0",
    "manifest_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "sbom_sha256": "d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592"
  },
  "timestamp": "2026-02-06T12:00:00Z",
  "signer_identity": "https://github.com/username"
}

5.2 Signing Methods

5.2.1 Sigstore Keyless (Preferred)

# Sign the manifest
cosign sign-blob --bundle manifest.sig.json manifest.json

# Verify
cosign verify-blob --bundle manifest.sig.json manifest.json

Sigstore binds signatures to OIDC identity (GitHub, Google, Microsoft) without long-lived key management.

OIDC Providers:

5.2.2 Long-Lived Keys

5.2.3 Signature File Locations

5.3 SLSA Provenance Format

Build attestations MUST follow SLSA Provenance v1:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "@scope/package-name",
      "digest": {
        "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v1.0.0",
          "repository": "https://github.com/org/repo",
          "path": ".github/workflows/release.yml"
        }
      },
      "resolvedDependencies": [
        {
          "uri": "git+https://github.com/org/repo@refs/tags/v1.0.0",
          "digest": {
            "gitCommit": "a1b2c3d4e5f6..."
          }
        }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@refs/tags/v1.0.0"
      },
      "metadata": {
        "invocationId": "https://github.com/org/repo/actions/runs/12345"
      }
    }
  }
}

Attestation File Locations:

5.4 VEX Statement Format

VEX (Vulnerability Exploitability eXchange) statements allow publishers to document non-applicability of vulnerabilities.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-001",
  "author": "publisher@example.com",
  "timestamp": "2026-02-06T12:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "@id": "CVE-2026-1234"
      },
      "products": [
        {
          "@id": "pkg:pypi/mypackage@1.0.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The vulnerable function is not called by this package"
    }
  ]
}

VEX Status Values:

Justification Values:

VEX File Locations:

VEX documents MUST be signed using the same mechanism as bundle signatures.

5.5 Verification Report Format

Scanners and registries produce verification reports documenting control compliance:

{
  "$schema": "https://mpaktrust.org/schemas/mtf/v0.1/report.json",
  "package": "@acme/server",
  "version": "1.0.0",
  "verified_at": "2026-02-06T12:00:00Z",
  "verifier": {
    "name": "mpak-scanner",
    "version": "1.0.0"
  },
  "level_claimed": 2,
  "level_verified": 2,
  "controls": [
    {
      "id": "AI-01",
      "name": "Manifest Validation",
      "status": "pass",
      "details": null
    },
    {
      "id": "SC-02",
      "name": "Vulnerability Scanning",
      "status": "pass",
      "details": {
        "vulnerabilities_found": 2,
        "vulnerabilities_blocking": 0,
        "vex_applied": 1
      }
    },
    {
      "id": "CQ-03",
      "name": "Static Analysis",
      "status": "warn",
      "details": {
        "findings": [
          {
            "severity": "MEDIUM",
            "file": "src/utils.py",
            "line": 42,
            "message": "Possible SQL injection"
          }
        ]
      }
    }
  ],
  "signature": "..."
}

6. Implementation Guide

6.1 Phased Adoption

The MCP ecosystem is early-stage. This roadmap prioritizes controls by impact and implementability.

Phase 1: Foundation

Deploy core security controls that provide immediate value with minimal friction.

Outcome: L1 compliance achievable.

Phase 2: Supply Chain

Add supply chain verification and identity controls.

Outcome: L2 compliance achievable.

Phase 3: Verified Distribution

Implement cryptographic verification and registry governance.

Outcome: L3 compliance achievable.

Phase 4: Full Assurance

Complete the assurance model with behavioral verification.

Outcome: L4 compliance achievable.

6.2 Minimum Viable Security

The smallest set of controls that meaningfully reduce supply chain risk:

These controls represent the minimum bar for publishing MCP bundles responsibly.

6.3 Tooling Landscape

Implementations can leverage existing open-source tooling for many checks:

MCP-Specific Controls (Require Custom Implementation):

6.4 CI/CD Integration

GitHub Actions: L2 Compliance

name: MTF Verification

on:
  push:
    tags: ["v*"]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Generate SBOM (SC-01)
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.json

      # Scan for secrets (CQ-01)
      - name: Secret Detection
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

      # Scan for vulnerabilities (SC-02)
      - name: Vulnerability Scan
        uses: anchore/scan-action@v3
        with:
          sbom: sbom.json
          fail-build: true
          severity-cutoff: high

      # Static analysis (CQ-03)
      - name: Static Analysis (Python)
        run: |
          pip install bandit
          bandit -r src/ -f json -o bandit-report.json
          # Fail on high severity
          bandit -r src/ -ll

      # Validate manifest (AI-01)
      - name: Validate Manifest
        run: |
          # Check manifest exists and is valid JSON
          jq . manifest.json > /dev/null
          # Check required fields
          jq -e '.name and .version and .tools' manifest.json

GitHub Actions: L3 Compliance (with Signing)

name: MTF L3 Release

on:
  push:
    tags: ["v*"]

permissions:
  id-token: write
  contents: read

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # ... L2 checks from above ...

      # Install Cosign
      - name: Install Cosign
        uses: sigstore/cosign-installer@v3

      # Sign manifest (AI-03)
      - name: Sign Manifest
        run: |
          cosign sign-blob \
            --bundle manifest.sig.json \
            --yes \
            manifest.json

      # Generate SLSA provenance (PR-03)
      - uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v1
        with:
          # ... builder config ...

6.5 Adoption Incentives

6.6 Scanner Implementation Notes

Control Enforcement Order

Scanners SHOULD evaluate controls in dependency order:

1. AI-01 Manifest Validation (required for all other checks)
2. SC-01 SBOM Generation (required for SC-02)
3. CQ-01, CQ-02 Secret/Malware (immediate threats)
4. CD-01 Tool Declaration (required for CD-02, CD-03)
5. Remaining controls in any order

Failure Modes

Performance Considerations

7. Specification Roadmap

7.1 Version Progression

7.2 Why Phased?

MCP-specific threats require both supply chain and runtime controls. v0.1 focuses on supply chain because:

1. Tooling exists. SLSA, Sigstore, SBOM generators, and vulnerability scanners are mature.
2. Foundation first. Runtime controls need signed manifests and declared capabilities.
3. Adoption enables enforcement. Behavioral analysis requires registry infrastructure.

Appendix A: Control Quick Reference

A.1 Master Control Index

Total: 41 controls

A.2 Controls by Enforcement Point

Appendix B: Controls by Compliance Level

B.1 L1 Basic (7 controls)

B.2 L2 Standard (+19 = 26 controls)

Includes all L1 controls, plus:

B.3 L3 Verified (+12 = 38 controls)

Includes all L1 + L2 controls, plus:

B.4 L4 Attested (+3 = 41 controls)

Includes all L1 + L2 + L3 controls, plus:

B.5 Level Comparison

Appendix C: Open Questions

Issues surfaced during specification development that require resolution in future versions.

C.1 Detection Limitations

Tool description poisoning (CD-03): Pattern matching catches obvious attacks but sophisticated paraphrased instructions evade detection. No production-ready semantic analysis exists. This control provides baseline protection, not comprehensive defense.

Name squatting (CQ-06): Detection combines name similarity analysis with publisher trust signals. Accuracy depends on threshold tuning for similarity metrics.

C.2 Behavioral Analysis Implementation

CQ-06 specifies what behavioral analysis MUST verify. Implementation approaches include:

• OpenSSF Package Analysis: Foundation for sandbox infrastructure
• Container sandboxes: Docker/Podman with seccomp profiles
• eBPF tracing: Low-overhead syscall monitoring
• Firecracker/gVisor: Lightweight VM isolation

Registries implementing CQ-06 SHOULD publish their implementation details.

C.3 Container Image Verification

Section 4 specifies container handling at a high level. Open questions:

• How do OCI attestations integrate with MTF attestation format?
• Should container layers be individually verified or only final image?
• How do multi-arch images affect reproducibility requirements?

C.4 Transitive Dependency Provenance

MTF requires SBOM but doesn’t mandate provenance attestation for dependencies. For L4, should all transitive dependencies also require provenance?

Current treatment: RECOMMENDED for L4, not REQUIRED. Ecosystem maturity is insufficient.

C.5 Key Escrow vs. Keyless

Sigstore keyless signing is REQUIRED for L3+. However:

• Some enterprises require key escrow for compliance
• Air-gapped environments cannot use OIDC

Open question: Should MTF define an alternative key-escrow path?

C.6 Breaking Change Detection

UP-02 requires semver but doesn’t define breaking change detection. For MCP:

• Is tool removal a breaking change? (Yes, per current spec)
• Is permission scope reduction breaking? (No)
• Is OAuth scope reduction breaking? (No)

C.7 Cross-Registry Federation

This spec assumes a single authoritative registry. If multiple registries exist:

• How is namespace governance coordinated?
• How are revocations propagated?
• Which registry’s compliance level is authoritative?

Deferred: Wait for ecosystem to determine if federation is needed.

C.8 Multi-Signature / Threshold Signing

For L4 critical infrastructure, single-signer is a single point of compromise.

Open question: Should L4 require threshold signatures (e.g., 2-of-3 keys)?

Current treatment: Not addressed. PR-02 requires multi-owner but not multi-signature.

C.9 Signature Expiry

Signatures currently have no expiration. A bundle signed in 2024 remains “verified” indefinitely.

Open question: Should signatures have maximum validity periods? Should clients warn on old signatures?

Current treatment: RG-05 revocation handles known compromises; time-based trust decay not addressed.

Appendix D: Runtime Security Roadmap

This appendix describes controls planned for future MTF versions. These are informative, not normative for v0.1.

D.1 Runtime Isolation Controls (v0.2)

Controls for verifying bundle behavior matches declared capabilities at execution time.

Implementation notes:

• Requires registry-operated or client-side sandbox infrastructure
• Technologies: containers with seccomp, gVisor, Firecracker, eBPF

D.2 Protocol Security Controls (v0.3)

Controls requiring changes to the MCP protocol specification.

Dependencies:

• Requires MCP protocol version changes
• Coordination with MCP specification maintainers needed

D.3 Control Numbering

D.4 Feedback Requested

Input is specifically requested on:

1. Sandbox feasibility: What isolation technologies are practical for MCP server execution?
2. Protocol changes: What MCP protocol extensions would enable PT- controls?
3. Client vs. registry enforcement: Which runtime controls should clients enforce locally?
4. Performance impact: What latency is acceptable for runtime verification?

License

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

Copyright 2026 NimbleBrain, Inc.

Full license: https://creativecommons.org/licenses/by/4.0/