TL;DR: Frontier model weights often run on infrastructure the owner does not control, where privileged operators can read them in memory, according to Fortanix, and it argues that direct extraction risk requires hardware-enforced isolation, attestation-gated key release and GPU coverage rather than trust in the host. This shifts model protection from policy to proof, and makes deployment environment assurance a core governance decision.
At a glance
What this is: Fortanix argues that model IP is exposed when weights are decrypted in untrusted inference environments, and that confidential computing with attestation is the practical answer for protecting them in use.
Why it matters: For IAM and security teams, the key issue is who or what can be trusted to access sensitive model assets at runtime, which directly affects workload identity, key release policy and hosting decisions for AI programmes.
Context
Model protection for AI is not just a question of storage, because weights have to be decrypted to run inference and that creates an exposure window in memory. In practice, the problem is less about at-rest encryption and more about whether the runtime environment itself can be trusted with the plaintext model.
This article sits at the intersection of AI security and governance because model IP is a high-value asset that can be exposed by infrastructure administrators, weak attestation or poor host controls. The trust boundary matters just as much as the model architecture, which is why deployment choices now look more like security architecture decisions than procurement choices.
Key questions
Q: How should security teams protect AI model weights in third-party inference environments?
A: Security teams should require runtime confidentiality controls that keep model weights protected while in use, not just at rest. The practical standard is hardware-enforced isolation with attestation-gated key release, so decryption only happens inside a verified environment. If the host or accelerator cannot prove its state, the model should not be released.
Q: Why do administrator privileges still matter for model IP risk?
A: Administrator access matters because conventional infrastructure often allows privileged operators to inspect plaintext memory during inference. That means the model can be exposed without a breach in the usual sense. The risk is not only malicious abuse but also the fact that normal host access can be enough to reveal sensitive weights.
Q: What are the signs that a confidential computing deployment is incomplete?
A: The main warning signs are CPU-only attestation, key release that is not tied to verified measurements, and no clear statement about GPU coverage. Those gaps mean the deployment may look protected while the actual inference path remains outside the trusted boundary. If any of those pieces are missing, the control is incomplete.
Q: What is the difference between protecting model data at rest and in use?
A: 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.
Technical breakdown
Why model weights become exposed at inference time
Model weights can stay encrypted at rest and still become readable the moment inference starts. The processor needs plaintext access to perform computations, so conventional deployments place the model inside memory that the operating system, hypervisor or privileged administrator can potentially inspect. That is the core weakness: the protection disappears exactly when the model begins doing useful work. This is not a special AI flaw so much as a failure of the hosting boundary to preserve confidentiality in use. Practical implication: treat inference environments as part of the model protection surface, not as neutral infrastructure. See the AI Model Security Guide.
Practical implication: Require runtime confidentiality controls for any environment that handles model weights in memory.
How confidential computing changes the trust boundary
Confidential computing uses a trusted execution environment, or TEE, to encrypt and isolate memory below the operating system layer. For AI workloads, that boundary has to extend to the GPU because the actual inference work happens there. Without GPU coverage, the CPU enclave can be secure while the model is still exposed during the handoff or execution phase. Composite attestation matters because it verifies both the CPU and GPU components before sensitive material is released. Practical implication: verify that the full inference path, not just the host CPU, is inside an attested boundary. See the AI Security Maturity Model.
Practical implication: Confirm that both CPU and GPU are attested before any model secrets are released.
Why attestation must gate key release
Attestation is a cryptographic proof that the hardware and software state match expected values. In a secure design, encryption keys are released only after that proof succeeds, so the model is decrypted only inside the verified enclave. If key release happens before or regardless of attestation, the mechanism becomes telemetry rather than control. That distinction is critical because logging an untrusted environment does not prevent model exposure. Practical implication: make key release conditional on verified measurements and fail closed when the platform state changes.
Practical implication: Enforce hard-gated key release so decryption cannot occur outside a verified state.
Threat narrative
Attacker objective: Extract proprietary model weights or related model IP from the runtime environment without needing to defeat the model itself.
- Entry occurs when a model owner deploys weights to infrastructure that it does not control and must trust the host environment with decrypted runtime data.
- Credential or privilege abuse can then let a sufficiently privileged administrator, or anyone with equivalent access, inspect plaintext model weights in memory or storage.
- Impact is direct model IP extraction, which can enable cloning, resale or unauthorized reuse of the trained model.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Model IP protection has become a runtime governance problem, not a storage problem. The article shows that encryption at rest does not matter if the model must be decrypted for inference in an environment the owner does not control. That shifts the governance question from whether data is encrypted to whether the runtime boundary is provably trustworthy. Practitioners should treat model deployment as a control decision, not a hosting preference.
Attestation-gated access is the real control, because trust by contract does not protect high-value weights. The article's strongest point is that operators can have legitimate administrative access and still be the wrong trust domain for sensitive model assets. Agentic AI Identity Maturity Model is relevant here because model deployment increasingly depends on whether the platform can prove the identity and state of the execution environment before releasing secrets. Practitioners should require cryptographic proof, not assurances.
GPU visibility is the hidden gap in many confidential computing claims. A CPU enclave alone does not protect an AI model if the GPU executes the sensitive workload outside the attested boundary. That creates a false sense of coverage because the place where inference actually happens remains exposed. Practitioners should evaluate the full compute path, including GPU attestation, before accepting a confidential computing claim as meaningful.
Model builders need a named control concept here: attestation-gated model release. The article defines a practical pattern in which model keys are released only after hardware attestation succeeds and are withheld when the environment drifts. That is a tighter control than generic zero trust language because it ties decryption to measured state. Practitioners should make this the baseline for any third-party inference environment handling valuable model IP.
Query-based extraction remains a separate risk even when runtime confidentiality is strong. The article correctly distinguishes direct weight theft from API-based model stealing and side-channel leakage. That matters because a strong enclave does not solve overuse of public inference endpoints or leakage through response patterns. Practitioners should align model protection with the specific threat class instead of assuming one control covers all extraction paths.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: AI Model Security Guide
What this signals
Attestation-gated model release: this is the governance pattern model teams need when valuable weights are deployed outside owned infrastructure. The control only works if decryption is conditional on verified hardware state, because monitoring without refusal to release keys still leaves the model exposed.
Confidential computing will increasingly be judged by the quality of the trust boundary, not by whether the deployment uses the label. For AI programmes, the practical question is whether the runtime can prove its own integrity before model assets are exposed, and whether GPU execution is inside that proof boundary.
AI security teams should expect model IP protection to merge with workload identity, key management and environment attestation. That means deployment reviews will look more like control validation than infrastructure review, especially when the model is trained on sensitive proprietary data.
For practitioners
- Require GPU attestation in every deployment review Do not accept confidential computing claims that only cover the CPU path. Verify that the GPU execution environment is also attested and that the model cannot run on an unverified accelerator.
- Make key release conditional on attestation success Treat attestation as a hard gate, not a monitoring signal. Encryption keys should be released only after the platform state matches approved measurements and should never enter general system memory.
- Evaluate the full inference trust boundary Map every point where the model is decrypted, handed off, executed or monitored, including host OS, hypervisor and accelerator layers. The deployment is only as protected as its weakest runtime layer.
- Separate direct extraction risk from API theft risk Use different controls for host-level weight extraction, query-based distillation and side-channel leakage. Confusing these threats leads to gaps because each one requires a different control strategy.
Key takeaways
- Model weights are still exposed if they must be decrypted in a runtime the owner cannot verify or control.
- The article's core evidence is that direct extraction risk exists whenever privileged host access can read plaintext memory.
- The limiting control is attestation-gated release into a fully verified CPU and GPU boundary, not trust in the hosting provider.
Related NHI Mgmt Group resources: Agentic AI Identity Maturity Model · AI Security Maturity Model · AI Model Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Privileged infrastructure access can expose model weights and runtime secrets during inference. |
| Recommendation — Limit release of sensitive model assets to verified execution identities and controlled privilege boundaries. | ||
| NIST AI RMF | MANAGE — AI Risk Management and Governance | The article is fundamentally about governing where AI assets may run and under what trust conditions. |
| Recommendation — Define approval criteria for model deployment environments and enforce them before sensitive assets are released. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on whether infrastructure entitlements allow plaintext access to model weights. |
| Recommendation — Review entitlements so privileged hosts cannot expose model weights outside approved runtime boundaries. | ||
| MITRE ATLAS | TA0006 — Credential Access | The threat model includes direct extraction of model weights by privileged actors and compromised credentials. |
| Recommendation — Map model weight exposure paths to credential access and hunt for privileged extraction opportunities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key release and runtime access depend on controlled authenticators and secrets handling. |
| Recommendation — Apply authenticator lifecycle controls so model release keys are rotated, protected and gated correctly. | ||
Key terms
- Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Model Weight Extraction: Model weight extraction is the theft of a trained model's parameters from memory, storage or another runtime path. It is a direct intellectual property risk because the attacker does not need to retrain the model, only recover the asset that defines its behaviour and value.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org