Ciphertext-Based AI Inference Tool Design for the Model Context Protocol (MCP)

The Model Context Protocol (MCP) provides a standardized interface for AI-powered tools to interact with applications, autonomous agents, and large language models. In a typical deployment, an MCP client (e.g., an IDE plugin or an agent orchestrator) sends user input to an MCP server, which invokes one or more specialized tools to perform inference using local or remote downstream models. Currently, the input data, model parameters, and inference results are processed entirely in plaintext. This grants the MCP server and the tool provider full visibility into potentially user data. In scenarios involving privacy-critical workflows—such as analyzing medical imagery, product scans, or industrial defects—this plaintext exposure poses significant data leakage risks. Even if the server operator is deemed honest, a perimeter compromise of the remote tool endpoint could expose historical or active user payloads. Existing transport-layer solutions like TLS only protect data in transit; the data remains exposed at the computational endpoint. Emerging paradigms like Federated Learning focus on cooperative model training rather than cipertext remote inference. This contribution introduces a protocol extension for ciphertext-based AI inference within the MCP ecosystem. By leveraging Homomorphic Encryption (HE), an MCP tool can execute deterministic or approximated machine learning inference directly on encrypted inputs. While the base model can be trained in plaintext using conventional deep learning frameworks, it is converted into a homomorphic-friendly representation (e.g., approximating non-polynomial activation functions like ReLU with low-degree polynomials, and scaling weights) prior to its deployment within the secure MCP tool environment. The remote server handles exclusively encrypted data and public evaluation keys, generating encrypted outputs that are cryptographically opaque to all entities except the holding MCP client. To facilitate interoperability among decoupled clients and internet-facing tools, this document specifies standard JSON-RPC schema extensions for the MCP 'tools/call' sequence. This includes dedicated parameters for cryptographic algorithm identifiers, evaluation key references, and encrypted binary payloads encoded in text-safe formats. The remainder of this document is organized as follows: Section 2 defines terminology. Section 3 describes the problem statement and threat model. Section 4 outlines the design goals. Section 5 presents the system architecture. Section 6 specifies protocol schemas, and Section 8 discusses security considerations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Terms related to the Model Context Protocol (MCP) not explicitly defined in this section retain their meanings as specified in the base MCP specification . The following terms are defined for this extension:

Homomorphic Encryption (HE): A class of cryptographic primitives that permit specific mathematical operations to be performed directly on ciphertexts, yielding an encrypted result which, upon decryption, mirrors the output of those operations executed on the corresponding plaintext: exactly for exact schemes (e.g., BFV/BGV) and approximately, up to a bounded error, for approximate schemes (e.g., CKKS).
Ciphertext Inference: The execution of a machine learning model's forward pass inside an untrusted environment where inputs, intermediate activations, and outputs remain encrypted throughout the computation.
Plaintext Model: A standard machine learning model trained on unencrypted data, utilizing non-linear functions unsuited for direct homomorphic evaluation.
Homomorphic Model: A modified representation of a plaintext model structured for HE evaluation, wherein continuous non-polynomial functions are replaced by polynomial approximations and model weights are quantized or encoded into a format compatible with ciphertext algebraic circuits.
Public Key (Encryption Key): The cryptographic key used by the MCP client to encrypt plaintext inputs into ciphertexts. This key may be safely shared with the MCP server or tool providers.
Evaluation Key: A set of public cryptographic tokens (e.g., relinearization or Galois keys) required by the HE scheme to perform complex operations like homomorphic multiplication or rotations on ciphertexts without enabling decryption capabilities.
Secret Key (Decryption Key): The private cryptographic key held exclusively by the MCP client. It is strictly required to decrypt inference results back into plaintext and MUST NOT be shared with the MCP server or tools.
Encrypted Payload: The parameter or response block within an MCP JSON-RPC message containing ciphertexts, typically serialized using standard binary-to-text encodings (e.g., Base64) for transport compatibility.
Algorithm Identifier (Algorithm ID): A standardized token indicating the specific HE scheme (e.g., CKKS, BFV), ciphertext parameter set (e.g., polynomial modulus degree, coefficient modulus, and scale), and library version utilized.
Key Reference: A unique pointer or URI within the MCP message linking the payload to its corresponding evaluation keys, supporting both in-band negotiation and out-of-band key management mechanisms.
Ciphertext Inference Tool: A specialized MCP tool that advertises capability schemas requiring encrypted arguments and providing encrypted structural responses under the 'tools/call' framework.

This section describes the operational context, threat model, and security objectives for privacy-preserving, ciphertext-based AI inference within the Model Context Protocol (MCP) framework.

