Why do GenAI programmes create new identity risk even when the models change?

Because the operational risk sits in the identities that call the models, not only in the models themselves. When teams switch providers or add tools, they often keep the same broad credentials, which expands exposure across data sources, logs, and downstream applications. The control failure is credential reach, not model brand.

Why This Matters for Security Teams

GenAI programmes change quickly, but the identity layer often does not. Teams swap model providers, add retrieval pipelines, and connect new tools while preserving the same broad API keys, service accounts, and cloud roles. That creates credential reach across logs, datasets, vector stores, and downstream applications, even when the model itself is replaced. NHI Management Group’s research on Ultimate Guide to NHIs and the Top 10 NHI Issues shows why identity scope, not vendor choice, is the control boundary that matters most.

The practical risk is that a model change is usually treated as a platform decision, while the identity estate is left in place. Security teams then discover that a single bearer token can still authorize access to multiple systems, or that a tool connector inherited privileges that were never reviewed for an AI workflow. Current guidance from the NIST Cybersecurity Framework 2.0 and the NIST AI 600-1 GenAI Profile points toward governance of the system, data, and access paths together, not just the model endpoint. In practice, many security teams encounter identity sprawl only after a tool chain has already broadened access to sensitive data.

How It Works in Practice

The identity risk appears when GenAI is operationalised as a set of interconnected workloads. A prompt router, retrieval layer, plug-in, evaluation service, or agent runner may each use different credentials, but they often share trust in one or two high-value secrets. If the model provider changes, the surrounding identities can remain untouched, which means the attack surface stays broad.

A more defensible pattern is to treat every GenAI component as a workload identity first and a model consumer second. That means issuing short-lived credentials, binding them to a specific task or session, and revoking them when the task ends. Where possible, use workload identity primitives such as SPIFFE or OIDC-backed tokens so the platform can verify what the workload is, not just what secret it holds. For policy enforcement, current best practice is evolving toward runtime evaluation rather than static access lists, using policy-as-code and context-aware authorization so access can be narrowed to the exact data source, tool, or action required.

• Use separate identities for model access, retrieval, logging, and outbound tool calls.
• Prefer JIT credential issuance over long-lived shared secrets.
• Scope tokens to the minimum data source, tenant, and time window needed.
• Rotate or revoke credentials when the workflow changes, not just on a calendar.
• Monitor for lateral movement between GenAI components, especially through shared orchestration layers.

This is consistent with the identity-first framing in 52 NHI Breaches Analysis, and it aligns with workload-identity guidance in NIST CSF 2.0. These controls tend to break down when a single orchestration account is reused across multiple environments because compromise of one connector can immediately expose every connected dataset.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, so organisations have to balance stronger containment against deployment speed. That tradeoff becomes sharp in multi-tenant SaaS integrations, rapid experimentation environments, and agentic workflows that call many tools in sequence.

There is no universal standard for this yet, but current guidance suggests the highest-risk patterns are shared service accounts, persistent refresh tokens, and broad cloud roles reused across model experiments. Teams also need to separate model portability from identity portability: switching from one LLM provider to another does not reduce risk if the same orchestration identity can still read source code, customer records, or internal tickets. NHI Management Group’s Ultimate Guide to NHIs and the DeepSeek breach page are useful reminders that exposure often follows the identity path, not the model brand.

In regulated or high-change environments, the safest baseline is to assign a distinct identity to each GenAI control plane component, limit secrets to short TTLs, and review every tool connector as though it were a privileged integration. That approach is less convenient, but it prevents a model swap from quietly preserving old access.

Related resources from NHI Mgmt Group

• Why do silent data changes create governance risk for identity and security programmes?
• Why do collaboration platforms create identity risk even when the workspace looks tidy?
• Why do MCP servers create new risk for IAM and NHI programmes?
• Why do just-in-time access models reduce risk in privileged identity programmes?