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

3.1. Operational Context

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.¶

3.2. Threat Model

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.¶

5.1. Architectural Domains

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):¶

1. 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.¶

2. 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.¶

1. 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.¶

5.2. Component Interaction Diagram

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

      (0*) Key Provisioning (Init) -> 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                                           |  |
|  |                                                       |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+

5.3. Operational Phases

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:¶

1. 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.¶

2. 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.¶

3. 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.¶

6.1. Step 1: Local Encryption Request (Client to Local Server)

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'.¶

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "tools/call",
  "params": {
    "name": "fhe_encrypt",
    "arguments": {
      "client_id": "agent_fe8354f2851b",
      "image_path": "/home/user/cat.jpg",
      "session_dir": "/runtime_mcp/sessions/session_20260617_8f3a9b"
    }
  }
}

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.¶

6.2. Step 2: Local Encryption Response

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

6.3. Step 3: Ciphertext Upload and Remote Inference Request (Client to Remote Server)

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.¶

{
  "jsonrpc": "2.0",
  "id": "up-014",
  "method": "tools/call",
  "params": {
    "name": "upload_ciphertext_chunk",
    "arguments": {
      "client_id": "agent_fe8354f2851b",
      "session_id": "session_20260617_8f3a9b",
      "file_name": "enc_input_ic0_phase0.bin",
      "chunk_index": 0,
      "total_chunks": 2,
      "chunk_b64": "base64_encoded_ciphertext_chunk...",
      "auth_token": "k7Qf6w2Jx0aB9dW3nT1uY5vH8sR4eL2"
    }
  }
}

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).¶

{
  "jsonrpc": "2.0",
  "id": "req-002",
  "method": "tools/call",
  "params": {
    "name": "remote_inference_cnn",
    "arguments": {
      "client_id": "agent_fe8354f2851b",
      "session_id": "session_20260617_8f3a9b",
      "auth_token": "k7Qf6w2Jx0aB9dW3nT1uY5vH8sR4eL2",
      "omp_threads": 9
    }
  }
}

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.¶

6.4. Step 4: Remote Inference Response (Remote Server to Client)

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.¶

{
  "jsonrpc": "2.0",
  "id": "req-002",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"ok\": true, \"encrypted_logit_b64\": \"base64_encoded_output...\", \"encrypted_logit_bytes\": 1048576, \"profile\": {\"infer_s\": 57.1}}"
      }
    ],
    "isError": false
  }
}

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.¶

6.5. Step 5: Local Decryption Request (Client to Local Server)

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.¶

{
  "jsonrpc": "2.0",
  "id": "req-003",
  "method": "tools/call",
  "params": {
    "name": "fhe_decrypt",
    "arguments": {
      "client_id": "agent_fe8354f2851b",
      "encrypted_logit_path":
        "/runtime_mcp/sessions/session_20260617_8f3a9b/enc_logit.bin"
    }
  }
}

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.¶

6.6. Step 6: Local Decryption Response

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

7.1. Extended Request Parameters (Client to 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 [HES] (see also the FHE standardization effort in [ISO-FHE]). 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.¶

7.2. Extended Response Parameters (Server to Client)

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.¶