🤖 AI

Secure Tool Manifest and Digital Signing Solution for Verifiable MCP and LLM Pipelines

This paper proposes a Secure Tool Manifest and Digital Signing Framework that enhances Model Context Protocols (MCP) by implementing cryptographically signed manifests and transparent verification logs to ensure the integrity, verifiability, and secure execution of Large Language Model pipelines in sensitive domains.

Original authors: Saeid Jamshidi, Kawser Wazed Nafi, Arghavan Moradi Dakhel, Foutse Khomh, Amin Nikanjam, Mohammad Adnan Hamdaqa

Published 2026-02-02

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Saeid Jamshidi, Kawser Wazed Nafi, Arghavan Moradi Dakhel, Foutse Khomh, Amin Nikanjam, Mohammad Adnan Hamdaqa

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are running a high-stakes kitchen where a very smart, but sometimes unpredictable, head chef (the Large Language Model or LLM) is preparing complex dishes based on orders from customers. This chef can use various tools—knives, ovens, blenders (the external tools)—to get the job done.

The problem is that in the current setup, anyone could sneak into the kitchen, swap out the chef's recipe card with a fake one, or trick the chef into using a dirty knife. If the chef follows a bad order, the food could be poisoned, and no one would know who gave the order or what actually happened. This is the vulnerability the paper addresses.

The authors propose a new system called the Secure Tool Manifest and Digital Signing Framework. Here is how it works, using simple analogies:

1. The "Tamper-Proof Recipe Card" (The Manifest)

Before the chef touches any tool, every single request must be written on a special, digital "recipe card" called a Manifest.

The Analogy: Think of this like a sealed, official envelope. Inside, it lists exactly what the chef is allowed to do.
The Twist: The paper separates the "customer's view" (what the user sees) from the "chef's view" (the internal technical details). This prevents the customer from accidentally (or maliciously) leaking secrets about how the kitchen works.

2. The "Notary Stamp" (Digital Signing)

Before the chef can even look at the recipe card, it must be stamped by a trusted Notary (a Hardware Security Module or HSM).

The Analogy: Imagine a notary public who checks the recipe card, verifies the rules, and then stamps it with a unique, unforgeable seal using a special ink (a digital signature).
The Result: If someone tries to change even a single letter on the card after the stamp is applied, the ink smears, and the card is instantly recognized as fake. The chef refuses to cook.

3. The "Public Ledger" (Transparency Logs)

Every time a recipe card is stamped and used, a copy of the receipt is added to a giant, public, unchangeable book called a Transparency Log (using something called a Merkle Tree).

The Analogy: Think of this like a blockchain or a public diary that everyone can read but no one can erase or edit. If you want to know what the chef did five minutes ago, you can look it up.
The Benefit: If the chef does something weird, you can prove exactly when it happened and who authorized it. You can't hide the evidence.

4. The "Speed Test" (Scalability)

The authors tested this system with up to 50,000 orders (a massive amount of cooking).

The Finding: They found that adding more orders didn't slow the kitchen down in a messy way. Instead, the system got faster and more efficient per order, almost like a well-oiled machine. It scaled "linearly," meaning if you double the orders, the time taken just doubles (which is expected), but it didn't crash or get bogged down.
The Analogy: It's like a highway that adds a new lane for every 1,000 cars, keeping traffic flowing smoothly even during rush hour.

5. The "Fairness Check" (Balanced Usage)

The system uses three different types of chefs (GPT-4, LLaMA, and DeepSeek).

The Finding: The system automatically balanced the work so that no single chef was overwhelmed while others sat idle. It was like a smart waiter who distributes tables evenly among all the cooks.
The Security: This prevents a bad actor from overwhelming just one chef to cause a crash (a Denial-of-Service attack).

6. The "Self-Correction" (Error Handling)

The system is designed to be "fail-closed."

The Analogy: If a recipe card looks even slightly suspicious, or if the timestamp is wrong (like a recipe from next year), the system immediately locks the door and says "No." It doesn't take a chance.
The Result: It successfully rejected all the fake or broken orders in their tests while letting the valid ones through.

Summary

In short, this paper builds a security guard, a notary, and a public recorder for AI systems. It ensures that when an AI uses tools, it follows a verified, signed, and recorded set of rules. It proves that you can make AI systems this secure without slowing them down, even when thousands of people are using them at once.

The paper does not claim this fixes the AI's "thinking" or makes it smarter; it only ensures that the actions the AI takes are safe, traceable, and impossible to fake.

Technical Summary: Secure Tool Manifest and Digital Signing Solution for Verifiable MCP and LLM Pipelines

1. Problem Statement

Large Language Models (LLMs) are increasingly deployed in sensitive domains such as healthcare and finance, yet their execution pipelines remain vulnerable to manipulation, unverifiable behavior, and adversarial attacks. While the Model Context Protocol (MCP) provides a foundation for structuring interactions between LLMs and external tools, existing implementations often lack verifiable enforcement and transparent validation of model actions.

Current control mechanisms define compliance policies but fail to prevent:

Unverified tool invocation: Allowing tools to be called without cryptographic proof of authorization.
Adversarial prompt manipulation: Techniques such as Tool Invocation Prompt (TIP) attacks that hijack execution flows.
Opaque runtime behavior: Lack of deterministic action traces and explicit context versioning.
Key concentration and timing side channels: Risks arising from asymmetric key dominance and timestamp variance that can leak workload patterns.

Existing solutions, such as runtime attestation or enclave-based approaches (e.g., Scanclave), often fail to address the probabilistic, tool-driven nature of LLM workloads or do not scale to heterogeneous multi-model deployments. There is a critical gap in system-level security that unifies cryptographic accountability with transparent, scalable execution pipelines.

