At-rest protection secures the model before it is loaded, but it does not stop exposure once the model must be decrypted to run inference. Protection in use is harder and requires the runtime itself to enforce confidentiality, usually through hardware-backed isolation and attestation. For AI IP, that difference is decisive.
Why “at rest” and “in use” are different protection problems
Protecting model data at rest is about the stored artifact: weights, checkpoints, embeddings, prompts, fine-tune deltas, or training data on disk, in object storage, or in a repository. That is a storage and distribution control problem. Protecting model data in use is different because the model must be decrypted, loaded, or otherwise made available to execute inference, which creates a live exposure window the storage control alone cannot close.
The practical distinction is that at-rest controls reduce theft from repositories, backups, and transfer paths, while in-use controls have to protect the runtime state itself. If you only harden storage, you may still leak the model through memory inspection, process compromise, debugging paths, side channels, or a host that can observe plaintext during execution.
In other words, the question is not whether the model is encrypted somewhere in the pipeline, but where confidentiality is actually enforced. For highly sensitive AI IP, that distinction determines whether the model is merely harder to copy or genuinely protected while it is being executed.
What changes once the model has to run
Once inference starts, the model is no longer just a file. It becomes runtime state that may exist in memory, on a device, inside a container, or within an isolated execution environment. That means confidentiality now depends on the trustworthiness of the execution boundary, not just the strength of encryption at rest.
Protection in use usually requires hardware-backed isolation, attestation, or a comparable trusted execution design so the host cannot freely inspect decrypted contents. That is a materially stronger control than storage encryption alone because it tries to constrain what the platform can see while the model is being processed. Where that boundary is weak, the model may be protected on disk but exposed in execution.
This is also why “in use” controls are harder to implement and validate. You are no longer protecting a static object; you are proving that the runtime environment, the access path, and the measurement of the environment all support confidentiality while the model is active.
What the difference means for control selection and validation
The right control depends on the asset and the consequence of exposure. For a low-sensitivity model, at-rest encryption plus access control may be enough. For a proprietary or regulated model where disclosure would create major IP loss or security impact, you need to decide whether the deployment model can preserve confidentiality after decryption, not just before it.
That decision should be based on observable properties, not vendor claims alone. You want evidence that the runtime is isolated, that the expected code or enclave was actually measured, and that the model cannot be extracted through ordinary administrative access to the host. If you cannot establish that, then “protected” really means “protected only until execution begins.”
At-rest and in-use protection should also be treated as layered, not interchangeable. Strong storage encryption still matters because it reduces exposure during transfer, backup, and theft of the artifact. But if the model is valuable enough that exposure during execution is unacceptable, you need a separate in-use story.
Risk and Threat Considerations
The main risk is false confidence. Teams often assume encryption solves the problem, but a decrypted model in a reachable runtime can still be copied, inspected, or altered by an actor who gets host, process, or orchestration-level access.
Failure mechanism: The model is decrypted for inference, and the confidentiality boundary shifts from storage to execution. If the runtime cannot reliably isolate and attest to the environment, an attacker with sufficient platform access may recover the model from memory, tooling, or the execution host.
Impact: The result is IP loss, model theft, or exposure of proprietary behavior that was never meant to be observable outside the trusted runtime. In higher-value deployments, that can also undermine trust in the model’s integrity and provenance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V11 — Cryptography | Model protection depends on encryption and key handling across storage and runtime. |
| Recommendation — Apply V11 to protect model artifacts with sound encryption and key management. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | In-use protection relies on isolating the runtime that handles decrypted model data. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Trusted runtimes often depend on authenticating services or workload identities accessing the model. | |
| SI-7 — Software, Firmware, and Information Integrity | Protecting a model in use depends on the integrity of the runtime that handles decrypted content. | |
| Recommendation — Enforce process isolation so decrypted model state is harder to inspect or extract. Authenticate non-organizational runtimes before they can access protected model material. Verify runtime integrity before allowing access to sensitive model artifacts. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer hinges on trusting the runtime only after verification, not by location alone. |
| Recommendation — Treat runtime access to the model as continuously verified, not implicitly trusted. | ||
Practitioner Guidance
What to verify: Confirm whether the deployment can prove confidentiality after decryption, not just at rest. That means checking the runtime boundary, the attestation story, and who can inspect the execution environment.
Decision rule: If the model’s disclosure would be materially damaging, treat storage encryption as necessary but insufficient. Require an in-use protection design that matches the sensitivity of the model and the trustworthiness of the platform.
What practitioners underestimate: The operational burden is not just technical hardening, it is proof. If you cannot demonstrate that the runtime, and not only the storage layer, enforces confidentiality, then the model is still exposed at the point that matters most.
Practitioner takeaway: At-rest protection prevents easy copying of the artifact; in-use protection is what determines whether the model remains confidential when it is actually doing work.
Related resources from NHI Mgmt Group
- What is the difference between data at rest, data in motion, and data in use?
- What is the difference between protecting data at rest and protecting data in motion?
- What is the difference between encrypting data at rest and protecting service metadata in cloud platforms?
- What is the difference between protecting data in transit and protecting data at rest in a privacy programme?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org