AI model sovereignty depends on control planes, not provider flags

At a glance

What this is: This is an analysis of how a single provider and jurisdiction can become a concentration risk for AI capability, and why sovereignty depends on the control plane rather than the model itself.

Why it matters: It matters because IAM teams now have to govern AI capabilities as revocable non-human identities, with access scope, jurisdiction, and continuity all becoming part of the control problem.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Unosecur's analysis of AI sovereignty, concentration risk, and control planes

Context

AI sovereignty is a control-plane problem, not a branding problem. When a provider can revoke access to a critical capability across customers and staff, the question for identity teams becomes who controls the authority to act, and under which jurisdiction that authority can be withdrawn.

For IAM, NHI, and AI governance programmes, the practical issue is continuity under revocation. If model access, agent access, or delegated workflow access depends on a single external approval point, then the organisation does not own the operating model, even if it owns the contract.

Key questions

Q: How should security teams govern AI capabilities that can be revoked by a provider or regulator?

A: Treat the capability as a governed entitlement, not a permanent service. Identify who can revoke it, under what legal or contractual conditions, and what dependent workflows would fail. Then move approval and audit authority into your own identity governance layer so model access does not equal external control over business continuity.

Q: Why does AI sovereignty matter for IAM programmes?

A: Because AI access can be withdrawn by a third party, which turns continuity into an identity issue. IAM teams need to know whether they control the authorization layer, whether they can swap capabilities without rebuilding controls, and whether legal constraints can change access at runtime. That is governance, not procurement.

Q: What breaks when an organisation depends on one AI provider in one jurisdiction?

A: The organisation loses the ability to guarantee continuity. If the provider or regulator disables access, every workflow built on that model can stop at once, including approved internal use. The failure is concentration risk, where the control point sits outside the enterprise and cannot be overridden locally.

Q: Who should be accountable for AI access revocation risk?

A: Accountability should sit with the teams that own identity governance, security architecture, and risk management together. If the model provider controls the final switch, internal accountability is weak by design. The organisation needs a named owner for capability dependencies, jurisdictional exposure, and failover testing.

Technical breakdown

Control-plane ownership for AI capabilities

In identity terms, the control plane is the layer that decides which identities may use which capability, under what conditions, and with what revocation rights. If the provider owns that layer, the organisation inherits a dependency it cannot meaningfully override. This is different from hosting a model or using an API. The architectural question is whether access governance sits inside the enterprise boundary or at a vendor boundary that can be reset by law, policy, or outage. Practical implication: treat AI capability access as a governable entitlement, not a static service feature.

Practical implication: Inventory who can revoke each AI capability and move approval authority into your own identity governance layer.

Jurisdictional exposure in AI identity governance

Jurisdiction becomes an access-control variable when laws or export rules determine who can use a capability. That means nationality, residency, and place of work can become live authorization attributes, not just HR data. Most enterprise IAM stacks are not designed to enforce those attributes at the pace needed for model access changes. The result is a governance gap between policy intent and technical enforceability. Practical implication: classify AI services by jurisdictional reach and verify whether your access model can actually enforce those constraints.

Practical implication: Map every AI dependency to the jurisdictions that can reach it and test whether your IAM stack can enforce those rules.

Why model portability is a security control

Model portability means a workflow can switch from one model to another without redesigning the control environment around it. That matters because if the model is replaceable, the business process survives provider disruption. If it is not, the model becomes a single point of failure. Portability is therefore a resilience control, not a procurement preference. Practical implication: test whether an AI workflow can be re-pointed without changing identity, authorization, or audit logic.

Practical implication: Prove that critical AI workflows can fail over to another model without rebuilding identity and audit controls.

Threat narrative

Attacker objective: The objective was not data theft but enforced denial of AI capability through concentration of authority in one revocable access layer.

1. Entry occurred through a single external control point that could disable access to Fable 5 and Mythos 5 for all users at once. Escalation followed because the access decision applied across customers and staff, including approved internal users. Impact was immediate loss of capability across dependent workflows, with no local override available.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Concentration risk is now an identity control problem, not just a vendor risk. When a single provider and a single jurisdiction can revoke access to a critical AI capability, the failure is not merely operational. The deeper issue is that the control plane was external to the organisation, so continuity depended on a party the business could not govern. The implication is that AI capability ownership has to be assessed like any other high-value entitlement path.

Jurisdiction has become a live authorization attribute. The article shows that nationality and residency can suddenly affect who is allowed to use a model, including approved staff. That breaks the assumption that access decisions are stable enough to be managed only through ordinary provisioning and review cycles. The implication is that identity programmes must be able to reason about lawful access conditions at runtime, not after the fact.

