The condition where an application depends on a provider-managed model name that looks stable but can change, retire, or map to different behavior over time. It is a governance problem because the application contract outlives the lifecycle of the external model identity.
Expanded Definition
Model identity drift occurs when an application treats a provider-managed model name as a durable dependency, even though the underlying model can change behavior, be retired, or be remapped without the application contract changing. In practice, the identifier looks stable while the operational identity is not. That makes the issue less about prompt quality and more about governance of external execution dependencies.
Definitions vary across vendors because some platforms expose versioned names, some expose aliases, and some silently update shared endpoints. In NHI terms, the risk resembles trusting a stable service label without validating what it actually resolves to at runtime. This matters alongside broader control expectations in the NIST Cybersecurity Framework 2.0, where asset context, change awareness, and risk response must stay current.
The most common misapplication is assuming that a model name alone is an immutable control boundary, which occurs when teams pin business logic to a provider alias and ignore release, deprecation, or routing changes.
Examples and Use Cases
Implementing model identity rigorously often introduces version-management overhead, requiring organisations to weigh output stability against the speed and convenience of provider-managed aliases.
- A customer support agent is built against a general model alias, then starts producing different classifications after the provider retunes the alias behind the same name.
- A workflow uses a model for policy summarization, but the provider retires the referenced endpoint and remaps traffic, creating undocumented behavior drift in downstream approvals.
- An internal coding assistant depends on a shared model name, and a later backend swap changes tool-use reliability, breaking automation assumptions even though the API call succeeds.
- A regulated workload pins only an alias instead of a specific release, then cannot reproduce prior outputs during audit review or incident investigation.
These scenarios are closely tied to the broader NHI lifecycle problems described in the Ultimate Guide to NHIs and to identity-adjacent failures seen in the 52 NHI Breaches Analysis. For implementation guidance, teams often compare provider alias behavior with the model lifecycle and deployment expectations discussed in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Model identity drift creates governance blind spots because security, reliability, and compliance controls may be validated against one behavior while production depends on another. That can break approval workflows, policy enforcement, incident reproducibility, and change accountability. It also complicates trust decisions for Agent / AI Agent systems that call models as tools, because the agent may inherit a changed capability profile without any corresponding approval event.
NHIMG research shows that 68% of organisations do not know how to fully address NHI risks, and model identity drift is one reason why: the control problem hides in naming, lifecycle, and dependency mapping rather than obvious credential theft. The issue is especially dangerous when paired with secret sprawl, opaque third-party dependencies, and the false assumption that a stable endpoint implies stable behavior. The Top 10 NHI Issues framing is useful here because it places lifecycle governance alongside access control, not after it.
Organisations typically encounter the consequences only after a failed audit, a broken workflow, or an unexplained production output shift, at which point model identity drift becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A-03 | Covers unstable model/tool dependencies that change agent behavior over time. |
| NIST CSF 2.0 | PR.IP-3 | Change management applies when provider model identities shift or are remapped. |
| NIST AI RMF | Addresses AI system context, lifecycle, and monitoring for changing model behavior. | |
| OWASP Non-Human Identity Top 10 | NHI-07 | Identity lifecycle gaps arise when external model names outlive their actual trust state. |
| CSA MAESTRO | Agentic systems need explicit control over dynamic model selection and trust boundaries. |
Pin and validate model dependencies so agents cannot inherit unreviewed behavior changes.
