AI sovereignty tested by access loss

AI sovereignty is defined as an organization's ability to continue operations without reliance on the provider of an AI tool. This requires simulating an access cut-off before it actually happens to ensure that the organization can still function, recover data, and maintain control.

ARTEX agent moves to closed source

Reuters reported on Friday, October 9, that the developer of the ARTEX agent is transitioning its project to closed source, discontinuing new versions and maintenance. This move follows cybersecurity firms linking the tool to a campaign targeting South Korean banks, though these attributions remain from third-party sources.

Dependency beyond the AI model

AI agent dependency is not limited to the model itself but includes technical identities, connectors, and orchestrators. These elements affect data formats, logs, updates, and support. A service chain involving multiple providers means replacing a model may not restore the service.

Legal vs. operational sovereignty

Legal sovereignty involves hosting data in a specific region to meet regulatory requirements. However, operational sovereignty ensures the availability of APIs, portability of work states, and maintenance of connectors. These are separate but equally important aspects of AI integration.

Shared service accounts pose risks

According to the CISO AI Leverage Report by the Open Future Forum (October 2026), 37 percent of respondents use shared service accounts for access management, compared to 14 percent who use delegated identities or mediated access. This practice increases the difficulty of attributing actions and revoking access, highlighting the need for more secure identity management.

CIOs must address four key questions

For each AI-based service, the CIO should be able to answer four critical questions: what business functions must continue if the model is unavailable, what identifiers and rights the agent uses, what data can be recovered, and what procedures allow switching to another tool or manual mode. These questions ensure preparedness for potential disruptions.

Testing the exit scenario

Organizations should simulate access loss by disabling a connector, revoking a token, or simulating model unavailability. This exercise helps identify hidden dependencies, such as non-exportable memory or untested manual procedures, and provides measurable outcomes like recovery time and data loss.

Architecture must reduce dependencies

The system architecture should minimize shared accounts, isolate agent rights, and avoid requiring a full rebuild when changing models. Technical dependencies must be mapped and addressed, as no legal clause can compensate for unpreparedness. The key question remains: what can an organization still do if it can no longer use a specific AI model?