TL;DR: Sovereign cloud still relies on a patch-window assumption that frontier models and SaaS-to-SaaS breach paths are collapsing, while software-only controls cannot stop a trusted token or integration from crossing a boundary once it is accepted, according to Anjuna. Sovereignty now has to start in the silicon, because the software layer can no longer be trusted to hold the line.
At a glance
What this is: This analysis says sovereign cloud is breaking under faster vulnerability discovery and trusted-integration abuse, so hardware-verifiable boundaries are becoming the practical line for operational sovereignty.
Why it matters: IAM, NHI, and cloud security teams need to reassess where trust is enforced, because identity tokens and software boundaries no longer guarantee containment once a foothold exists.
Context
Sovereign cloud splits into two different claims: jurisdictional control over where data sits, and operational control over who can technically read or alter it. The article is about the second claim, where identity and access management, encryption keys, and network boundaries decide whether the boundary actually holds.
The central governance gap is that software-enforced trust assumes a patchable world and a manageable integration surface. That assumption weakens when trusted tokens, SaaS links, and third-party services become the shortest route across the boundary.
For identity practitioners, the important question is not whether a tenant is isolated on paper, but whether the trust model can still resist valid credentials, vendor insiders, and rapidly exploited flaws in the delivery stack.
Key questions
Q: What breaks when sovereign cloud depends only on software trust boundaries?
A: Software-only sovereignty breaks when the same platform that enforces IAM, encryption, and segmentation also becomes part of the trust boundary. Once a host, admin path, or integration is compromised, the controls can still behave correctly while the sovereignty claim fails. The practical issue is not that policy is absent, but that enforcement lives inside the thing being trusted.
Q: Why do trusted SaaS integrations create sovereignty risk even without perimeter compromise?
A: Trusted integrations matter because applications usually honour valid tokens and sessions exactly as designed. If an attacker gains that trust, the software does not see a stranger, it sees an authorised caller. That turns a successful authentication event into a boundary-crossing path, which is why identity scope and key release matter as much as perimeter defence.
Q: How should security teams govern trust for confidential computing workloads?
A: Security teams should treat confidential computing trust as a workload identity issue, not only an infrastructure issue. That means assigning ownership, requiring independent attestation evidence, and binding trust decisions to certificate lifecycle, revocation, and auditability. If a workload cannot prove its identity and integrity, it should not be trusted just because it runs inside a protected environment.
Q: What is the difference between residency sovereignty and operational sovereignty?
A: Residency sovereignty is about where data is stored and which jurisdiction governs it. Operational sovereignty is about who can technically read, alter, or move that data regardless of location. The first can often be addressed with contracts and geography. The second requires cryptographic and architectural enforcement that limits administrator and platform access.
Technical breakdown
Why software-only trust boundaries fail in sovereign cloud
Operational sovereignty depends on who can technically access data and workloads, not just where they are hosted. When IAM, encryption-at-rest, and segmentation are implemented in software, they inherit the trust of the platform running them. If an attacker or insider reaches that platform, the boundary can no longer distinguish legitimate from illegitimate access unless the architecture has a separate enforcement layer.
Practical implication: Treat software-only sovereignty claims as contingent controls, not a final trust boundary.
How trusted integrations become the shortest path across the boundary
The article describes SaaS-to-SaaS breaches as an identity problem, not a perimeter problem. Once a token, session, or integration is trusted, the application will usually honour it exactly as designed, which means reachable data is exposed through valid authentication rather than overt exploitation. That shifts the technical focus from blocking network entry to constraining what an authenticated integration can actually unlock.
Practical implication: Map every trusted integration to the data it can reach and the identity state it inherits.
Why confidential computing changes the enforcement model
Confidential computing moves the trust anchor from software policy to hardware-backed attestation. Trusted execution environments encrypt code and data in use, so a cloud operator, hypervisor, or host-level compromise is no longer enough to read memory contents or alter the workload invisibly. The architectural shift is not that identity disappears, but that key release can be tied to an attested workload identity rather than to the surrounding infrastructure alone.
Practical implication: Bind sensitive-data release to attested workload identity, not to platform reachability.
Threat narrative
Attacker objective: The attacker wants to move across a trusted cloud boundary using legitimate authentication paths and reach data that software-only sovereignty assumed was insulated.
- Entry occurs through a trusted SaaS integration or valid token rather than a noisy perimeter breach, which makes the caller look authorised.
- The attacker leverages that trust to access data or downstream services reachable from the approved integration path.
- Impact follows when the trusted boundary exposes data or administrative reach that the organisation assumed was already contained.
Breaches seen in the wild
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Software-only sovereignty is an assumption, not a guarantee: operational sovereignty has been treated as something IAM, encryption, and segmentation can enforce on top of a cloud stack. That assumption fails when the cloud operator, its integrations, or its patch cycle become part of the trust boundary. The implication is that sovereignty claims must be judged by where enforcement actually occurs, not by where policy says it should occur.
Trusted integrations have become the default lateral-movement path in cloud environments: the article is right to distinguish identity failures from data-handling failures, because they are governed differently. A valid token does not look like compromise to the application that issued it trust. That means the governance gap is not simply access control, but the over-trust placed in a successful authentication event.
Ephemeral patch windows are collapsing the old sovereignty bargain: the old model assumed defenders would have enough time between vulnerability discovery and exploitation to preserve control. Frontier-model-assisted discovery shortens that window so sharply that software-only defences are no longer operating in a stable risk regime. Practitioners should treat patch cadence as a factor in sovereignty design, not a downstream hygiene task.
Hardware-verifiable trust boundaries create a different kind of identity control plane: confidential computing matters because it changes what the workload can prove before it receives keys or handles sensitive data. That is not a stronger version of the same software boundary; it is a different assurance model. The field should now separate contractual sovereignty from cryptographic enforcement and design for both.
Identity hygiene still matters, but it is no longer sufficient on its own: short-lived tokens, scoped OAuth grants, and MFA reduce exposure, yet they do not solve the structural problem of trust being granted too early in the stack. That makes operational sovereignty a layered problem spanning workload identity, attestation, and key-release policy. Practitioners need to reframe sovereignty as an architecture decision, not a compliance label.
What this signals
Identity trust is moving closer to the hardware layer: once a tenant boundary is enforced only in software, the same identity event that authorises a request can also authorise exposure. That is why operational sovereignty increasingly depends on workload attestation and controlled key release rather than on network placement alone.
The broader signal is that patch cadence, integration trust, and workload enforcement can no longer be managed as separate programmes. If discovery is machine-speed and trust is software-defined, practitioners need a sovereignty model that assumes both compromise and valid-authentication abuse can happen inside the same control plane.
For practitioners
- Map the software trust boundary Inventory where IAM, encryption keys, and network segmentation are actually enforced, then document which layers can still be read or altered by the cloud operator or a compromised host.
- Classify trusted integrations by reachable data List every SaaS integration, agent, and third-party service that can traverse a tenant boundary, then trace the data and administration paths each trusted token can unlock.
- Bind key release to attestation Require attested workload identity before sensitive data or encryption keys are released, so host compromise alone does not collapse the boundary.
- Separate identity failures from data-handling failures Decide which incidents are caused by valid credentials being honoured and which are caused by plaintext data exposure, because the control response is not the same in each case.
- Rework sovereignty claims into architecture controls Replace policy-only statements about sovereignty with verifiable controls over data-in-use, administrator reach, and workload attestation.
Key takeaways
- The article frames sovereign cloud as a boundary problem, not just a residency problem, because software-enforced trust can fail even when policy looks correct.
- Trusted credentials and integrations are central to the risk because they can let attackers cross into data that organisations assumed was already contained.
- Hardware-backed attestation changes the enforcement point, so practitioners should reassess whether their sovereignty claims are actually verifiable in use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Valid tokens and trusted integrations are the identity failure described in the article. |
| NHI-08 — Environment Isolation | The post argues that software-only isolation is not enough for operational sovereignty. | |
| Recommendation — Scope authentication to the minimum reachable data and treat valid tokens as high-risk trust events. Separate workloads so trust boundaries do not rely solely on shared software enforcement. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on tokens, keys, and their trust lifecycle across cloud boundaries. |
| Recommendation — Apply IA-5 to shorten authenticator lifetimes and limit where credentials can be reused. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Zero Trust principles | The article challenges implicit trust in tenants, integrations, and platform access. |
| Recommendation — Verify every access path continuously instead of trusting the cloud boundary by default. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The breach pattern is trusted-access abuse followed by movement across connected services. |
| Recommendation — Map trusted-integration abuse to credential-access and lateral-movement detections in cloud telemetry. | ||
Key terms
- Operational Sovereignty: The practical ability to run and govern identity services under local organisational control rather than depending entirely on external service boundaries. It matters when technical design must satisfy legal, national, or sector-specific expectations about administration and data handling.
- Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
- Trusted Integration: A third-party or internal connection that is already authorised to act on behalf of a user, service, or application. These integrations are powerful because they inherit trust from the platform, which is exactly why stolen or over-scoped tokens can cause broad downstream access.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org