Product
FHEnom for AI™
Architecture
How FHEnom for AI™ Works
Every stage of the AI pipeline operates on ciphertext. There is no point — from ingestion to output — where data exists in plaintext on the infrastructure.
Pre-Deployment: One-Time Setup
Model Encryption
Model weights, parameters, and architecture are encrypted using FHE before deployment. Existing pre-trained or newly trained models can be encrypted and deployed to any infrastructure — cloud, on-prem, or edge.Key Custody Configuration
Model key is triple-encrypted for TEE transfer. Key custody topology is established based on deployment scenario — on-prem, cloud, or mixed ownership.
Verified Before Keys are Released
Intel® Trust Authority Integration
In Intel TDX deployments, FHEnom for AI™ integrates with Intel® Trust Authority to cryptographically verify the hardware environment, guest operating system and FHEnom application before a wrapped session key is released.
RUNTIME: EVERY INFERENCE REQUEST
01
Client Encryption
Prompt encrypted at source with ephemeral session key. Data never leaves client control in plaintext.
02
Encryption Tokenizer
Tokenization occurs in ciphertext space. No plaintext tokens are ever generated.
03
FHE Inference
Encrypted model + encrypted prompt → encrypted output. GPU computes directly on ciphertext.
04
Decryption Tokenizer
Detokenization in ciphertext space. Encrypted tensor outputs are converted back to encrypted token sequences.
05
Client Decryption
Only the session key holder decrypts the response. Infrastructure never sees the output.
When Is a TEE Required?
Not all data requires the same level of protection. But when the classification demands it, only one tier delivers zero plaintext exposure.
Scenario 1
All Owners On-Prem
Model owner and data owner both on-premises. Physical security provides key custody.
Scenario 2
Cloud Model, Thick Client
Model in cloud, thick client on-premises. Client holds keys locally.
Scenario 3
Cloud + Thin Client
Cloud deployment with thin client. Keys must be custodied in hardware-hardened enclave.
Scenario 4
Mixed Ownership
Different organizations own model and data. TEE provides neutral key custody.
KEY MANAGEMENT
Two Key Lifecycles. Zero Exposure.
Model Key
Persistent — One-time Generation
Generated once from model owner’s secret. Encrypted with owner’s password. Either delivered to owner or destroyed.
If TEE present: stored inside TEE and never leaves in any form.
TEE-to-TEE transfer uses triple encryption: user password + new TEE public key + TLS. The model key never exists in plaintext outside a TEE under any circumstances.
Session Keys
Ephemeral — Per Session
Created and destroyed with each session. Every session is cryptographically isolated from every other session.
No session key survives beyond its session. No correlation possible between sessions.
Even if one session key were compromised, no other sessions are affected.
Infrastructure Isolation vs. Encrypted Execution
One decrypts your data to process it. One doesn’t. See the full comparison.
USE CASES
FHEnom for AI™ Use Cases
MSP
Secure Inference-as-a-Service
Managed service providers are deploying FHEnom for AI™ to offer encrypted AI inference as a managed service — a GPU-level security layer their customers can’t get anywhere else.Pharmaceutical
Drug Discovery IP Protection
AI models contain all R&D IP. Loss of the model means loss of the business. FHEnom for AI™ encrypts the model so it can run on shared infrastructure without exposure.Sovereign AI
Sovereign Cloud Burst
On-prem GPU capacity is finite. Data sovereignty regulations require jurisdictional control. FHEnom for AI™ eliminates the trade-off: data is encrypted before it leaves your premises and stays encrypted throughout processing on any cloud, in any jurisdiction. The cloud provider processes ciphertext — they cannot see the data, the model, or the results. Sovereignty is maintained mathematically, not by hardware attestation in a foreign datacenter.Systems Integrator
Regulated Training
A Fortune 500 global SI with 350K+ employees training models on regulated client data — without the SI ever seeing the data or the model. Customer encrypts, SI trains blind.INTEGRATION
Three Steps. Zero Code Changes.
FHEnom for AI™ deploys as a gateway VM that replaces your Al endpoint. Drop-in replacement — no application code changes required.
01
Encrypt the Model
Use the FHEnom for Al™ CLI to encrypt your model. Encrypted tokenizer replaces the standard tokenizer when the model is placed in service.02
Configure the Gateway
Admin CLI configures the FHEnom for AI™ gateway VM to point to your encrypted vLLM endpoint. Supports vLLM; other frameworks (like Bedrock) coming soon.03
Point Users to FHEnom for Al™
Users interact with the FHEnom for AI™ endpoint instead of direct vLLM. Same API. Same behavior. Fully encrypted.
SPECIFICATIONS
Technical Specifications
0.66ms
Encrypt/decrypt overhead for 4K tokensISO 27001
2022 certified
0μs
Inference latency difference vs. plaintext
vLLM
Supported framework; others (Bedrock) coming soon
100%
Output accuracy — bit-exact FP32 match
Gateway VM
Drop-in deployment, no code changes
Any GPU
Hardware-agnostic — no TEE required for compute
FIPS 140-3
Validated
FOR TECHNICAL EVALUATORS & INVESTORS
What Technical Evaluators Need to Know.
FHEnom for AI™ is built on proprietary cryptographic research — not a wrapper around open-source FHE libraries. Below: the architecture, the validation, and the security posture.
GET STARTED
See Encrypted Inference. Running Live.
Schedule a technical demo with our engineering team. Bring your model. We’ll encrypt it.