In a standard MCP deployment, an MCP client initiates tool invocations by sending structured requests to an MCP server. The server acts as an orchestration layer, routing these requests to one or more specialized inference tools. These tools process user prompts or high-dimensional unstructured data—such as image payloads for computer vision tasks—using trained machine learning models. The resulting inference outputs (e.g., classification labels, bounding boxes, or metadata) are returned to the client via the server. Under the current protocol specification, all components of this exchange—including user images, model parameters, and final inference results—are transmitted and processed in plaintext within the execution environment.

The threat model considers two primary categories of adversaries operating in an untrusted or semi-trusted network environment: Honest-but-Curious Server/Platform: The MCP server infrastructure is assumed to correctly execute the protocol routing and forward requests to designated tools. However, the entity operating the server (or an attacker with persistent read-only access) may attempt to observe, log, or harvest user data. For image recognition tools, this includes persisting raw pixel data, extracting embedded metadata (e.g., EXIF location data), or performing passive traffic analysis (such as inferring image characteristics). External Network Adversaries: Untrusted third parties operating on the communication path between the Client, the MCP Server, and the Remote Tool endpoints. These adversaries may eavesdrop on traffic, perform statistical side-channel analysis, or attempt to modify, delay, or replay messages. Exclusions: This threat model explicitly excludes malicious or compromised MCP clients, fully malicious tools that deliberately exfiltrate data outside the MCP boundary, and active physical attacks targeting the underlying cryptographic hardware or client-side memory leakage.

To address the privacy vulnerabilities and operational challenges identified in the problem statement, the ciphertext inference extension for MCP MUST satisfy the following design goals:

Confidentiality processing: The primary goal is to ensure that the intermediate MCP server and the remote tool provider never have access to the plaintext user data. The processing entity MUST NOT be capable of extracting raw pixels, semantic features, or final inference outputs from the ciphertexts during the execution of the tool workflow.
Functional Compatibility: The design must natively accommodate the algebraic structures and computational primitives required by mainstream machine learning models. For example, it can support ciphertext evaluations to Convolutional Neural Networks (CNNs) —such as tensor convolutions, matrix multiplications, and polynomial activation approximations—to execute practical computer vision tasks like image classification and object detection, etc.
Cryptographic Agnosticism: The protocol wire format and schema extensions MUST NOT be bound to a single homomorphic encryption paradigm (e.g., CKKS). The message format must incorporate flexible negotiation parameters, such as a structured Algorithm Identifier (Algorithm ID), allowing clients and servers to independently update their underlying cryptographic backends and parameter sets.
Efficient Key Management: Recognizing that evaluation keys in advanced HE schemes (e.g., bootstrapping or relinearization keys) can scale to hundreds of megabytes, the protocol design should avoid coupling key transmission directly with every individual 'tools/call' invocation. The architecture SHALL support decoupled key lifecycle management, including key reuse, server-side caching, and references to out-of-band key distribution channels to minimize network bandwidth consumption.

The ciphertext-based AI inference extension introduces a dual-domain architecture designed to decouple cryptographic operations from the core orchestration logic of the AI agent. This separation ensures that cryptographic keys never leave the user's trusted environment, while computationally expensive inference is offloaded to remote infrastructure.

The architecture is divided into two distinct trust boundaries: the Local Domain (Trusted) and the Remote Domain (Untrusted). Local Domain (Trusted Zone): This domain resides on the user's device or within a secure corporate perimeter. It consists of two primary components interacting via local MCP transport (e.g., stdio or local HTTP):

MCP Client (Agent): The primary orchestrator (e.g., an LLM-driven autonomous agent). It determines the workflow, issues 'tools/call' requests, and manages the state, but it does not inherently implement complex homomorphic cryptographic primitives.
Local Cryptographic MCP Server: A locally deployed MCP server providing specialized cryptographic tools (e.g., 'fhe_encrypt', 'fhe_decrypt'). This server manages the HE key pairs and performs the actual encryption of raw user data and decryption of the remote inference results. The Secret Key (Decryption Key) strictly remains within this server.

Remote Domain (Untrusted Zone): This domain represents the external, internet-facing infrastructure providing the AI capabilities.

Remote Inference MCP Server: A unified remote endpoint that handles the internet-facing MCP protocol (e.g., via SSE transport) and hosts the Homomorphic Model. It receives encrypted payloads, executes the ciphertext mathematical evaluations using the client's public Evaluation Key, and directly returns the encrypted inference results. The internal routing between the server interface and the specific execution tool is considered an implementation detail outside the scope of this protocol.

