Who Controls Trust? Rethinking Digital Sovereignty

Europe's digital sovereignty debate has a blind spot: it still treats infrastructure as the only place where control lives. In modern cloud and AI environments, control also lies in the systems that establish identity, grant authority, and decide what users, applications, and AI agents are allowed to do. These systems are just as vital as the hardware they run on, and that changes the definition of sovereignty.

The debate has made real progress. Conversations that once focused almost entirely on data residency and physical infrastructure now cover jurisdiction, regulatory compliance and the geopolitical risks of cloud concentration. But most organizations are still asking where their data lives, when they should also be asking who controls trust.

Most of the debate is still asking the wrong question: organizations ask where their data lives, when they should be asking who controls trust.

Those two questions lead to very different architectural decisions. And as AI agents begin acting autonomously across enterprise systems, the gap between them is about to become a serious operational problem.

What is security sovereignty?

Security sovereignty is the ability to retain control of the systems that establish identity, grant authority, evaluate access and enforce policy, independently of any single infrastructure provider.

It extends data sovereignty and sovereign cloud to the identity and access management (IAM) layer. That layer covers the authentication, authorization and API access control that decide who can reach your data in the first place.

Security sovereignty is not the same as self-sovereign identity (SSI), which refers to decentralized credentials held by individual users. Security sovereignty is about an organization keeping control of its own identity and authorization infrastructure.

Why data sovereignty and sovereign cloud are not enough

Infrastructure sovereignty is necessary. Running workloads on infrastructure subject to foreign jurisdiction creates real legal and operational exposure. The US CLOUD Act, for example, allows US authorities to compel US-based providers to hand over data they control, wherever it is stored

When an employee logs in or an AI agent queries a database, something has to decide whether that request should be allowed. Where the workload runs is only part of the picture. You also need to know who makes the access decision and who controls the policy behind it.

If your identity or authorization service is so tightly coupled to one provider that it cannot be operated or moved independently, that creates a dependency. You may control where your data and workloads run, but you don't necessarily control the systems that decide who can access them.

Security sovereignty is the ability to retain control of the systems that establish identity, grant authority, evaluate access and enforce policy, independently of any single infrastructure provider.

The missing layer: identity and authorization in the control plane

Modern digital architectures separate the data plane, where workloads and data operate, from the control plane that governs access to them. Identity, authorization and policy form the core of this security control plane, while enforcement happens across APIs and other distributed points.

Most sovereignty investment has gone into the data plane: sovereign cloud deployments, on-premises infrastructure and data localization. Those investments are often sensible. But many organizations have invested heavily in sovereign infrastructure and then handed authentication, authorization and API access control over to a hyperscaler. The data sits within your jurisdiction while the decisions about who can access it do not.

The security control plane can be disrupted in more ways than most architects plan for:

• provider outages or regional failures

• changes to pricing, terms of service or product roadmaps

• the provider being acquired

• sanctions, export controls or other geopolitical restrictions

• legal orders from foreign jurisdictions

When any of these happens, the consequences go well beyond slower response times. The ability to authenticate users, authorize transactions and govern AI agents disappears with it. That is a different category of problem.

Regulation is moving in the same direction. DORA requires financial entities, including insurers, to manage ICT third-party and concentration risk. NIS2 makes supply chain security a management responsibility. An identity layer that can only run in one provider's cloud is exactly the kind of dependency these rules are designed to surface.

Why agentic AI makes authorization sovereignty urgent

For most of the cloud era, control-plane dependency was a latent risk: critical, but not acute. Agentic AI is changing that.

AI agents act autonomously across APIs, databases and business processes. An agent serving a customer may call several APIs and systems as it works toward a goal, so authorization becomes continuous rather than a one-time decision at the start of a session. Both the number of authorization decisions and the stakes of each one rise sharply.

Each of those decisions depends on an authorization layer. If that layer depends on a hyperscaler in a way that prevents you from operating independently, then so does the governance of your AI agents, whether you intended that or not.

In McKinsey's State of AI 2025 survey, 23% of organizations said they were already scaling an agentic AI system in at least one business function, and another 39% were experimenting with AI agents.

Organizations are already deploying AI systems into production at scale, often before they have worked out where authorization decisions are actually made or who controls the policies governing agent behavior. Identity and access infrastructure that was adequate for human users and service accounts was not designed for this.

Four principles of security sovereignty

Moving beyond an infrastructure-centric view of sovereignty comes down to four principles.

1. Portable, transparent identity

Identity cannot be a black box. Organizations need to know exactly how identities are established and validated for users, service accounts and AI agents. That knowledge must be portable and not locked to a specific provider's implementation. Building on open standards such as OAuth 2.0 and OpenID Connect keeps it that way.

2. Organization-owned authorization policy

Authorization policies need to remain under the organization's control, not the platform's. Business rules about who can do what, and under what conditions, should be expressible and enforceable independently of the infrastructure they run on. Policies that only exist inside a cloud provider's policy engine are not really yours.

3. Security services that run in any environment

If your identity and authorization infrastructure can only run inside a specific cloud, you have created a single point of failure that no amount of compute redundancy can fix. The architecture needs to support on-premises, sovereign cloud, private cloud and multi-cloud deployment without loss of capability or consistency.

4. Bounded authority for AI agents

An agent acting on behalf of a user shouldn't automatically inherit everything that user can do. Its authority should be limited to the task, time-bound and recorded. In practice, that means issuing agents short-lived, narrowly scoped access tokens instead of reusing the user's full session. It also means using delegation rather than impersonation, so every action can be traced to both the agent and the user it acts for. Standards such as OAuth 2.0 Token Exchange (RFC 8693) already provide the building blocks. The underlying authorization problem isn't new, but agents make it far more common.

Example: how If Insurance keeps control of its identity layer

At Curity, we work with organizations that have made identity and authorization sovereignty a deliberate architectural choice. One example is If Insurance, one of the largest insurers in the Nordic region. Its common identity platform, powered by the Curity Identity Server, protects all of its internal and external APIs, including the customer-facing AI services it is now bringing into production. By applying the same security architecture across traditional digital services and AI, If retains control over a critical part of the trust layer rather than treating AI security as a separate problem.

A practical test for security sovereignty

Ask one question: can your identity and authorization continue to operate consistently if your infrastructure, provider or jurisdiction changes?

Infrastructure is ephemeral. Providers get acquired or change their terms. Regulations evolve. If your ability to authenticate users and enforce authorization policies depends on any of those things staying stable, you have a problem that no SLA covers.

The sovereignty debate will continue to evolve as geopolitical and regulatory pressures increase. The architectural question is already clear: identity and authorization should remain operable on your terms, even when providers, infrastructure or jurisdictions change.

Learn how Curity Access Intelligence gives you runtime control over what AI agents can access and do.