Security Addendum

Last Updated: February 23, 2026 Effective Date: Upon acceptance of the Master Service Agreement

1. Purpose

This Security Addendum describes the technical and organizational security measures implemented by Tacitus Systems to protect Customer Data, Customer Content, and Vector Embeddings across the Cloud Bridge and Cortex deployment models.

For definitions of capitalized terms, refer to the Master Service Agreement, Section 2.

2. The Sovereignty Pledge

Tacitus Systems makes the following binding commitments:

2.1 No Training on Customer Data

We do not use Customer Data, Customer Content, Vector Embeddings, or any derivative thereof to train, fine-tune, distill, or improve AI models. This prohibition extends to all sub-processors engaged by Tacitus Systems. Models operate in inference-only mode. For details, refer to the AI Policy.

2.2 No Silent Access

Cortex Mode. The appliance operates in an air-gapped environment. Tacitus Systems has physically no access to Customer Data. No outbound network connections to Tacitus Systems or any third party are possible.
Cloud Bridge Mode. Each Customer operates a single-tenant instance with dedicated encrypted storage volumes. Tacitus Systems does not access Customer’s encrypted storage volumes except: (a) when explicitly authorized by Customer for support purposes, or (b) when required by applicable law or valid court order.

2.3 Non-Custodial Encryption

Tacitus Systems does not store, escrow, or have access to Customer’s Master Mnemonic or derived encryption keys. The Customer is the sole custodian of all cryptographic material necessary to decrypt their data.

3. Encryption Standards

3.1 At Rest

All Customer Data is encrypted at rest using AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode). Encryption is applied at the object level: no implementation writes plaintext Customer Data to any storage medium.

3.2 Key Derivation

Encryption keys are derived from the Customer’s BIP39 Master Mnemonic using HKDF-SHA256 (HMAC-based Key Derivation Function). Purpose-specific sub-keys are derived for:

Storage encryption (AES-256-GCM for files at rest).
Deduplication indexing (HMAC-SHA256 for document fingerprinting).

This architecture enables stateless recovery: restoring the Master Mnemonic restores access to all encrypted assets without requiring a separate key backup.

3.3 In Transit

All API communications are encrypted using TLS 1.3. Internal service-to-service communication within the container orchestration layer uses encrypted channels.

3.4 Cortex: Full-Disk Encryption

Cortex storage volumes are protected by LUKS (Linux Unified Key Setup) partition encryption, layered on top of the object-level AES-256-GCM encryption. The LUKS key is sealed by the TPM 2.0 module and released only when boot integrity measurements (PCRs) confirm the hardware and operating system have not been tampered with.

4. Hardware Security (Cortex)

4.1 TPM 2.0 Hardware Binding

Each Cortex unit contains a Trusted Platform Module (TPM) 2.0. During provisioning, the Master Mnemonic is encrypted by the TPM using the unique hardware signature of the motherboard. The system auto-decrypts the Mnemonic into RAM only when Platform Configuration Register (PCR) measurements confirm hardware and OS integrity.

Consequence: If NVMe storage drives are physically removed from the Cortex chassis, they cannot be decrypted without the specific motherboard’s TPM. Stolen drives yield only ciphertext.

⚠ Motherboard failure risk. The LUKS encryption key is sealed by the TPM 2.0 module and is bound to the specific motherboard. In the event of motherboard failure, the NVMe drives cannot be decrypted using a replacement motherboard, as the TPM seal is unique to the original hardware. Customers are strongly advised to: (a) maintain an offline backup of their Master Mnemonic in a secure, offline location, and (b) use the RAID 1 configuration to reduce the risk of data loss due to a single-drive failure. Data recovery is possible from the Master Mnemonic alone, but only if the Mnemonic has been preserved.

4.2 NVMe RAID 1 Mirroring

Cortex storage is configured in RAID 1 (mirroring) across paired NVMe drives:

Boot partition (md0): Mirrored across Drive A and Drive B.
Data partition (md1): Mirrored across Drive A and Drive B, LUKS-encrypted.

If a single drive fails, the system continues operating on the remaining drive without data loss or downtime. The Watchdog service monitors /proc/mdstat for degradation and triggers alerts upon detecting a fault.

4.3 Chassis Intrusion Detection

Cortex units are designed to support hardware-level chassis intrusion detection. This feature is not yet active in the current software release and may or may not be implemented in a future Supply Drop. When available, the Shield Protocol (described in the Hardware Lease Terms) will govern the response to unauthorized chassis access. Current units do not have active hardware intrusion sensors.