2. Methodology

The authors propose a Secure Tool Manifest and Digital Signing Framework, a structured extension of the Model Context Protocol (MCP). The framework enforces a six-stage pipeline designed to ensure deterministic integrity, metadata separation, and transparent auditing.

Core Architecture

The framework operates through the following sequential stages:

Manifest Creation: Each LLM tool request is encapsulated into a deterministic manifest $M = (M_u, M_m, \tau)$ , where $M_u$ represents user-facing parameters, $M_m$ represents model-facing inputs, and $\tau$ is a freshness timestamp. This structure enforces information-flow separation to prevent leakage.
Policy Enforcement and Signing: Before execution, the manifest is evaluated against deterministic compliance rules $C(M)$ . If compliant, a digital signature $\sigma$ is generated using a Hardware Security Module (HSM) and the manifest's hash.
Verification: The system verifies the signature and policy compliance. Only manifests with valid signatures and passing policy checks proceed to execution.
Transparency Logging: Validated manifests are appended to an immutable transparency log integrated via a Merkle tree. This ensures forward integrity and allows for efficient inclusion proofs.
Audit Exporting: The system generates compact, cryptographically verifiable evidence tuples containing execution latency, verification latency, and Merkle root references.
Metric Collection: Temporal metrics and security overheads are tracked to analyze scalability and trade-offs.

Threat Model

The system assumes a probabilistic polynomial-time (PPT) adversary capable of intercepting communications, injecting payloads, and replaying manifests. However, the adversary cannot compromise underlying cryptographic primitives (collision-resistant hashing, EUF-CMA signatures) or the HSM. The framework mathematically bounds the probability of successful attacks (forgery, replay, tampering) to negligible levels ( $negl(\lambda)$ ).

Algorithmic Implementation

The methodology is operationalized through three interdependent algorithms:

Algorithm 1 (Manifest Creation & Signing): Constructs the canonical manifest, hashes it, enforces policy rules, and signs the digest.
Algorithm 2 (Verification & Logging): Validates signatures, appends entries to the Merkle log, and updates the root hash.
Algorithm 3 (Auditing & Metrics): Computes execution and verification latencies, generates output digests, and exports evidence for external auditors.

3. Key Contributions

The paper makes three primary contributions:

Framework Design: A novel Secure Tool Manifest and Digital Signing framework that defines a cryptographically signed manifest format for MCP-compliant LLM execution. It ensures manifest integrity, enforces metadata separation, and builds trust in execution pipelines.
Evaluation Methodology: A dual-perspective pipeline combining performance and security metrics to systematically assess trade-offs at scale. This provides a reproducible basis for future studies on secure LLM infrastructures.
System-Level Insights: The first comparative analysis of secure execution across different LLMs (GPT-4-turbo, LLaMA-3.5, and DeepSeek-V3). The study identifies and quantifies vulnerabilities such as asymmetric key dominance and timestamp variance, offering actionable guidance for resilient deployment.

4. Experimental Results

The framework was evaluated across workloads ranging from 100 to 50,000 manifest instances using three representative LLMs.

Scalability

Near-Linear Scaling: The system demonstrates near-perfect linear scalability with a regression fit of $R^2 = 0.998$ . The computational complexity converges to $O(\log N)$ for logging and $O(1)$ for signing/verification per request.
Overhead: The normalized security overhead remains below 5% ( $\delta < 0.05$ ) across all scales, confirming that cryptographic enforcement does not significantly degrade performance.

Fairness and Distribution

Model Utilization: Model usage converged to a balanced distribution of approximately 33% per model (GPT-4-turbo, LLaMA-3.5, DeepSeek-V3), with a fairness index $F = 0.97$ .
Key Usage: The study identified a vulnerability where a single key (dev-k1) dominated utilization (80% at scale), highlighting the need for adaptive key rotation strategies.
Severity Enforcement: The system exhibited adaptive enforcement, with "warn" and "block" outcomes increasing proportionally with adversarial stress, demonstrating a controlled feedback mechanism.

Verification and Reliability

Accuracy: The framework achieved an average verification success rate of 80% for valid executions while consistently rejecting invalid or forged manifests.
Latency Stability: Verification latency remained bounded (median 1.9ms for GPT-4-turbo) with low variance, preventing timing-based side-channel inference.
Error Behavior: While absolute error counts increased superlinearly due to specific revocation failures, the normalized error density stabilized asymptotically ( $\rho_E \to 0.15$ ), indicating the system does not suffer from cumulative verification risk.

5. Significance and Claims

The paper claims that the proposed framework successfully bridges the gap between model-centric safety research and system-level execution security. Its significance lies in:

Operationalizing Accountability: Unlike previous works that focus on post-hoc forensic analysis or isolated enclave attestation, this framework embeds proactive cryptographic enforcement and real-time transparency logging directly into the execution pipeline.
Scalable Trust: By demonstrating near-linear scalability and bounded overhead, the solution proves that high-assurance cryptographic mechanisms (signing, Merkle logging) can coexist with the low-latency requirements of regulated LLM deployments.
Mathematical Formalization: The work provides a formal stability envelope where empirical behavior (latency, fairness, error rates) converges with theoretical cryptographic bounds, offering a mathematically grounded approach to trustworthy AI.

The authors conclude that their framework establishes a foundation for verifiable, auditable, and fair LLM pipelines, essential for safety-critical domains where even minor execution errors or policy violations can lead to severe compliance and security consequences.