FHE Prompt Privacy: The Visible Envelope Around an Encrypted Prompt

FHE Prompt Privacy

Disclosure: AI tools were used for source collection and editorial review. The article was written by a human author, who checked the facts, code, and conclusions.

Crypto risk disclosure: This article is a technical explanation, not investment advice. It is not a recommendation to buy, sell or hold any cryptoasset.

Review FHE Prompt Privacy as a visible envelope, not as a slogan about hidden prompts. The payload can be ciphertext while the request still exposes plenty: when it moved, where it went, how large it was, which account or wallet route paid for it, which policy touched it, and which logs survived. The useful claim is smaller, and it lasts longer: the prompt payload was encrypted, and these surrounding fields stayed visible.

Payload

Start with the part that is real. OpenFHE's documentation describes fully homomorphic encryption as computation over encrypted data without access to the secret key, and it lists multiple FHE schemes in its implementation stack. That backs the payload claim: selected data can stay encrypted during computation.

A payload claim is not a request claim, though. Zama's FHEVM Solidity overview describes encrypted Solidity-compatible types and ciphertext handles, along with relayer configuration and access-control mechanisms. Those are useful boundaries, because they show encrypted data handling sitting inside a larger system surface.

Envelope

The visible envelope is the part of FHE Prompt Privacy a product review should force into the open. The field names below are an author model for review, not a FHEVM, TFHE-rs, OpenFHE, or OHTTP native format.

{
  "request_id": "fhe_prompt_call_2026_06_04_001",
  "encrypted_payload": {
    "payload_ciphertext_digest": "sha256:ciphertext_bundle",
    "ciphertext_size_bucket": "64-128kb",
    "cleartext_prompt_visible": false
  },
  "visible_envelope": {
    "request_time_bucket": "minute_bucket",
    "model_or_endpoint_id": "selected_inference_route",
    "account_or_wallet_route": "wallet_or_api_account_alias",
    "payment_or_quota_route": "quota_counter_or_payment_reference",
    "client_network_surface": "transport metadata outside encrypted payload"
  },
  "policy_surface": {
    "relayer_or_gateway_reference": "named integration component when source supports it",
    "decryption_policy_reference": "policy id or ACL reference",
    "visible_log_surface": [
      "request accepted",
      "ciphertext size bucket",
      "policy or decryption event status"
    ]
  },
  "allowed_claim": "The prompt payload was encrypted for this call, while the envelope fields above remained reviewable.",
  "blocked_claims": [
    "The user or session was anonymous.",
    "The model route was hidden.",
    "The payment or account route was hidden.",
    "No metadata leaked."
  ]
}

Size

Size deserves its own statement, because ciphertext is still an object that moves. TFHE-rs describes a Rust implementation of TFHE for Boolean and integer arithmetic over encrypted data, and its feature list includes ciphertext and server-key compression for efficient data transfer. That alone does not prove a metadata leak, but it is enough to put transfer size on the review list.

The practical claim should use buckets, not exact drama. A reviewer does not need to say the ciphertext reveals the prompt. They can say the service still exposes a size class, unless the system pads, batches, or otherwise controls the transfer surface. FHE Prompt Privacy reads stronger when that residual size field gets named instead of ignored.

Route

Route needs a statement too, because encrypted computation still happens somewhere. The FHE paper Drifting Towards Better Error Probabilities in Fully Homomorphic Encryption Schemes is useful here only for the cryptographic boundary: FHE schemes include key generation, encryption, decryption, and evaluation over ciphertexts, with correctness and security tied to failure probability and security notions. What the paper does not say is that endpoint choice, account route, or payment route disappears.

The route field is where AI x crypto systems tend to overclaim. A wallet-funded request, quota account, contract call, relayer path, or gateway path can stay visible even when the prompt text does not. A technical article should not turn that into a trading point or a token claim. It should keep the route as an operational privacy field.

Analogy

Oblivious HTTP is a useful warning, because encrypted messages still need deployment boundaries. RFC 9458 describes a protocol for forwarding encrypted HTTP messages so an origin server cannot link requests to a client, while it also places limited trust in forwarding nodes. The same RFC then spends real space on security, privacy, traffic-analysis, client-clock, and operational considerations.

That standard is not evidence that an FHE prompt system is private. The analogy is narrower than that: serious encrypted-message designs still discuss the surrounding envelope. Hold FHE Prompt Privacy to the same discipline before it claims more than payload confidentiality.

Decision

The safe decision is to publish the small claim and block the broad one. FHE Prompt Privacy can say that a selected prompt payload was encrypted for a named computation under a named policy. It should not say that the request, user, session, route, model choice, payment route, and logs became private, unless each of those surfaces has its own evidence.

Use this final check before accepting an encrypted-prompt claim:

Claim	Status	Reason
The prompt payload was encrypted for this computation.	Allowed if the implementation evidence names the encrypted fields.	Payload confidentiality is the narrow FHE claim.
The service cannot see the user's task.	Blocked unless route, timing, size, and model identifiers are controlled.	The envelope may still classify the workflow.
The wallet or account route is private.	Blocked unless a separate source proves that route is hidden.	FHE over payloads does not erase payment or account metadata.
The logs are safe.	Blocked unless retention, redaction, and debug behavior are written down.	Logging is a system policy, not a cryptographic side effect.

FHE Prompt Privacy becomes credible when the visible envelope ships as part of the artifact. The best review output is not a bigger slogan. It is a receipt that shows exactly which fields were encrypted, which fields remained visible, and which claims the team refused to make.

DEV Community