AI factory build-out shifts security to runtime trust

At a glance

What this is: Fortanix says AI factories are being built faster than many security architectures can adapt, and that confidential computing is becoming the preferred way to protect AI workloads while they run.

Why it matters: This matters because AI factories concentrate sensitive models, prompts, and enterprise context in one runtime layer, so IAM, NHI, and platform teams need governance that protects use-time access rather than only storage and perimeter controls.

Context

AI factories are purpose-built environments for running AI models and agents at scale, with hardware, storage, orchestration, and networking tuned for token generation efficiency. The governance problem is that these environments concentrate sensitive data and decision-making into a runtime that cannot be secured well by perimeter thinking alone.

For identity and access teams, the important shift is that AI workloads are no longer just another application tier. They are becoming a new computing substrate where model weights, prompts, enterprise context, and delegated access all need runtime protection, especially in regulated and sovereign environments.

Key questions

Q: How should security teams design AI factories so trust is enforced at runtime?

A: 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.

Q: Why do AI factories create governance risk if security is added later?

A: Because architecture decisions, vendor integrations, and data flows harden quickly once the platform is in production. Security debt becomes expensive to unwind, and the organisation may already be committed to runtime patterns that expose models, prompts, or regulated data outside the trusted boundary.

Q: What breaks when confidential computing is not built into AI infrastructure?

A: The trust model breaks at the moment sensitive AI assets are processed. Without hardware-rooted protection, organisations rely on assumptions about operators, tenants, and surrounding controls that do not hold well for model theft prevention, data leakage reduction, or sovereign workloads.

Q: Should organisations prioritise runtime controls or privacy-preserving AI first?

A: Runtime controls should usually come first when the immediate concern is live misuse, because they limit what the model can do right now. Privacy-preserving techniques matter too, but they do not stop endpoint abuse, policy bypass, or anomalous access during operation. The order should follow the dominant risk in the pipeline.

Technical breakdown

Why AI factories change the security model

AI factories differ from general-purpose clouds because they are designed around one dominant workload pattern: large-scale model and agent execution. That changes the security target from generic infrastructure hardening to runtime protection of high-value assets such as model weights, prompts, and contextual data. In practice, the control problem shifts from where data is stored to where data is decrypted and processed. Confidential computing is relevant because it creates hardware-enforced trusted execution environments, reducing exposure to infrastructure operators and adjacent tenants. For identity practitioners, the parallel is clear: the security boundary moves closer to the workload itself, where access and processing actually happen.

Practical implication: Treat AI factory design as a runtime governance problem, not a perimeter or storage problem.

Confidential computing and confidential AI in practice

Confidential computing protects code and data while they are in use by isolating them inside attested hardware-backed environments. Confidential AI applies that model to AI-specific assets, including model weights, prompts, responses, and enterprise context pulled from systems such as collaboration platforms and databases. The security value is not only encryption at rest and in transit, but protection during inference and orchestration. That matters because many AI risks emerge after the data reaches the model, when traditional controls lose visibility. For teams responsible for IAM and NHI, this also affects who or what can invoke models, supply context, and receive outputs under governed conditions.

Practical implication: Define which AI assets must only be processed inside attested environments and make that a platform requirement.

Why retrofitting AI security creates governance debt

The article’s core warning is about timing. When security is added after AI factories and agent workflows are already deployed, the organisation inherits governance debt: architecture choices, vendor integrations, and operating assumptions become harder to change later. That is especially true for regulated workloads, where sovereignty, compliance, and evidence requirements become part of the operating model. The broader lesson is familiar from cloud and mobile transitions. Once scale arrives first, security becomes a rework exercise. In identity terms, the same pattern appears when delegated access and service credentials are expanded without a lifecycle model. AI factories magnify that risk because the runtime itself becomes a decision engine.

Practical implication: Build runtime trust controls into the reference architecture before AI factory roll-out becomes widespread.

Threat narrative

Attacker objective: The objective is to obtain sensitive AI assets or influence AI processing outcomes by exploiting weak runtime protection and delayed security design.

