TL;DR: AI factories move AI development on-premises or into hybrid data centres, giving organisations more control but also shifting responsibility for access management, auditing, and privileged control onto internal teams, according to Delinea. The critical gap is that high-performance AI environments can amplify unmanaged service identities, shadow AI, and over-privileged access faster than standard IAM processes can keep up.
At a glance
What this is: This is Delinea's analysis of how AI factories change the security model by moving AI workloads into environments where the organisation, not a cloud provider, must govern access, privilege, and audit controls.
Why it matters: It matters because identity teams now have to govern AI infrastructure that combines high-performance computing, service accounts, and privileged operations without the safety net of cloud-managed controls.
Context
AI factories are on-premises or hybrid environments built to develop, train, and deploy AI at scale. In this model, the security problem is not just infrastructure hardness. The issue is that identity, access, and accountability controls have to keep pace with highly specialised systems that run at machine speed.
Delinea's article frames the shift as a governance problem for AI, IT, and security teams: cloud convenience is replaced by direct responsibility for service identities, privileged access, software oversight, and auditing. That changes the operational baseline for any programme securing AI workloads, whether the environment is managed by platform teams, IAM, or PAM.
The article's starting position is typical of emerging AI factory deployments. The risk is not unique to one stack, but to the control gap created when organisations industrialise AI inside their own data centres without mature identity governance.
Key questions
Q: Where do AI factories fail when service accounts and admin rights are not separately governed?
A: They fail when the same identities are allowed to provision workloads, move data, and administer the environment without clear role separation. That creates unmanaged privilege, makes abuse hard to spot, and turns ordinary operational accounts into high-value attack paths. The control failure is not scale alone, but the absence of enforced boundary between workload execution and privileged administration.
Q: Why do AI agents increase identity and data access risk in cloud analytics platforms?
A: AI agents expand risk because they can act autonomously, reach sensitive data, and interact with connected services faster than manual review can keep up. In cloud analytics platforms, that means a single mis-scoped agent or integration can expose data, trigger unauthorised actions, or widen blast radius across downstream systems. Governance must account for both identity and the permissions granted to machine actors.
Q: How do security teams know if AI governance is working?
A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.
Q: What is the difference between zone-based access control and least privilege in AI factories?
A: Zone-based access control decides where an identity is allowed to enter and operate, while least privilege decides how much it can do once inside. In AI factories, both are needed because a user or service account can still be over-entitled even if the zone boundary exists. The practical difference is between limiting reach and limiting power.
Technical breakdown
Why AI factories create a new identity control plane
AI factories combine GPU clusters, orchestration layers, storage, and admin tooling into a tightly coupled environment. That architecture concentrates access decisions around users, services, schedulers, and maintenance accounts, so identity is no longer a side control. When training jobs, data movement, and model deployment all share the same physical and logical estate, account scope and privilege boundaries become the main security boundary. This is why NIST's HPC overlay focuses on zones, account management, authentication, and auditing rather than generic perimeter controls.
Practical implication: identity teams should treat the AI factory as a zone-governed access environment, not as ordinary server infrastructure.
How service accounts and privileged access become the scaling problem
AI factories rely heavily on service accounts for schedulers, data movers, model services, and control-plane functions. These identities often need privileged access for performance or automation, which makes them easy to under-govern when clusters scale quickly. Delinea's article highlights the operational pattern that matters: when machine identities are created ad hoc, tied to local processes, or left with broad access, the environment accumulates unmanaged privilege faster than manual review can absorb. The technical issue is not just account count, but the difficulty of maintaining ownership, lifecycle state, and least privilege across parallelised workloads.
Practical implication: account lifecycle and privilege scope for service identities need central ownership before cluster scale makes manual governance ineffective.
Why auditing in AI factories has to capture identity context
Logging alone does not create accountability unless each action can be tied to a user, service, or administrative role. In high-performance AI environments, audit data has to show which identity accessed a dataset, changed a configuration, or launched an unusual job. Without that context, forensic review becomes guesswork and compliance evidence collapses into raw event volume. The article also points to the need for performance-conscious logging, because AI factories can generate enough operational noise that weak audit design hides the very actions security teams need to see.
Practical implication: record identity-linked administrative and workload activity so investigation and compliance do not depend on inference after the fact.
Threat narrative
Attacker objective: The objective is to abuse the AI factory's identity model to gain unauthorised access to data, workloads, or privileged administrative functions.
- Entry begins when a user, service account, or malicious actor gains access to an AI factory identity that can reach compute, storage, or orchestration zones.
- Escalation follows when that identity carries excess privilege, allowing access to datasets, model pipelines, or administrative functions outside its intended scope.
- Impact occurs when unmanaged identities, shadow AI deployments, or privileged processes are used to expose sensitive data, alter jobs, or undermine compliance evidence.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
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
AI factories expose identity as the primary control surface. Once AI development moves out of managed cloud services and into on-premises or hybrid factories, identity governance stops being a supporting function and becomes the operating model. The environment is too distributed, too fast, and too privilege-heavy for perimeter thinking to carry the load. Practitioners should read this shift as a control reordering: who can act, under what role, and with what audit trail becomes the decisive design question.
AI factories amplify the machine-identity problem already present in modern infrastructure. Service accounts, schedulers, data movers, and control-plane identities are not incidental in these environments. They are the mechanism by which the factory works, which means unmanaged lifecycle, reused credentials, and broad entitlements scale into real exposure very quickly. The practitioner conclusion is straightforward: machine identity governance must be designed for industrialised workload velocity, not for static server estates.
Access review cadences are too slow for AI factory privilege churn. These environments create a constant stream of provisioning, elevation, and job-scoped access that traditional review cycles cannot meaningfully validate. The governance gap is not just missing controls, but a time mismatch between how quickly privileges appear and how slowly most IGA processes operate. Practitioners need to treat issuance and zoning as the point of control, because post-hoc review will always trail the work.
Shadow AI is a governance failure, not just an inventory issue. Unapproved models, tools, and local deployments appear when users can create high-performance workloads outside sanctioned paths. That is an identity and privilege problem because the hidden asset usually comes with hidden access, hidden ownership, and hidden audit scope. The field implication is that AI programme governance now has to cover who is allowed to instantiate compute, not only who is allowed to consume it.
Identity-centric security is what makes performance-governed AI feasible. The article is right to frame zone-based access, strong authentication, least privilege, and auditing as the practical bridge between HPC performance and security accountability. The implication for the market is that AI infrastructure and identity security are converging, and programmes that keep them separate will keep rediscovering the same blind spots.
What this signals
Identity governance has to move closer to issuance time in AI factories. Review-based programmes were built for access that stays around long enough to be certified, but AI factory identities often exist only for a job, a session, or a specific operational path. That means the control point shifts from periodic review to role assignment, provisioning, and zone placement.
Shadow AI is really unauthorised identity creation. The operational danger is not just an unknown model or unapproved tool. It is that those deployments often arrive with hidden service accounts, elevated permissions, and no clear owner, which leaves the security team managing a control problem they never saw initiated.
AI factories make NHI governance inseparable from platform engineering. Once compute orchestration, storage access, and administrative elevation all depend on machine identities, identity security is no longer a back-office policy layer. It becomes part of the build of the platform itself, and the programme has to be designed that way from the outset.
For practitioners
- Define zone-scoped identity boundaries Map access, management, compute, and storage zones to separate roles and entitlements so users and services only reach the zone they actually need.
- Centralise service account lifecycle control Inventory scheduler, data mover, and model-service identities, then assign ownership, provisioning, rotation, and revocation to one authoritative process.
- Separate admin elevation from workload execution Require dedicated administrator accounts for maintenance and block the pattern where privileged users also run AI jobs with root or equivalent rights.
- Bind audit logs to identities and zones Ensure session recording, command history, and access events can be traced back to the exact user or service account and the zone it entered.
- Control unsanctioned software and model deployment Restrict user-installed software and monitor for shadow AI projects, unapproved training instances, and unvetted tooling that bypass official oversight.
Key takeaways
- AI factories shift AI risk from cloud provider controls to internal identity governance, especially around service accounts and privileged access.
- The main exposure is not just scale, but the speed at which machine identities, shadow AI projects, and elevated roles can accumulate.
- Zone boundaries, lifecycle ownership, and identity-linked auditing are the controls that decide whether AI factories stay governable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | AI factories rely on many managed and unmanaged service identities that can become weak links. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns about elevated service accounts and admin rights in AI factories. | |
| NHI-10 — Human Use of NHI | The post describes users and admins leveraging non-human identities to run AI workloads and operations. | |
| Recommendation — Inventory and govern every service identity so unmanaged AI workloads cannot inherit hidden trust. Reduce excess entitlement on AI factory accounts and separate admin and workload privileges. Prevent people from reusing non-human identities for convenience in AI factory operations. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The threat discussion centres on credential theft and excessive privilege enabling abuse in AI factories. |
| Recommendation — Map AI factory identity abuse to credential access and privilege escalation to prioritise detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on entitlements, zone-based access, and least-privilege control in AI environments. |
| AU-2 — Comprehensive Audit Logging | Auditability is central because the article stresses session records and identity-linked accountability. | |
| Recommendation — Use PR.AA-05 to align AI factory entitlements with role and zone boundaries. Apply AU-2 to ensure AI factory actions are logged with user and service identity context. | ||
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.
- Zone-based access control: Zone-based access control divides an environment into separate trust zones, such as access, management, compute, and storage. In AI factories, the goal is to prevent any single identity from moving freely across the stack and to make privilege easier to audit and contain.
- Service Account Lifecycle: Service account lifecycle refers to the creation, use, review, rotation, and retirement of non-human identities that support applications or infrastructure. The key governance question is whether each account remains tied to a current business purpose and a named owner.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org