By Luigi Caramico, Founder and CTO of DataKrypto

Artificial intelligence is rapidly becoming a central repository of enterprise knowledge. As organizations deploy private AI models trained on proprietary data, a new category of risk is emerging. This risk is not driven by how users interact with AI, but by how AI systems themselves are accessed, copied, and attacked.

Most enterprises already encrypt sensitive data at rest and in transit. But AI does not create value while data sits on disk or travels across a network. It creates value while data and model parameters are actively processed during training and inference – which, with traditional encryption, requires that data be decrypted. That distinction matters.

If an attacker gains unauthorized access to the runtime environment, the AI itself can become a direct path to intellectual property loss.

AI Models Are Concentrated Repositories of Private Data

Modern models such as GPT, Claude, and LLaMA compress massive datasets into compact internal representations. This compression is what makes AI so effective, but it also introduces a unique risk in private deployments.

Instead of sensitive information being distributed across databases, applications, and file systems, AI consolidates years of proprietary knowledge into a single executable artifact: the model.

Once that model is exposed, the consequences are significant. An attacker does not need to breach dozens of systems or exfiltrate countless files. Access to the model or its runtime state is often enough.

Unauthorized Access Is the Core Risk

In private AI environments, data exposure can occur without a malicious prompt or user error. Some of the most damaging scenarios occur when attackers or insiders gain access below the application layer, where traditional user controls no longer apply.

These scenarios include cloud administrators or insiders accessing system memory, compromised operating systems or hypervisors, GPU memory scraping or driver-level attacks, exfiltration of model checkpoints or runtime snapshots, and accidental exposure of fine-tuned models or embeddings.

In these cases, the attacker bypasses the application layer entirely. Traditional controls, such as authentication, authorization, and prompt monitoring, offer little protection once the model or memory is exposed.

Why Traditional Encryption Fails During AI Execution

Encryption at rest and in transit protects data on disk and on the wire. AI, however, operates somewhere else.

During training and inference, model weights are loaded into system RAM and GPU memory. Inputs, embeddings, and intermediate numerical representations exist in clear form while the model runs. GPU VRAM holds the full operational state of the model. Once an attacker reaches this layer, encryption is no longer protecting data. The system may appear secure, but its most valuable assets are exposed at the exact moment they are used.

Enforcing Access With Trusted Execution Environments

End-to-end encryption protects models and data from unauthorized extraction throughout their lifecycle (?) While encryption protects AI models and data from unauthorized extraction, access control still matters. This is where Trusted Execution Environments, or TEEs, play a critical role.

In a private AI deployment, a TEE establishes a hardware-enforced trust boundary that tightly controls who can interact with the AI system.

With a TEE in place:

• Only authenticated and authorized code is allowed to execute inside the secure enclave.
• Cryptographic keys are released only after successful attestation of the runtime environment.
• Unauthorized binaries, modified runtimes, and unapproved operators are denied access by design.
• Administrative privileges outside the enclave do not grant visibility into enclave state or cryptographic keys.

This allows organizations to enforce strict policies around who can run the AI system, from where, and under what conditions, independently of the surrounding operating system or cloud infrastructure.

Importantly, the TEE does not determine what an authorized user may ask the model. Instead, it ensures that only explicitly authorized parties can access the AI service itself, and that all cryptographic material remains inaccessible to everyone else.

When combined with encrypted execution, the TEE serves as the gatekeeper, while end-to-end encryption ensures that even if the gate is attacked, nothing of value can be taken.

Defining the Threat Model

It is important to be precise about what problem this approach addresses.

The focus here is unauthorized access, including model theft, insider abuse, cloud or infrastructure compromise, memory scraping, GPU inspection, and unauthorized reuse of trained intelligence.

This does not address what an authorized user is permitted to ask the model. That is a governance and policy issue, not an encryption one.

Encrypting AI In Use: Closing a Critical Security Gap

At Datakrypto, we developed FHEnom for AI™ to protect private AI systems against unauthorized access at the computation layer.

Rather than focusing only on storage or transport, FHEnom protects the AI lifecycle where attacks actually occur – during execution.

FHEnom for AI protects private AI systems through the following controls:

• Encrypted model weights
  Model parameters remain encrypted at rest and in memory. GPU memory holds ciphertext, not usable weights.
• No plaintext in RAM or GPU memory
  Inputs, embeddings, tensors, and intermediate results remain encrypted throughout execution. Memory dumps yield no usable data.
• TEE-isolated trust boundary
  Only the tokenizer, embedding, and output layers execute inside a Trusted Execution Environment. Encryption keys are generated and retained exclusively within the enclave.
• No runtime model key exposure
  The core model executes without access to decryption keys. Compromising the operating system or GPU does not reveal the model.
• Session-level isolation
  Each inference session uses unique cryptographic keys, limiting exposure even in extreme breach scenarios.
• No performance trade-off
  Encrypted execution preserves native precision and GPU-level throughput, including for large-scale models.

Why This Matters in Practice

Consider a private AI system trained on internal legal documents, proprietary source code, or sensitive research data.

In a conventional deployment, stealing the model or scraping memory can expose years of accumulated knowledge. With encrypted execution, stolen models are cryptographically unusable. Memory snapshots reveal only ciphertext. Cloud insiders cannot inspect model behavior or content. Infrastructure compromise no longer equates to intellectual property loss.

The AI model and its inputs and outputs remain valuable to its owner and unusable to everyone else.

Key Takeaways

Private AI systems concentrate sensitive data into a single high-value target. Encryption at rest and in transit does not protect AI during computation. Unauthorized access most often occurs at the memory and runtime layer. Securing AI requires encryption in use, not just perimeter controls.

As private AI adoption accelerates, organizations must assume that infrastructure will eventually be compromised. The security model must ensure that even in that scenario, the intelligence itself remains protected.