Figure 1 illustrates the structural components, trust boundaries, and the sequential data flow of MCP 'tools/call' interactions.

Obtain 'Key Ref' +-------------------------------------------------------------+ | Local Domain(Trusted Zone) | | | | +------------+ (1) tools/call: fhe_encrypt +------------+ | | | |============================>| Local | | | | | (2) Response: Ciphertext | Crypto | | | | |<============================| MCP Server | | | | MCP Client | | [Secret & | | | | (Agent) | (5) tools/call: fhe_decrypt | Eval Key] | | | | |============================>| | | | | | (6) Response: Plaintext | | | | +------------+<============================+------------+ | | ^ | | +------|------|-----------------------------------------------+ | | | | (3) tools/call: remote_inference {client_id, session_id, auth_token} | | (preceded by N x upload_ciphertext_chunk, by session_id) +------|------|-----------------------------------------------+ | | | Remote Domain | | +---|------V--------------------------------------------+ | | | (4) Response: Remote Inference MCP Server | | | | Encrypted [Homomorphic Model, Eval Key Cache]| | | | Result | | | | | | | +-------------------------------------------------------+ | +-------------------------------------------------------------+ ]]>

The execution of a ciphertext inference workflow is divided into two distinct phases. The MCP Client acts as the central router orchestrating all operations. Phase 1: Key Provisioning Phase To prevent excessive bandwidth consumption during each inference, the Evaluation Key SHALL be provisioned to the Remote Inference MCP Server independently. Once successfully provisioned, the Remote Server issues a 'Key Reference' (e.g., a URI or session token) which the Client stores for subsequent use. TODO: How the key (e.g., evaluation key) can be provisioned is ffs Phase 2: Ciphertext Inference Workflow The core inference sequence consists of three distinct request/response interaction pairs orchestrated by the client:

Local Encryption (Steps 1-2): The Client initiates a 'tools/call' request to the Local Cryptographic MCP Server containing the raw user data. The local server processes the plaintext and returns the Encrypted Payload.
Remote Inference (Steps 3-4): The Client issues a 'tools/call' request to the Remote Inference MCP Server. The request includes the Encrypted Payload, the 'Key Reference', and the Algorithm ID. The remote server evaluates the ciphertext through its homomorphic-friendly model and returns an Encrypted Result.
Local Decryption (Steps 5-6): The Client sends the Encrypted Result via a final 'tools/call' back to the Local Cryptographic MCP Server. The local server uses the Secret Key to decipher the payload and returns the final Plaintext Result to the Client.

This section specifies the standard JSON-RPC message structures required to execute the ciphertext inference workflow within the MCP ecosystem. All interactions are based on the standard MCP 'tools/call' method, extended with specific argument schemas for cryptographic payloads. [TODO: Define Step 0 - Key Provisioning Request and Response Formats.]

To initiate the workflow, the MCP Client sends a 'tools/call' request to the Local Cryptographic MCP Server to encrypt the raw user data. The target tool is generically referenced as 'fhe_encrypt'.

The 'client_id' identifies the calling client and selects its locally held HE key set; the corresponding Secret Key never leaves the Local Domain, while the matching Evaluation Key is the one provisioned to the Remote Inference MCP Server during the Key Provisioning phase. The 'image_path' is an absolute path to the plaintext input on the trusted host; only this reference is passed to the local server, so the raw image bytes never appear in any MCP message. The 'session_dir' designates the local directory into which the resulting input ciphertexts are written for the current inference session. The HE scheme and parameter set are determined by the key set bound to 'client_id', so no separate algorithm identifier is required in this request.

[TODO: Define Step 2 - The response from the Local Server containing the 'encrypted_payload' as a Base64 string.]

The encrypted input produced in Step 2 is typically too large to embed in a single JSON-RPC message; a CKKS-encoded image input can span tens to hundreds of megabytes across multiple ciphertext objects. MCP carries no native binary frame, so all binary data is conveyed as Base64 strings within JSON 'arguments'. Following the same decoupling principle applied to evaluation keys, the MCP Client therefore transfers the ciphertext to the Remote Inference MCP Server in bounded, Base64-encoded chunks via repeated 'tools/call' invocations, and only then triggers evaluation. Ciphertext Upload. Each ciphertext object is split into transport-sized chunks (e.g., 32 MiB before encoding). Every chunk is delivered as an individual 'tools/call' to the 'upload_ciphertext_chunk' tool, all sharing a common 'session_id'. The server stages and reassembles the chunks for that session prior to evaluation.

