01 / DEFINITION
Sovereignty is the ability to keep control.
Sovereign security operations keep sensitive security data, administrative authority and AI processing within approved legal, geographic and technical boundaries. The deployment may be on premises, in-country, private cloud or hybrid, provided control remains explicit and verifiable.
Data residency answers where data is stored. Sovereignty is wider. It asks who can administer the system, which laws and contracts apply, whether external services are required, where models run, how updates arrive and whether the operation can continue through a connectivity or geopolitical disruption.
For security operations, these questions are material. Incident evidence can contain credentials, network structure, employee identity, regulated records and details of defensive controls. The operating model should fit the boundary, not force the boundary to fit the software.
02 / THREE DIMENSIONS
Data, operations and models.
A credible sovereign design makes each dimension visible. Keeping storage in-country while support, keys or inference remain externally controlled may satisfy one requirement and fail another.
Data sovereignty
Define where raw evidence, derived context, incident records, logs, backups and model prompts are stored and processed.
Operational sovereignty
Control administrator identity, privileged access, keys, support paths, upgrades, monitoring and continuity from within the approved boundary.
Model sovereignty
Choose where inference runs, which models can see each data class, how model artifacts arrive and whether the system can operate without an external API.
Decision sovereignty
Keep policy, approval rights and action authority under the customer’s governance, regardless of infrastructure placement.
03 / PLACEMENT MODELS
One operating model. Four places to run it.
Scope, Hunt and Strike keep the same responsibilities while infrastructure, data movement and model routing are configured for the organization’s jurisdiction, assurance and availability requirements.
On premises
Virian, evidence stores, integrations and approved models run inside the organization’s facilities and administrative domain.
In-country colocation
A dedicated or approved facility provides local residency, connectivity and operating control without placing hardware on the customer campus.
Private cloud
Virian runs in a customer-controlled cloud environment with isolated networking, identity, keys, logging and model endpoints.
A controlled hybrid keeps sensitive evidence and policy local while routing only approved tasks or data classes to external services. The boundary is designed at field level, not described with a single “hybrid” label.
04 / LOCAL AI
Inference can stay with the evidence.
Local AI allows the investigation and decision engine to run inside the sovereign boundary. An organization may use locally hosted open-weight models, approved commercial models in a private environment, or a routed model set where each task and data class has an explicit destination.
This is not only a privacy choice. Local inference can support disconnected operations, predictable access control and continued service when an external provider is unavailable. It also creates responsibilities for capacity, model evaluation, patching, monitoring and lifecycle management.
Fully local
All inference runs on customer-controlled infrastructure. No incident content is sent to an external model service.
Approved private endpoint
Models run in an isolated private cloud or in-country service with customer identity, networking and data controls.
Policy-routed
Local models handle sensitive tasks. External models receive only approved data classes and explicitly permitted requests.
Disconnected ready
Core investigation and response continue without an external control plane, model API or routine internet dependency.
05 / PRODUCTION CONTROLS
The hard questions begin after location.
A deployment diagram does not prove sovereignty. The production design must cover the full operating lifecycle, including ordinary maintenance and exceptional access.
| Control | Decision to make | Evidence to retain |
|---|---|---|
| Identity and privilege | Who can administer infrastructure, models, policy and integrations? | Named identities, role assignments, approvals and privileged session logs |
| Keys and secrets | Who generates, holds, rotates and recovers encryption keys and integration credentials? | Key ownership, rotation history, recovery procedure and access trail |
| Network and egress | Which destinations are allowed, for which task and data class? | Approved routes, firewall policy, proxy logs and denied connection events |
| Model lifecycle | How are model artifacts evaluated, signed, delivered, updated and rolled back? | Model inventory, evaluation results, artifact provenance and change approval |
| Platform updates | How do security fixes enter connected, intermittent and disconnected environments? | Release provenance, signing, compatibility tests and installation history |
| Backup and recovery | Which state must survive failure, and where may replicas exist? | Backup location, restore tests, recovery objectives and failover exercises |
| Operations and support | Can support occur without unrestricted remote access or cross-border data movement? | Access request, scoped session, commands performed and session closure |
06 / DESIGN QUESTIONS
Turn “sovereign” into a testable architecture.
What must never leave?
Classify raw telemetry, credentials, identities, incident evidence, prompts, outputs, logs and support bundles separately.
Who can stop the system?
Define local authority to suspend actions, revoke credentials, isolate models and restore a known-good state.
What must work offline?
Specify which detection, investigation, approval, response and audit functions continue during disconnection.
How is control proven?
Require configuration, access, routing, update and recovery evidence that can be inspected by local assurance teams.
07 / PRIMARY SOURCES
Current sovereign cloud and local AI patterns.
- 01Microsoft, Azure Local disconnected operationsTECHNICAL DOCUMENTATION
- 02Microsoft, Foundry Local for on-premises AI inferenceTECHNICAL DOCUMENTATION
- 03Google Cloud, Sovereign CloudDEPLOYMENT PATTERNS
- 04NIST SP 800-207, Zero Trust ArchitectureNIST