Model portability is the named resilience concept this episode sharpens. A workflow that cannot move from one model to another without rebuilding the control plane is already locked into concentration risk. The problem is not the model alone, but the dependency chain wrapped around it. Practitioners should treat portability as a governance requirement for any AI dependency that can affect production workflows.

AI agents inherit the same governance lesson as other non-human identities, but with a sharper blast radius. Once an AI capability sits inside a workflow, it becomes part of the identity surface. If the access authority sits outside the enterprise, the organisation is outsourcing not just functionality but revocation risk. That is why AI governance and NHI governance are converging on the same control question: who can revoke what, and where is that authority held?

Open-weight models shift the risk, they do not remove it. The article is right to frame self-hosting as a sovereignty move, but the operational burden moves with it. Infrastructure, monitoring, safeguards, and chip-level dependency still have to be governed. The implication is that sovereignty is an architecture property, not a licensing choice.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That is why practitioners should also review Ultimate Guide to NHIs , Key Challenges and Risks for the governance patterns that concentration risk tends to expose.

What this signals

Model portability is becoming a programme requirement, not an architecture nice-to-have. Identity teams should assume that critical AI services can become unavailable for reasons outside their operational control, and that the control plane must survive that change. The programmes that will hold up best are the ones that can re-point access without reworking governance, audit, or revocation logic.

The sharper lesson is that AI governance and NHI governance are converging. Once a model or agent can be revoked externally, it behaves like a high-risk non-human dependency whose lifecycle, access scope, and jurisdictional exposure must be explicitly managed.

For teams already using open-weight or self-hosted models, the next question is whether the surrounding environment is actually resilient. Sovereignty shifts the burden to your own infrastructure, so the operational signal to watch is whether you can keep policy, monitoring, and incident response intact when the underlying model changes.

For practitioners

• Map AI capability revocation paths Identify every external party that can suspend, narrow, or revoke access to a model, agent, or AI workflow. Document where that authority sits, which jurisdictions can trigger it, and which internal business services would fail if the capability disappeared.
• Move authorization authority into the enterprise control plane Ensure your identity and access layer, not the provider, decides which users, service accounts, and AI agents may use each capability. Scope access by task, environment, and jurisdiction so provider approval is not the final gate.
• Test model failover without control-plane rebuilds Run a tabletop where the primary model is unavailable and prove that the workflow can switch to an alternate model while keeping the same identity, authorization, and audit logic intact.
• Classify AI services by jurisdictional reach Record which laws, export controls, or residency constraints can affect each AI dependency, then verify whether your current access model can enforce those attributes in production.
• Review open-weight assumptions before self-hosting If you move to self-hosted models, assign ownership for monitoring, abuse prevention, and platform resilience before production use. The model may be portable, but the surrounding infrastructure becomes your responsibility.

Key takeaways

• AI sovereignty is an identity governance issue because the control plane, not the model, determines who can act and who can revoke access.
• A single provider or jurisdiction can create concentration risk that invalidates assumptions about continuity, portability, and local override.
• Practitioners should treat model portability, jurisdictional visibility, and internal revocation authority as core control requirements for AI-dependent workflows.

Key terms

• AI sovereignty: AI sovereignty is the ability to control where a capability runs, who can use it, and who can revoke it. In practice, it depends on identity governance, jurisdictional awareness, and resilience controls that keep business workflows running when a provider changes the rules.
• Control plane: The control plane is the decision layer that determines which identities may access a system and under what conditions. For AI, it becomes the load-bearing governance point because it can outlast or out-rank the model itself, making ownership of that layer a security issue.
• Concentration risk: Concentration risk is the exposure created when too much operational dependency sits with one provider, one jurisdiction, or one approval path. In identity terms, it becomes dangerous when a single external decision can stop multiple workflows, leaving the organisation unable to override the failure locally.
• Model portability: Model portability is the ability to move a workflow from one AI model to another without redesigning the surrounding access, audit, or policy controls. It matters because portability is what turns a model into a replaceable component rather than a single point of failure.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• How Unosecur says it built its control plane to run in different deployment models, including managed service, customer-owned infrastructure, and air-gapped use cases.
• The article's discussion of sovereignty properties such as model portability, jurisdictional visibility, graceful degradation, and control-plane ownership.
• The specific implications Unosecur draws from the Anthropic order for European-hosted and self-hosted AI architectures.
• The vendor's own framing of why a European flag is not itself a security control.

👉 Unosecur's full post covers the Anthropic shutdown, export-control implications, and deployment trade-offs.

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 responsible for identity security strategy or operational governance, it is worth exploring.