The 'session_id' groups all chunks (and the subsequent inference) of a single request. The 'file_name' identifies the target ciphertext object, while 'chunk_index' and 'total_chunks' let the server order the slices and detect when an object is complete. The 'chunk_b64' field carries one Base64-encoded slice whose decoded size MUST NOT exceed the negotiated maximum (e.g., 32 MiB). The 'auth_token' authorizes the upload. The server returns a per-chunk acknowledgement (for example, '{"ok": true, "file_name": "enc_input_ic0_phase0.bin", "chunk_index": 0, "chunk_bytes": 4194304}') and never reconstructs any plaintext. Inference Invocation. Once all chunks for the session are uploaded, the MCP Client invokes the remote inference tool, which references the staged ciphertext by 'session_id' rather than re-transmitting it. This is the core operational message transmitted over the untrusted network (e.g., via Server-Sent Events).

The 'client_id' acts as the Key Reference: the remote server resolves it to the client's previously provisioned, cached Evaluation Key set, so no key material is carried in the request. The 'session_id' references the encrypted input that was transferred to the remote server for this session; the server assembles and evaluates exactly that ciphertext set through its Homomorphic Model. The 'auth_token' is a bearer credential authorizing use of the client's cached keys and session; it is verified server-side against a stored hash and MUST be transmitted only over a confidentiality-protected channel. The 'omp_threads' field is an OPTIONAL hint for the degree of evaluation parallelism and does not affect the result. Because the HE scheme and parameter set are fixed by the referenced key set, no plaintext, key material, or separate 'algorithm_id' appears in this request.

Upon successful homomorphic evaluation, the Remote Inference MCP Server returns the encrypted inference results. The response strictly adheres to the standard MCP tool response structure, encapsulating the ciphertext within the 'content' array.

The 'text' field contains a serialized JSON string, following the MCP tool-response convention. The 'encrypted_logit_b64' field carries the Base64-encoded output ciphertext, i.e., the encrypted inference result, which is decryptable only with the client's Secret Key. The 'encrypted_logit_bytes' field is the size in bytes of the decoded ciphertext, useful for integrity and transfer checks. The 'profile' object conveys OPTIONAL evaluation metadata (e.g., 'infer_s', the homomorphic evaluation time in seconds). The server MUST NOT return any plaintext or semantic representation of the inference outcome.

To finalize the workflow, the MCP Client passes the remote 'encrypted_result' back to the Local Cryptographic MCP Server for decryption, invoking the 'fhe_decrypt' tool.

The 'client_id' selects the matching locally held Secret Key. The 'encrypted_logit_path' is a local path to the encrypted result obtained in Step 4: the client persists the Base64 ciphertext from the remote response to this file and passes only its path to the local server, which decrypts it with the Secret Key and structures the final plaintext result before returning it to the agent (see Step 6). As with encryption, the ciphertext is exchanged by local reference and is never carried back over a remote MCP message.

[TODO: Define Step 6 - The final response returning the plaintext structured data to the MCP Client.]

While the core protocol defined in Section 6 assumes that the Remote Inference MCP Server enforces default homomorphic configurations, practical deployments often require fine-grained control over computation. Variables such as multiplicative depth, ciphertext noise, and batch processing strictly govern the feasibility and performance of FHE operations. To facilitate more flexible ciphertext inference services and future protocol standardization, this section outlines recommended optional parameters. These parameters MAY be included within the 'arguments' object of the request or the 'structuredContent' object of the response to enable dynamic capability negotiation between the MCP Client and the Remote Server.

The following parameters allow the client to define the precise cryptographic context and payload structure before remote execution:

