Air-Gapped Audits: Running Compliance Checks on a Sovereign AI Without Network

Auditing an AI system that has zero network connectivity conflicts with most modern compliance tooling. Cloud-based scanners, remote attestation services, and SaaS logging platforms all assume the system can phone home. But for sovereign AI deployments—medical diagnostics, military command-and-control, or critical infrastructure—air-gapping is non-negotiable. The EU AI Act demands audits, but it does not require internet access. You can run thorough compliance checks entirely offline.

This article outlines a practical methodology for auditing an air-gapped sovereign AI stack. We'll cover hardware-rooted attestation, immutable logs, offline model scanning, and reproducible inference verification. No marketing, no theory—just the tools and commands you need.

The Threat Model

Before designing an audit process, understand what we're protecting against. An air-gapped system is isolated from external networks, but it's still vulnerable to:

• Unauthorized model modification – someone swaps the deployed model with a backdoored version.
• Data leakage – inference logs contain PII that shouldn't leave the enclave.
• Policy drift – the system's behavior changes over time due to corrupted weights or configuration tampering.
• Insider threats – an operator with physical access alters audit logs.

The audit must detect any of these without relying on network connectivity. The answer is a combination of hardware-based trust anchors, cryptographic logs, and offline verification tools.

Hardware Root of Trust: TPM 2.0

A Trusted Platform Module (TPM 2.0) is the foundation. It provides a hardware-bound key store and platform measurement registers (PCRs) that record the boot chain and loaded software. For an air-gapped AI server, use the TPM to:

• Seal secrets (e.g., model encryption keys) to specific PCR values.
• Generate attestation quotes that prove the system state at boot.
• Sign audit logs with a key that never leaves the TPM.

Enable TPM 2.0 in your BIOS and verify it's active:

# Check if TPM is present
ls /dev/tpm0
# List PCR values
tpm2_pcrread

You'll need tpm2-tools (version 5.0+). The TPM's endorsement key (EK) is unique per device and can be used to create an attestation identity key (AIK) for signing.

Immutable Logging with systemd-journald and Forward Secure Sealing

Standard logs are mutable. An attacker with root can delete or modify them. Use forward secure sealing (FSS) to make logs tamper-evident. systemd-journald supports FSS natively since v246.

Configure /etc/systemd/journald.conf:

[Journal]
Seal=yes
SplitMode=journal

Then generate an FSS key and start sealing:

journalctl --setup-keys
# Store the key offline (print it and store in a safe)
journalctl --rotate

Each journal entry is hashed and linked to the previous entry via a Merkle tree. The seal key is required to verify the chain. Without it, you can't forge new entries or backdate them. Store the key on a separate air-gapped USB drive used only for audits.

Offline Model Verification with Cryptographic Hashes

Every model you deploy should have a known-good hash. Use SHA-256 or BLAKE3. Store the hash in a signed manifest file that is itself signed by the TPM AIK.

Generate the manifest at deployment time:

# Compute hash of the model file (e.g., llama-2-7b.gguf)
sha256sum /models/llama-2-7b.gguf > /audit/manifest.sha256
# Sign the manifest with TPM AIK
tpm2_sign -c aik.ctx -f plain -o manifest.sig /audit/manifest.sha256

During an audit, verify the signature and hash:

# Verify signature
tpm2_verifysignature -c aik.pub -f plain -m manifest.sha256 -s manifest.sig
# Verify hash
sha256sum -c manifest.sha256

If the model is split into shards (e.g., for LoRA adapters), hash each shard and include them in the manifest.

Reproducible Inference Verification

A model can be unmodified but still produce different outputs due to non-determinism in GPU kernels or floating-point rounding. To verify inference behavior, run a fixed set of test inputs and compare outputs against a golden reference.

Create a test suite:

[
  {"input": "What is the capital of France?", "expected": "Paris"},
  {"input": "Explain the EU AI Act in one sentence.", "expected": "It is a regulation governing AI systems based on risk."}
]

Run the model with deterministic settings (seed, temperature=0, top_p=1):

./llama-cli -m /models/llama-2-7b.gguf -f test_prompts.json --seed 42 --temp 0 --top-p 1 --repeat-penalty 1.0

Compare outputs character-by-character. Any deviation indicates a change in the model or inference stack. Script this and include it in the audit report.

Offline Model Scanning for Malware

Models can contain hidden payloads. Use llama.cpp's built-in metadata inspection and a custom scanner that looks for suspicious patterns (e.g., large weight outliers, unexpected tensors). For a more thorough scan, run binwalk on the model file:

binwalk -Me /models/llama-2-7b.gguf

This extracts embedded files and signatures. Also check the model's tokenizer for unusual tokens that might encode commands.

Audit Workflow: Step-by-Step

1. Pre-deployment: Generate TPM AIK, create FSS key, compute model hashes, sign manifest. Store keys offline.
2. Daily: systemd-journald seals logs automatically. Inference logs are hashed and stored on a read-only partition.
3. Monthly (or per policy): An auditor physically visits the site with a laptop that has the offline verification tools. No network connection is required.
   • Boot the server into a known-good state (verified by TPM quote).
   • Verify the FSS chain using the stored seal key.
   • Recompute model hashes and compare to signed manifest.
   • Run the deterministic inference test suite.
   • Extract and scan the model with binwalk.
4. Report: Generate a signed PDF of findings using the auditor's own key.

Tooling Summary

All tools run offline. No internet access required.

EU AI Act Specifics

The EU AI Act requires high-risk AI systems to be auditable (Articles 9, 10, 17). Specifically:

• Article 12: Logging capabilities must be built in. Our FSS-based logging satisfies this.
• Article 17: Documentation and technical documentation must be available. The signed manifest serves as technical documentation.
• Article 19: Conformity assessment. An auditor can verify the system's state without relying on the provider's infrastructure.

The air-gapped audit methodology provides a chain of custody that is verifiable by a third party. The TPM ensures the hardware hasn't been tampered with, and the sealed logs provide non-repudiation.

Limitations

• Physical access required: The auditor must be on-site. This is a feature, not a bug, for sovereign deployments.
• No runtime monitoring: We cannot detect attacks that modify the model in memory. Use signed boot and kernel lockdown (CONFIG_LOCK_DOWN_KERNEL) to mitigate.
• Auditor trust: The auditor must be trusted to not leak the seal key. Use hardware security modules (HSMs) for auditor keys.

Conclusion

Air-gapped audits are not only possible but can be more secure than cloud-dependent alternatives. By leveraging TPM 2.0, forward secure sealing, and offline verification tools, you can meet the EU AI Act's audit requirements without compromising data sovereignty. The methodology is concrete, tool-specific, and reproducible. Implement it before your next compliance review.