4.4 USB Lockdown

Mass storage devices are blocked on all ports except designated “Service Ports” used for Supply Drop ingestion and Flight Recorder export. USB policy is enforced via udev rules at the operating system level.

5. Volatile Ingestion Pipeline

During document ingestion, uploaded files must be temporarily written to disk for OCR processing. Tacitus Systems eliminates the risk of plaintext data remnants through the following architecture:

Shared RAM Disk (tmpfs). The ingestion scratch volume is mounted as a tmpfs filesystem in volatile memory (RAM), not persistent storage.
Capacity. 1 GB hard limit per instance.
Lifecycle. Files are written to RAM during upload, processed by the OCR and embedding pipeline, and deleted upon completion.
Fail-Safe. In the event of power loss, kernel panic, or container restart, all data in the tmpfs volume vanishes instantly. Unprocessed documents are cryptographically unrecoverable because they were never written to a persistence layer.

6. Tenant Isolation

6.1 HMAC Deduplication Shield

Each Tacitus Systems instance generates document identifiers using HMAC-SHA256 with an instance-specific cryptographic salt. Even if two separate Customers upload an identical document, the resulting database identifiers and vector signatures are mathematically different. This prevents cross-tenant metadata correlation or deduction.

6.2 Cloud Bridge: Isolation Architecture

Each Customer’s Cloud Bridge instance is deployed as a single-tenant, independent environment with dedicated encrypted storage volumes. Strict network policy ensures no cross-tenant communication is possible. Tacitus Systems may implement this isolation using Kubernetes namespace isolation (with NetworkPolicy enforcement) or through equivalent per-customer dedicated instance deployment, depending on the service tier. The security guarantees are equivalent regardless of the underlying orchestration method:

Shared Silicon (entry tier): Single-tenant instance with strict network isolation enforcing Deny All Ingress except from Customer’s own services. Resource controls prevent “noisy neighbor” interference.
Sovereign Tenant (production tiers): Dedicated compute resources with exclusive lock on physical GPU hardware. Dedicated NVMe block storage. No shared compute resources with any other Customer.

6.3 Cortex: Physical Isolation

Cortex units are air-gapped by design. The host firewall (UFW) is configured to:

Deny ALL Outgoing traffic.
Allow Incoming from LAN on Port 443 only.

No outbound connections to Tacitus Systems, LLM providers, or any external service are possible.

7. Host & Container Security (Cortex)

7.1 Operating System

Ubuntu Server 24.04 LTS (minimized installation).
snapd removed to eliminate unauthorized background update channels.
CIS Benchmark Level 1 hardening applied.
AppArmor mandatory access control profiles enforced for all containers.

7.2 Container Security

Base image: Google Distroless (gcr.io/distroless/cc-debian12). No shell, no package manager, minimal attack surface (~50 MB).
Rootless execution: All services run as non-root user (UID 10001).
Read-only root filesystem enforced where operationally feasible.

8. Supply Drop Integrity

Software updates for Cortex units are delivered via the Supply Drop protocol, which preserves the air-gap while ensuring update authenticity:

State Manifest. The Cortex unit generates a State Manifest containing hardware identifiers, software version numbers, and optionally operational telemetry data (CPU/GPU utilization, RAID status, uptime metrics). This manifest contains no Customer Data, Customer Content, or personally identifiable information.
Package Generation. Customer uploads the manifest to the Tacitus Systems portal. The portal verifies the Customer’s subscription and generates a tailored package.
Cryptographic Signing. Every Supply Drop is signed with Tacitus Systems’ Ed25519 signing key.
Verification. Upon ingestion, the API Gateway verifies the Ed25519 signature before applying the update. Packages with invalid or missing signatures are rejected.
Application. Verified updates are applied locally via container image loading. No external network connectivity is required.

9. Flight Recorder Protocol

The Flight Recorder provides a privacy-preserving diagnostic mechanism for air-gapped Cortex units:

Trigger. Customer inserts a blank USB drive into the designated Service Port.
Collection. The system aggregates container logs, kernel logs (dmesg), and service health metrics.
PII Redaction. An automated redaction engine scrubs personally identifiable information (names, dates, currency amounts, identification numbers) using pattern-matching rules before any data leaves the system.
Encryption. The redacted log bundle is encrypted with Tacitus Systems’ public GPG key. Only Tacitus Systems support personnel can decrypt the contents.
HMAC Verification. Logs are tagged with the instance’s HMAC salt, ensuring that diagnostic data from one unit cannot be used to deduce the file structure or metadata of another unit.
Export. The encrypted bundle is saved to the USB drive. Customer transmits the file to Tacitus Systems support via email or secure upload.

