Who Controls Trust? And What Happens When You Don’t?

Security Sovereignty Under Stress

In the first article, we asked a simple question: who controls trust?

This time, the more uncomfortable question is what happens when you don’t.

Contracts are funny things. When everything is sunshine and apple pie, they tend to stay in the drawer. Business is good, profits are rolling in, customers are happy, shareholders are happy, and very few people spend much time thinking about the clauses that describe what happens when things go wrong.

Then the weather changes. Politics shift. Alliances weaken. Regulations move. A provider that looked completely safe yesterday suddenly becomes a source of uncertainty. A service nobody thought twice about becomes unavailable, restricted, or simply too risky to depend on. That is usually the moment when the contract comes out of the drawer.

Digital operations are not that different. As long as everything works, most organizations do not spend much time asking what happens if a critical cloud service disappears, an identity provider becomes unavailable, a jurisdiction changes its rules, or a trusted external dependency can no longer be trusted in quite the same way. Why would they? The business is running.

But once those assumptions begin to fail, questions that once sounded theoretical can quickly become questions of survival.

Can you still establish who or what is acting? Can you still decide what that user, application, workload, or AI agent is allowed to do? Can you still enforce policy if part of the infrastructure behind those decisions is no longer there?

That is where security sovereignty stops being an architectural preference. It becomes part of business continuity.

Resilience starts when normal stops being normal

Most resilience planning begins with an understandable assumption: keep the service available.

But availability alone is not resilience.

A service can still be online and effectively unusable because users cannot authenticate. An API can respond perfectly and still be unsafe because authorization decisions can no longer be made reliably. An AI agent can continue reaching systems even though the context needed to govern what it is allowed to do has disappeared.

That is why it is useful to think about three distinct operating conditions: normal, degraded, and crisis.

During normal operations, the organization works with the full set of services, controls, policy inputs, and contextual information available to it. Users authenticate as expected. Applications and workloads obtain the authority they need. AI agents may act autonomously within clearly defined boundaries, and authorization decisions can draw on rich context such as identity, risk, device state, delegated authority, transaction value, or business policy.

Then something changes.

It may be a cyberattack, a major outage, a geopolitical event, or simply a critical dependency becoming unavailable or unreliable. Whatever the cause, the result is the same: assumptions the organization made about its operating environment no longer hold.

At that point, continuing as though nothing happened is usually the wrong decision: Authority should begin to contract.

Access may need to become narrower. Credentials may need to become shorter lived. Some integrations may no longer be trusted enough to use. Certain transactions may require additional approval. AI agents may continue to operate, but with fewer permissions and within a smaller set of allowed actions.

This is degraded operation.

And the important part is that degraded operation should be designed in advance. It should not be invented in the middle of an incident by whoever happens to be awake.

The organization should already know which capabilities can continue, which should be restricted, and which must stop. The transition between these modes should be predetermined. If conditions recover, the organization can return to normal operation. If they worsen, authority contracts further and the system moves into crisis mode.

Crisis mode is different again. At that point, the goal is no longer to preserve normal business processes. The goal is to preserve the organization itself, or at least the essential services that matter most.

Autonomous behavior may need to be reduced sharply or removed altogether. Some services may be suspended. Only a limited set of trust paths may remain active. Break-glass mechanisms may become necessary, but they should be explicit, temporary, and auditable.

A resilient architecture should therefore be able to become smaller, stricter, and more conservative as uncertainty increases.

That is not failure. That is control.

Security sovereignty is about preserving choice

This is where sovereignty and resilience meet.

Curity's view of Security Sovereignty is not that organizations should abandon public cloud, cloud-native services, or external providers. That would be unrealistic and, in many cases, counterproductive. Modern digital businesses are built on dependencies. The real question is whether those dependencies leave you with options.

Can your identity services continue to operate if the underlying environment changes? What happens if the organization cannot preserve identity, authorization, and policy when the underlying provider changes?

Can the same trust model be maintained across public cloud, sovereign cloud, private infrastructure, or on-premises environments? Can the organization reduce authority safely when risk increases? Can it continue to enforce policy when one external signal, provider, or control plane is no longer available?

If the answer to those questions is no, then the dependency is more than technical; it has become operational.

And if changing providers also means losing the ability to authenticate users, issue authority, or enforce access policy, then the organization does not really control that part of its architecture. It is renting control.

That distinction matters because a sovereign architecture should not depend on stability outside the organization's influence.

Providers change. Terms change. Regulations change. Political relationships change. The ability to establish identity, grant authority, and enforce policy should survive those changes.

Agentic AI raises the stakes

Agentic AI makes the resilience problem more acute because agents can turn a single objective into a chain of actions across APIs, systems and data, often using delegated authority and making decisions at machine speed. Authorization therefore becomes part of the execution path rather than something that happens once at the start of a session.

That means authority also needs to respond when operating conditions change. An agent that can complete a task autonomously during normal operations may need narrower permissions when services or trust signals become unreliable. In crisis conditions, some autonomous actions may need explicit human approval or may need to stop altogether.

When circumstances worsen, different parts of the trust model can fail in different ways. A critical context or risk signal may disappear, leaving the system with less information than it normally relies on. If the authorization engine itself becomes unavailable, the organization has to decide whether operations should stop, fall back to a more restricted mode, or require explicit human approval. And if the target system becomes unstable, the question is no longer only whether the request is authorized, but whether it is still safe to carry out at all.

AI does not create this resilience problem, but it increases the speed, scale and potential consequence of getting it wrong.

The real test comes when the weather changes

It is easy to talk about sovereignty while everything is working, just as it is easy to sign a contract, file it away, and forget the uncomfortable clauses while everyone is still getting what they expected. The real value of both only becomes visible when circumstances change.

Security sovereignty is tested when an organization has to move from normal into degraded operation, and perhaps from there into crisis mode, without losing control of identity, authority and access along the way. The objective is not to keep every service running at any cost, but to preserve the capabilities that still matter, under the controls that remain appropriate, for as long as it is safe to do so.

That takes more than redundant infrastructure. It requires a trust layer that can continue to function as providers, jurisdictions, operating conditions and underlying infrastructure change around it.

Before the weather turns

The question, then, is how to design for this before normal stops being normal.

How do you make sure control can be preserved when providers, infrastructure or critical services become unreachable?

Nobody likes to think too much about the point, yet we prepare for uncomfortable possibilities in other parts of life all the time. We buy life insurance, write wills and make contingencies for events we hope will never happen. Not because we expect the worst every day, but because some things matter too much to leave unplanned.

Organizations should approach digital operations with the same mindset. This is not primarily about cost; it is about retaining control when circumstances deteriorate. A crisis-management handbook cannot be written in the middle of a crisis. The processes, procedures and boundaries need to be understood in advance: what may continue, what must be restricted, what requires human intervention and what has to stop.

That is where Security Sovereignty is really tested. It is not only about deciding who controls trust while everything is working, but about making sure that control survives when the systems and services around it no longer do. The time to make those decisions is before the weather turns.