1. Entry begins when AI factories and AI-native applications are deployed on infrastructure that lacks runtime protection for sensitive assets.
2. Escalation occurs as model weights, prompts, enterprise context, and delegated access move through environments that are not protected by attested execution controls.
3. Impact follows when model theft, data leakage, compliance failure, or loss of sovereign control is discovered after architecture decisions are already baked in.

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

Runtime trust is becoming the control plane for AI infrastructure. AI factories concentrate model execution, enterprise context, and delegated access into a single environment where perimeter controls are no longer sufficient. The governance question is not whether security exists, but whether trust is enforced at the point of use. Practitioners should treat attestation and trusted execution as architectural requirements, not optional hardening.

AI governance debt is the new form of retrofitting risk. When organisations scale AI factories first and ask security questions later, they inherit design constraints that are expensive to unwind. That pattern mirrors earlier cloud and mobile transitions, but the blast radius is larger because AI factories also govern sensitive prompts, model assets, and enterprise data flows. Leaders should assume that delayed security becomes structural debt.

Confidential computing gives AI a more defensible identity model. AI workloads are not just applications, they are decision environments that rely on issued context, model access, and runtime privileges. By binding execution to attested environments, organisations narrow the trust window around sensitive processing. For NHI and agentic AI programmes, that means the identity of the workload and the place where it runs become inseparable.

Platform teams will need to govern AI factories the way cloud teams govern crown-jewel services. The article points to regulated sectors, sovereignty concerns, and end-to-end reference architectures as the pressure points shaping adoption. That makes AI factories a governance problem for security architecture, not just an infrastructure investment. Practitioners should expect internal control requirements to converge around runtime protection, data sovereignty, and evidence of trustworthy processing.

AI factory security will increasingly depend on controlling who can invoke, supply, and observe the workload. As agents, models, and enterprise data sources become connected, the access model needs to cover non-human actors as tightly as human users. The practical conclusion is that identity governance for AI must extend into the runtime, where credentials, attestation, and delegated context meet.

What this signals

AI factory governance will increasingly look like workload identity governance. As model execution becomes a core business substrate, teams will need to decide where privileged context is allowed to exist and who or what may invoke it. That makes the control problem closer to identity-bound runtime governance than to traditional infrastructure hardening.

Confidential AI is likely to become a platform selection criterion rather than a niche enhancement. Security and architecture teams should expect procurement, sovereignty, and compliance questions to converge around how workloads are attested, isolated, and observed in use.

For practitioners

• Define runtime protection as a non-negotiable AI architecture requirement Require attested execution, encrypted-in-use processing, and protected model assets in every AI factory reference design.
• Map sensitive AI assets to explicit trust boundaries Inventory model weights, prompts, responses, and enterprise context, then state where each can be decrypted and processed.
• Build sovereignty and compliance into platform selection Test whether the proposed AI stack can support regulated workloads without exposing customer data or model IP outside the trusted environment.
• Govern delegated access for agents and workloads Tie service identities, orchestration privileges, and data-source permissions to the minimum scope needed for each AI workflow.
• Create an AI security architecture review before scale-out Assess whether the current design will still hold when agent use, model volume, and sensitive data flows expand across the business.

Key takeaways

• AI factories concentrate sensitive model execution into a runtime where perimeter controls are no longer enough.
• The main security risk is not only data at rest, but exposure during inference, orchestration, and delegated context handling.
• Teams that wait to add confidential computing later will inherit avoidable rework, governance debt, and weaker trust assurances.

Key terms

• AI factory: An AI factory is an on-premise or hybrid computing environment built to train, deploy, and operate AI at scale. It combines GPU clusters, storage, orchestration, and identity controls into a single production system where access management and workload governance are tightly coupled.
• 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.
• Confidential AI: Confidential AI is the use of hardware and software controls to protect model data, prompts, and outputs while they are being processed. It reduces exposure to cloud operators, co-tenants, and attackers with infrastructure access. Defenders check memory isolation, encrypted processing paths, access controls, and logging boundaries.
• Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern security programmes. It helps practitioners connect identity control to the broader architecture decisions that shape AI and cloud trust.