Customer cannot read raw Flight Recorder logs (protecting Tacitus Systems IP). Third parties who intercept the USB drive cannot read the contents (GPG encryption).

10. Data Deletion & Certified Erasure

10.1 Document Deletion (During Service)

When a document is deleted through the platform interface:

Encrypted file deletion. The encrypted document is removed from the storage layer. Because all documents are encrypted at rest using AES-256-GCM with customer-held keys, the deleted ciphertext is cryptographically unrecoverable — deletion of the file makes the data permanently inaccessible without requiring physical overwrite. Physical overwriting with zeros is not required because data is encrypted with a key held solely by Customer. Even if raw storage were forensically recovered, it would yield only ciphertext. This approach follows NIST SP 800-111 guidance that encryption provides equivalent or superior security to physical overwrite for media sanitization.
Vector purge. All vector embeddings associated with the document are deleted from the Qdrant database via document_id filter.
Database cleanup. Metadata records are removed from SQLite. VACUUM operations are performed periodically to reclaim space.

10.2 Cloud Bridge Termination

Upon termination of a Cloud Bridge subscription, all single-tenant volumes are cryptographically erased. A written certification of erasure is provided upon request.

10.3 Cortex Hardware Return

When a Cortex unit is returned under the Secure Return Protocol:

Customer may remove and retain (or witness the destruction of) the physical NVMe storage drives.
If drives remain in the unit, Tacitus Systems performs verified “Secure Erase” before chassis refurbishment.
A certificate of destruction is provided upon request.

11. Incident Response & Breach Notification

11.1 Detection & Assessment

Tacitus Systems maintains continuous monitoring of Cloud Bridge infrastructure through the Watchdog service, which performs health checks every couple of seconds on all critical services. Anomalies are escalated for human review.

11.2 Notification Timeline

Action	Timeline
Notification to affected Customer(s)	Within 48 hours of becoming aware of a confirmed breach
Notification to UODO (Polish supervisory authority)	Within 72 hours as required by GDPR Article 33
Preliminary incident report to Customer	Within 5 business days
Post-incident report with root cause analysis	Within 30 days

11.3 Notification Contents

Breach notifications shall include: (a) the nature of the breach, (b) the categories and approximate number of data subjects affected, (c) the likely consequences, (d) the measures taken or proposed to mitigate the breach, and (e) the contact point for further information.

11.4 Cortex Incidents

For Cortex units, Tacitus Systems has no visibility into Customer Data. If a security vulnerability is discovered in the Tacitus Systems software stack, Tacitus Systems will: (a) issue a security advisory, (b) provide a priority Supply Drop with the fix, and (c) notify Customer of the urgency level.

12. Monitoring & Health

12.1 Watchdog Service

The Watchdog service performs automated health monitoring:

Service	Probe	Interval	Failure Response
API Gateway	`GET /api/health`	30 seconds	Log warning, increment failure counter
Qdrant (Vector DB)	`GET /healthz` (gRPC)	30 seconds	Log error, trigger alert
OCR Service	`GET /health`	60 seconds	Log warning (non-critical)
Redis (Job Queue)	`PING` command	15 seconds	Log error, trigger alert

12.2 Auto-Recovery

Container hang detected: Immediate container restart.
Critical failure (3 consecutive failures): Full system hardware reboot to clear GPU memory and reinitialize CUDA cores.

12.3 RAID Monitoring

The Watchdog monitors /proc/mdstat for RAID degradation. A degraded array triggers an entry in the maintenance_log.

13. Certification Roadmap

Tacitus Systems is committed to achieving the following certifications:

Certification	Status
ISO 27001	Planned
SOC 2 Type II	Planned

Until formal certifications are obtained, the security posture described in this Addendum represents Tacitus Systems’ documented commitment. Customers may exercise audit rights as described in the Data Processing Addendum, Section 9.

14. Contact

For security inquiries, vulnerability reports, or incident-related communications:

Tacitus Systems Ul. Krótka 7 97-200 Tomaszów Mazowiecki Poland Email: contact@tacitussystems.com