Security teams should require attested execution, encrypted-in-use processing, and explicit trust boundaries for model weights, prompts, and enterprise context. The goal is to move protection to the point where the workload runs, because storage and perimeter controls do not address exposure during inference or orchestration.
Why runtime trust has to be enforced inside the AI factory
Runtime enforcement changes the security model from “protect the assets around the AI system” to “control what the system can actually do while it is running.” That matters because model weights, prompts, retrieval context, tools, and orchestration logic all become part of the decision path at inference time. If trust is only checked at rest or at the perimeter, the system can still expose sensitive context, overreach on tool use, or execute with more authority than intended.
Security teams should treat the AI factory as a chain of trust, not a single workload. The important question is whether each step, from request to retrieval to inference to action, is continuously bound to a verified workload, a verified policy, and a bounded set of data and tools. That is why runtime controls need to sit alongside the execution layer, not only around the storage or network edge.
For teams building that chain, AI Infrastructure Workload Identity Guide is useful because it frames the identities behind pipelines, training jobs, model serving, and inference as part of the control surface rather than an implementation detail.
What “attested execution” and “encrypted-in-use” actually protect
Attested execution helps a platform prove that a workload is running in an expected environment with expected code and policy state. Encrypted-in-use processing reduces exposure while data is being handled in memory or during computation, which is the phase traditional storage encryption does not cover. Together, they raise the bar for tampering, unauthorized inspection, and untrusted infrastructure.
These controls are most valuable when the AI system is processing enterprise context, customer data, or prompts that shape downstream actions. They do not replace good authorization design, but they do make it harder for a compromised host, a rogue runtime, or a misrouted workload to observe or alter sensitive inference traffic. In practice, runtime trust should be tied to both workload identity and the integrity of the execution environment.
For broader platform design, AI Security Posture Management (AI-SPM) Guide is relevant because it connects AI asset discovery, misconfiguration, attack paths, and workload identities into one operational view.
How to separate trust boundaries for weights, prompts, and enterprise context
AI factories fail when every input is treated as equally trustworthy. Model weights need their own integrity controls, prompts need isolation from untrusted input, and enterprise context from retrieval systems or connectors needs explicit policy gates before it can influence the model. Each boundary answers a different question: can this artifact be trusted, can this request be used, and can this data be exposed to this runtime?
The most common design mistake is collapsing these three layers into one “secure model” assumption. Weights can be intact while prompts are poisoned, or prompts can be benign while the retrieved enterprise context is over-broad. Runtime trust means the system must evaluate each boundary independently and then enforce the narrowest safe combination of permissions, context, and action scope.
Teams standardising those boundaries can use AI Security Maturity Model to map the move from basic inventory and governance toward stronger runtime, identity, and control maturity.
Risk and Threat Considerations
When runtime trust is weak, the main failure mode is that the AI system becomes trusted to act on data or context that was never verified for that execution moment. That creates exposure to prompt injection, context poisoning, over-privileged tool use, and unintended disclosure during inference or orchestration.
Failure mechanism: The attacker or failure condition does not need to break storage or perimeter controls, because the system can be induced to make unsafe decisions once it is already running with excessive access, weak segregation, or unverified inputs.
Impact: Sensitive context can be exposed, models can be steered into unsafe outputs or actions, and downstream systems can receive unauthorized commands or data from a runtime that was treated as trusted by default.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | Runtime trust depends on isolating AI workloads and sensitive processing paths. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | AI factories often rely on service and workload identities at runtime. | |
| AC-6 — Least Privilege | AI tools and inference paths should only access the context and actions they need. | |
| Recommendation — Isolate AI execution paths so untrusted workloads cannot interfere with protected processing. Authenticate non-organizational workloads before allowing model or tool access. Restrict AI runtime permissions to the minimum required for each action. | ||
Practitioner Guidance
What to verify: Confirm that runtime trust is enforced by the execution environment itself, not only by adjacent controls such as network filtering, secrets storage, or model hosting policy. If the same workload can run unchanged in an untrusted context, the trust boundary is too loose.
What good looks like: Each inference path should be able to prove where it is running, what policy version it is under, what data it may see, and what actions it may trigger. If any of those cannot be answered at runtime, the platform is relying on trust that it has not actually established.
Practitioner takeaway: Design the AI factory so trust is recalculated at the moment of execution, because that is the only point where you can reliably bind identity, policy, context, and action to the actual workload.
Related resources from NHI Mgmt Group
- How should security teams design authorization for AI agents that need to call APIs across trust boundaries?
- How should security teams validate the trust boundary around AI runtime components before deploying local models?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams govern AI agents that can take runtime response actions?