Why do AI-accelerated platforms increase identity and access risk?

Why This Matters for Security Teams

AI-accelerated platforms do not just store data and run workloads. They centralise identity, permissions, compute, model access, experiment tracking, and often secret handling in one operating plane. That concentration means a single weak service account, token, or mis-scoped role can expose far more than one application. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but the blast radius is larger because AI platforms tend to chain together data pipelines and automated actions.

NHIMG research shows why this is not theoretical. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which becomes more dangerous when one platform identity can reach datasets, models, and downstream tools. The platform may look tightly managed on paper, yet its NHI estate often grows faster than governance can keep up. In practice, many security teams discover the issue only after a compromised token has already touched multiple systems, rather than through intentional access review.

How It Works in Practice

The main risk is not just “more identities.” It is that AI platforms create identity dependencies that are difficult to see and even harder to scope. A model training job may assume access to raw data, an orchestration service may inherit those permissions, and an agent or notebook may reuse the same token path for retrieval, evaluation, and deployment. That is why platform identity needs to be treated as a control plane issue, not a local application issue. OWASP’s Non-Human Identity Top 10 is useful here because it frames NHI failure as a lifecycle and governance problem, not just a secrets problem.

Operationally, teams should separate workload identity from human administrative access, then enforce short-lived, purpose-bound permissions for each job or agent. That usually means:

• Issuing ephemeral credentials for a single task, not long-lived keys for the whole platform.
• Evaluating authorization at request time with context such as dataset, model, environment, and risk score.
• Logging identity decisions alongside data access, tool invocation, and model actions so incident response can reconstruct the full chain.
• Using secrets managers and rotation policies to reduce the lifetime of tokens that could be reused across experiments or tenants.

The 52 NHI Breaches Analysis illustrates a broader pattern: once one non-human credential is exposed, attackers often pivot through connected systems rather than stopping at the first foothold. These controls tend to break down when platform teams rely on shared service accounts or broad project-level roles because the identity path becomes too reusable to contain.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance faster experimentation against stronger containment. That tradeoff is real in AI environments where data scientists expect rapid iteration and platform engineers want low-friction automation. Best practice is evolving, but there is no universal standard yet for how much autonomy a platform identity should have before it becomes an access risk.

Some environments need special handling. Multi-tenant AI platforms may require separate identity domains per team or per model family. Regulated workloads may need stronger proof of workload identity than a simple API token, especially when agents can call tools on behalf of users. In these cases, current guidance suggests combining NIST CSF 2.0 controls with lifecycle discipline from the Ultimate Guide to NHIs so identity, authorization, and revocation operate as one system. The main exception is highly ephemeral research sandboxes, where short-lived access can be acceptable if data exposure is genuinely low and teardown is automatic.

Security teams should also watch for hidden reuse. A token used for training may later be reused by a notebook, a CI pipeline, or an agentic workflow because the platform treats them as equivalent. That equivalence is convenient, but it also makes lateral movement easier. A platform becomes materially safer when each automated workload has a distinct identity, a narrow purpose, and a clear expiry boundary.

Related resources from NHI Mgmt Group

• Why do exposed AI development tools increase identity and access risk?
• Why do AI-driven attacks increase risk for identity and access management programmes?
• Why do service accounts or embedded credentials increase risk in AI control planes?
• Why do shared certificate keys increase machine identity risk?