How do organisations avoid lock-in in AI infrastructure and identity controls?

Why This Matters for Security Teams

Lock-in is not just a procurement problem when AI systems are involved. It becomes a security problem when identity, policy, and tool access are welded to one model provider, one orchestration layer, or one proprietary control plane. If the enterprise cannot move the trust boundary without redesigning the whole stack, it also cannot react quickly to vendor risk, incident response, or new governance requirements.

This is especially visible in NHI and agentic AI deployments, where the real control point is the workload identity and the policy layer, not the model itself. NHIMG research on Ultimate Guide to NHIs and Top 10 NHI Issues shows why long-lived credentials and tightly coupled identity controls create fragile dependencies. Once those controls are embedded in a single platform, every change becomes a migration project instead of a policy update.

Current guidance from the NIST Cybersecurity Framework 2.0 reinforces the need for portability, resilience, and governance across technology change. In practice, many security teams discover lock-in only after a model swap, cloud move, or breach response forces them to rebuild identity controls under pressure.

How It Works in Practice

Reducing lock-in means separating three layers that are often bundled together: model access, workload identity, and policy enforcement. The model can change, but the identity proof and the authorisation logic should remain stable. That is why current best practice favors open protocols, portable trust anchors, and policy enforcement points that sit between the agent and upstream systems, rather than embedding access logic inside a single vendor workflow.

For identity, teams should treat the agent as a workload with a portable cryptographic identity, then bind access to runtime context. Open approaches such as SPIFFE/SPIRE, OIDC-based workload tokens, and policy-as-code systems help keep the enterprise from hard-coding permissions into one AI stack. For governance, frameworks such as NIST CSF and NIST AI guidance support an architecture where controls are observable, testable, and portable across environments.

In practice, that usually looks like this:

• Issue short-lived credentials per task rather than embedding static keys in the agent runtime.
• Evaluate policy at request time, based on the agent’s intent, data scope, and destination system.
• Keep secrets, tokens, and certificates outside the model provider’s native control plane where possible.
• Use a broker or gateway so changes to models, tools, or clouds do not require rewriting trust logic.
• Log identity, decision, and tool-use events in a format the enterprise can move across vendors.

NHIMG’s 52 NHI Breaches Analysis and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research both underline the same operational lesson: once identity and secrets are entangled with one platform, attackers and migrations both benefit from the coupling. These controls tend to break down when the agent platform also owns secret storage, policy enforcement, and tool routing, because portability disappears at the exact layer security teams most need to replace.

Common Variations and Edge Cases

Tighter portability often increases integration overhead, so organisations must balance vendor flexibility against the cost of operating a more modular trust architecture. That tradeoff is real, especially when teams want fast deployment and low-friction developer experience.

There is no universal standard for this yet, so current guidance suggests aiming for the most portable control points first: identity issuance, policy evaluation, and secrets handling. The model layer can remain proprietary if the security boundary stays outside it. In contrast, if the vendor controls both the identity plane and the enforcement plane, lock-in is effectively baked in.

Edge cases show up in regulated or highly distributed environments. Air-gapped systems, legacy workflow engines, and embedded AI features inside SaaS platforms may not support clean separation of duties. In those cases, best practice is to document the coupling explicitly, limit the scope of privileged access, and plan exit criteria before the platform becomes business-critical. For agentic systems, the Ultimate Guide to NHIs — Standards and NIST-aligned identity controls are most useful when they are treated as portability requirements, not product features.

Where organisations go wrong is assuming that a “multi-model” strategy automatically avoids lock-in. It does not if each model still depends on a unique identity wrapper, secret store, and authorization API. The real test is whether the enterprise can swap the model without changing who the agent is, what it may do, or how access is approved.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• What is the difference between human identity governance and AI agent governance?
• Why do AI agents increase non-human identity risk in existing IAM programmes?