Sovereign Installation Checklist

This checklist is completed by the installing engineer during ABS Core deployment. It confirms that the installation meets the organization's security and data sovereignty requirements.

A printable version is available at tools/sovereign-checklist.html in the ABS Core distribution.

---

Section 1: Data Sovereignty (Critical)

1.1 Ed25519 signing keys generated locally on this server

Expected: YES

The KeyProvider generates Ed25519 key pairs on the local machine. Private keys are stored on the local filesystem (default: ~/.abs/keys/) or in an environment variable. They are never transmitted to ABS Cloud or any external service.

DPO Translation: No cryptographic material leaves the data controller's infrastructure. Key generation is a local operation with no network dependency.

1.2 Governance decisions processed locally

Expected: YES

The policy evaluation engine runs entirely on-premise. ALLOW, DENY, and ESCALATE decisions are computed locally without any external API call. The engine operates at full capacity even when the server has no internet connection.

DPO Translation: Personal data processed by AI agents is never transmitted to third parties for governance decisions. All processing occurs within the data controller's technical and organizational measures.

1.3 Hash chain ledger stored on local filesystem

Expected: YES

The immutable audit ledger (SQLite) resides on the local disk. There is no automatic replication to cloud services. The optional Backup Vault service encrypts data with the customer's key (E2EE) before transmission.

DPO Translation: Audit records containing metadata about AI agent operations are stored under the data controller's exclusive control.

1.4 Compliance reports generated locally

Expected: YES

NIST AI RMF reports, SovereignAuditRecords, and compliance exports are rendered on the local machine. No audit data is transmitted during report generation.

DPO Translation: Compliance documentation is produced without data transfers to sub-processors.

---

Section 2: Network and Connectivity (Standard)

2.1 Internet access required for governance execution

Expected: NO

ABS Core operates fully offline. The governance engine, policy evaluator, hash chain, and key management all function without network access. Air-gapped deployments are explicitly supported.

DPO Translation: The system does not require internet connectivity to perform its primary function, eliminating a category of data breach risk.

2.2 Outbound connections limited and customer-controlled

Expected: YES

The only outbound connections are optional:

• License heartbeat (1x/day): Sends license key + machine fingerprint. No customer data.
• TSA Relay (async): Sends SHA-256 hash only. Mathematically impossible to reverse.
• Update check: Downloads signed binaries. No upload.

All outbound connections can be disabled by the customer's firewall without affecting governance operations.

DPO Translation: All network communications are outbound-only, optional, and contain no personal data or audit content.

2.3 Logs, audit trails, or telemetry sent to ABS Cloud

Expected: NO

Zero telemetry. Zero log export. Zero tracking. ABS Core does not phone home with usage data, error reports, or behavioral analytics.

DPO Translation: No data processing activities occur on the vendor's infrastructure unless explicitly opted in by the data controller (e.g., Backup Vault).

---

Section 3: License and Enforcement (Standard)

3.1 License activated with valid key

Expected: YES

Each SovereignAuditRecord includes a license_status field that records whether governance was in FULL, GRACE_PERIOD, or AUDIT_ONLY mode at the time of the decision.

DPO Translation: Audit records provide proof that the governance system was fully operational during the compliance period.

3.2 Grace period policy documented

Expected: YES

After license expiry, the system continues full enforcement for 30 days (GRACE_PERIOD). After 30 days without renewal, the system enters AUDIT_ONLY mode: decisions are recorded but not enforced.

DPO Translation: There is a documented, predictable degradation path. The system never silently stops recording decisions.

3.3 AUDIT_ONLY liability clause included in contract

Expected: YES

The customer's contract should include a clause stating that the customer assumes responsibility for any governance failures occurring during AUDIT_ONLY mode due to non-renewal.

DPO Translation: The allocation of liability for governance gaps is contractually defined between the data controller and the vendor.

---

Section 4: Update Security (Critical)

4.1 Engine updates verified with dual signature

Expected: YES

Every engine update binary is signed with two keys:

• Development key (online, used during build)
• Production key (offline, cold wallet)

The host system accepts updates only when both signatures are valid.

DPO Translation: Supply chain integrity is maintained through cryptographic verification of all software updates. No single compromised key can inject malicious code.

4.2 Engine fingerprint recorded in each SAR

Expected: YES

The engine_fingerprint field in every SovereignAuditRecord contains the SHA-256 hash of the running engine binary. This creates an auditable record of which exact software version produced each governance decision.

DPO Translation: Software version provenance is cryptographically recorded, enabling post-incident forensic analysis.

---

Section 5: Backup and Recovery (Optional)

5.1 Ledger backup schedule configured

Expected: RECOMMENDED

Daily JSONL export with SHA-256 checksum verification. The backup utility verifies chain integrity during export.

DPO Translation: Business continuity measures protect the integrity of the governance audit trail.

5.2 Cloud Backup Vault opted-in

Expected: CUSTOMER CHOICE

If enabled, backups are encrypted with the customer's key before transmission. ABS Cloud stores the encrypted blob but cannot decrypt it (zero-knowledge architecture).

DPO Translation: If cloud backup is used, it operates under end-to-end encryption with the data controller holding the sole decryption key. The vendor is a data processor with no access to the encrypted content.

---

Attestation

Upon completion, both the installing engineer and the CISO/Security Officer should sign the printed checklist with:

• Organization name
• Installation date
• ABS Core license key
• Engine fingerprint (SHA-256)

This document is retained by the customer for audit purposes. It is not transmitted to ABS Core.

---

Related

• NIST AI RMF Mapping -- Control-level compliance evidence
• RFC 3161 Verification -- Temporal proof integrity
• Air-Gapped Operations -- Deployment without internet