scheme_context: Specifies the underlying mathematical scheme beyond a simple Algorithm ID. For AI inference, this typically indicates 'CKKS' (for approximate floating-point arithmetic) or 'BFV/BGV' (for exact integer arithmetic), dictating the server's evaluation rules.
poly_modulus_degree & scale: Explicitly declares the polynomial modulus degree N (e.g., 8192, 16384), which determines the number of slots available in a single ciphertext (N/2 for CKKS, e.g., N=16384 yields 8192; N for BFV/BGV), and the scale factor essential for CKKS precision management.
coeff_modulus: The ordered chain of RNS prime moduli defining the ciphertext modulus. For CKKS this chain governs the available multiplicative depth (one level is consumed per rescaling) and, together with poly_modulus_degree, determines the achievable security level; the server uses it to validate that the requested computation fits within the modulus budget.
security_level: The targeted bit-security of the cryptographic context (e.g., 128, 192, or 256 bits). For RLWE-based schemes this is a function of the polynomial modulus degree and the total bit-length of the coefficient modulus, per the Homomorphic Encryption Security Standard (see also the FHE standardization effort in ). The server MUST reject any parameter set whose poly_modulus_degree and coeff_modulus do not meet the declared target, enabling weak-parameter requests to be refused before evaluation.
max_multiplication_depth: The client's estimated upper bound of consecutive homomorphic multiplications required for the task. The server SHOULD use this to pre-validate whether the requested inference exceeds the theoretical limit of the provided ciphertexts, aborting early to save computational resources.
input_packing_format: Defines how the high-dimensional data (e.g., image pixels) is mapped into the 1D ciphertext slots (e.g., "gip_2d", "nchw_interleaved"). This is critical for the server to determine the correct stride for Galois rotations during convolutional operations.
batch_size & slot_count: Indicates how many independent data samples are packed into the current ciphertext slots (SIMD operations). This allows the remote server to optimize resource allocation for batch inference.
galois_key_mappings: A dictionary mapping specific spatial rotation steps (e.g., strides for a 3x3 convolution window) to their corresponding Galois Key references. This enables the server to perform shifting operations on ciphertext slots efficiently.

Upon completing or failing the inference, the server SHOULD provide cryptographic telemetry to assist the client in parsing the result or orchestrating fallback workflows:

noise_budget_remaining: For exact schemes (BFV/BGV), the remaining invariant noise budget of the output ciphertext, measured in bits. If it approaches zero, the ciphertext may fail decryption. For approximate schemes (CKKS), where no such bit-budget exists, the server instead reports the remaining level (the count of unused primes in the coefficient-modulus chain) and the current scale, indicating the multiplicative headroom left before a re-encryption or bootstrapping workflow is required.
computation_depth_used: The actual multiplicative depth consumed during the inference. Clients can compare this against their estimates for auditing or future optimization.
output_shape: An array (e.g., [1, 84, 84]) describing the structural dimensions of the encrypted tensor. This is strictly required for the Local Cryptographic MCP Server to correctly unflatten the decrypted payload into meaningful semantic data (e.g., bounding boxes).
error_code: Standardized machine-readable exceptions specific to homomorphic operations (e.g., "ERROR_DEPTH_EXCEEDED", "ERROR_INVALID_GALOIS_KEY", "ERROR_NOISE_OVERFLOW").
requires_decryption: A boolean flag used for Agent orchestration. If true, it explicitly signals to the LLM/Agent that the current output is an opaque ciphertext and MUST be routed to a local decryption tool before any subsequent plaintext analysis tools can be invoked.

This section analyzes the fundamental security guarantees using FHE in MCP, and discusses trust boundaries, and protection mechanisms required to ensure the secure operation of the ciphertext inference extension. Plaintext Confidentiality at the Remote Server: The primary security guarantee of this protocol is that the Remote Inference MCP Server operates in a non-trusted environment regarding user data. Because all inputs, intermediate activations, and outputs are encrypted using a homomorphic scheme (e.g., CKKS) before leaving the local trusted domain, the remote server cannot derive any plaintext semantic information. Even in the event of a total server perimeter breach or insider compromise at the remote site, historical and active user data remains cryptographically secure. Isolation of the Local Cryptographic Server: Since the Local Cryptographic MCP Server is responsible for generating cryptographic keys, encrypting raw user assets (such as pixel data), and decrypting inference results, it handles highly plaintext. Consequently, the local server MUST be deployed within a secure zone or trusted domain (e.g., restricted to localhost). It MUST NOT be exposed to the public internet. PKI Principles for Key Provisioning: To prevent Man-in-the-Middle (MitM) adversaries from substituting the client's public Evaluation Keys with malicious keys (which could lead to targeted calculation failures or subtle cryptographic leaks), the Key Provisioning phase MUST adhere to Public Key Infrastructure (PKI) principles. Evaluation keys and their associated Key References SHOULD be cryptographically signed, authenticated, and distributed over trusted channels. This ensures that the Remote Server can verifiably bind an incoming evaluation key to a legitimate, authenticated MCP Client. Payload Integrity Protection: Homomorphic ciphertexts and cleartext RPC parameters are highly susceptible to active tampering attacks; subtle bit-flips or structural modifications by a network adversary can corrupt the algebraic circuits, leading to computational failures or potential side-channel leaks. Therefore, all 'tools/call' requests and responses transmitted between the Local Domain and the Remote Inference Server MUST implement robust integrity protection. In addition to transport-layer security (e.g., TLS), payloads SHOULD incorporate application-layer Message Authentication Codes (MACs) or signatures to ensure end-to-end data integrity from the Client to the Remote Server.