Sovereign AI Deployment: FIPS 140-3, Air-Gapped FHE

Definitions

What sovereign AI means

Sovereignty in AI is not a single thing. It is a spectrum of control requirements, and different organisations land at different points on that spectrum depending on their data classification, regulatory environment, and operational context.

At one end is cloud deployment with contractual data residency: your data stays in an EU data centre but the inference service is operated by a US company subject to US law. This satisfies some residency requirements but not sovereignty ones. At the other end is fully air-gapped on-premises deployment: the model, the compute, the key management, and the data all live inside a physical boundary that has no external network connections. Nothing crosses a wire that you do not control.

Between those extremes sit sovereign cloud deployments (government-operated cloud infrastructure with your own compute), private cloud with encryption at inference (cloud compute but FHE ensures the provider cannot read the data), and on-premises with selective cloud connectivity (inference on-premises, model updates over a verified air gap).

Applicability

When sovereignty is required

Four conditions independently create a requirement for sovereign or air-gapped AI deployment.

Understanding which condition applies to your organisation determines the architecture. A hospital under GDPR in Germany needs a different deployment than an army unit operating in a disconnected forward base, even though both might say they need "sovereign AI."

What you are defending against

The air-gapped threat model

Air-gapped environments eliminate most network-based attack vectors but create a distinct set of threats that standard cloud deployments do not face.

Cryptographic standards

FIPS 140-3 for AI key management

FIPS 140-3 is the successor to FIPS 140-2 as the US federal standard for cryptographic module validation. For AI deployments in US government environments, FIPS 140-3 validated modules are required for any cryptographic operation on sensitive data. This is not optional: using a non-validated module is a finding in any FedRAMP or STIG assessment.

For a VectaX sovereign deployment, FIPS 140-3 applies to three operations: FPE key generation and storage, RBAC key generation and storage, and the key wrapping operations when keys are moved between systems during provisioning.

What FIPS 140-3 requires in practice

The standard has four security levels. Level 1 is software-only implementation. Level 2 requires evidence of tampering (tamper-evident seals). Level 3 requires tamper resistance and identity-based authentication. Level 4 is required only in the most extreme environments. For most government and regulated enterprise deployments, Level 2 or Level 3 HSMs are the requirement.

Reference design

Reference architecture for sovereign VectaX deployment

This architecture applies to an on-premises deployment with no external network connectivity. All components live inside the physical security boundary.

Implementation

VectaX in offline environments

The VectaX SDK cryptographic operations are local. FHE, vector encryption, and FPE do not require network calls during encryption or decryption. The one component that normally requires network access is RBAC key management, which calls the Mirror Security API to generate and scope user keys.

For air-gapped deployments, RBAC keys are pre-generated inside the secure boundary during a provisioning ceremony and stored in the HSM. The SDK then uses those stored keys without making further API calls.

from mirror_sdk.core.mirror_core import MirrorSDK, MirrorConfig
from mirror_sdk.core.models import VectorData

# In a sovereign deployment, point the SDK to your on-premises Mirror instance
# This instance runs inside your physical boundary with no cloud dependency
config = MirrorConfig(
    api_key="your-on-premises-api-key",
    server_url="https://mirror-api.internal.yourorg.gov",  # on-prem URL
    telemetry_enabled=True,
    policy_eval_enabled=True,
    # Longer polling interval is fine in air-gapped environments
    # policy updates happen via the provisioning process, not dynamically
    polling_interval=3600
)
sdk = MirrorSDK(config)

# VectaX encryption operations are local
# This call makes no network request
embedding = [0.12, 0.45, 0.78]  # your actual embedding vector
vector = VectorData(vector=embedding, id="doc_classified_001")
encrypted = sdk.vectax.encrypt(vector)  # purely local crypto operation

# Decryption is also local
decrypted = sdk.vectax.decrypt(encrypted)  # no network call

print("VectaX FHE operations complete with no external network dependency")

Key lifecycle

Key management without cloud connectivity

Key provisioning in an air-gapped environment is a procedural process as much as a technical one. It happens during a controlled key ceremony and must be documented in detail.

from mirror_sdk.core.mirror_core import MirrorSDK, MirrorConfig

# Key ceremony: run this on the HSM-connected provisioning workstation
# inside the physical security boundary
# Two authorised custodians must be physically present

config = MirrorConfig.from_env()
sdk = MirrorSDK(config)

# Step 1: Generate FPE key inside HSM
# The key material never leaves the HSM
# The SDK returns a handle (reference), not the key bytes
fpe_key_handle = sdk.metadata.generate_key()
print(f"FPE key generated. Handle: {fpe_key_handle[:8]}... (stored in HSM)")

# Step 2: Generate RBAC master policy
sovereign_policy = {
    "roles": ["analyst", "senior_analyst", "supervisor"],
    "groups": ["intelligence", "operations"],
    "departments": ["classified_division"]
}
sdk.set_policy(sovereign_policy)

# Step 3: Pre-generate RBAC keys for all authorised users
# Keys are generated now, stored in HSM, distributed to users via secure process
# No runtime API call is needed when users access the system

analyst_key = sdk.rbac.generate_user_secret_key({
    "roles": ["analyst"],
    "groups": ["intelligence"],
    "departments": ["classified_division"]
})

supervisor_key = sdk.rbac.generate_user_secret_key({
    "roles": ["analyst", "supervisor"],
    "groups": ["intelligence", "operations"],
    "departments": ["classified_division"]
})

# Step 4: Store keys in HSM under individual user key-encryption keys
# Each user's RBAC key is wrapped under their personal KEK in the HSM
# Users authenticate to the HSM to unwrap their key at session start

print("Key ceremony complete. All keys generated and stored in HSM.")
print("Ceremony must be documented and signed by both custodians.")

After the ceremony, the HSM holds all key material. The provisioning workstation retains only key handles, not key bytes. Key handles are configuration items, not secrets. The handles are deployed to the inference tier servers as part of normal configuration management.

Local policy enforcement

AgentIQ policy enforcement without cloud connectivity

In a standard deployment, the AgentIQ policy engine calls the Mirror Security API to evaluate policies. In a sovereign deployment, you run an on-premises AgentIQ instance that handles policy evaluation entirely within the physical boundary.

The on-premises instance receives your deployed policies during the provisioning process. Policy updates in a sovereign environment go through the same controlled change management process as any other software update: verified, approved, tested in a parallel environment, then deployed via the approved media transfer process.

from mirror_sdk.ops.mirror_decorators import policy_monitor
from mirror_sdk.core.mirror_core import MirrorConfig

# All requests go to the on-premises AgentIQ instance
# No call ever reaches the internet
config = MirrorConfig(
    api_key="on-premises-key",
    server_url="https://agentiq.internal.yourorg.gov",
    telemetry_enabled=True,
    policy_eval_enabled=True
)

@policy_monitor(name="sovereign_agent_policy", mirror_config=config)
async def classified_query_handler(user_query: str) -> str:
    """
    Handles queries against classified document corpus.
    Policy evaluation runs on the on-premises AgentIQ instance.
    Retrieval runs against the on-premises encrypted vector store.
    Inference runs on local GPU with VectaX FHE.
    No component of this function reaches an external network.
    """
    # Your sovereign inference logic here
    # All components are on-premises
    return "[sovereign inference result]"

Real-world tradeoffs

Operational considerations

Sovereign AI deployments involve tradeoffs that cloud deployments do not. Understanding them before you commit to the architecture prevents expensive surprises.

Regulatory mapping

Compliance mapping for sovereign AI

Common questions

FAQ