Security & Privacy

Security & Privacy

How CODEX protects data through controlled deployments, European infrastructure, and layered safeguards—without overstating guarantees.

Last updated: 2025-10-11

Security & Privacy

CODEX is designed for sovereign administrative environments—where systems are fragmented, trust is imperfect, and auditability matters. This page describes our security and privacy approach at a practical level. It is intentionally concise.

If a signed agreement exists, the agreement governs in case of differences.

Summary

  • European infrastructure: CODEX runs on raw infrastructure from OVHcloud and Hetzner.
  • Data residency: Data is stored in France or Germany, as specified by the applicable contract and deployment configuration.
  • Deployment control: We operate and harden the stack ourselves—operating systems, network boundaries, reverse proxies, application runtime, and encryption layers.
  • Backups: Databases are backed up frequently and rotated on a 7–14 day window (deployment-dependent). Deleted data may remain in backups until rotation completes.
  • Privacy posture: We minimize personal data collection and separate identity from operational records where feasible.
  • No sale / no training: We do not sell customer content, and we do not use customer content to train AI models.

Infrastructure and data residency

CODEX runs on dedicated or virtualized infrastructure provisioned from OVHcloud and Hetzner. We use these providers as raw compute and storage. We do not depend on “managed platform” features for core security boundaries.

Where data lives: Production data is stored in France or Germany. The exact region, redundancy model, and any cross-region replication are defined in the contract and deployment scope.

Operational control

We control the deployment environment end-to-end at the infrastructure and application layers:

  • We provision and harden hosts (OS baseline, patching, minimal services).
  • We control network boundaries (segmentation, inbound restrictions, service-to-service controls).
  • We operate edge routing (dedicated reverse proxies for API and application traffic).
  • We isolate backend communication (virtual private networks between backend machines, including encrypted service-to-service paths).

This differs from typical “public cloud defaults”. The security posture comes from direct operational control, not opaque managed services.

Encryption and transport security

Encryption is layered. It protects data in transit, at rest, and in backups, while remaining transparent about functional boundaries.

1) Encryption in transit

  • TLS for client traffic: We use modern transport security (TLS) for browser ↔ edge traffic.
  • Separated API ingress: API traffic is routed through dedicated reverse proxies at the edge.
  • Encrypted internal network: From the edge, traffic is forwarded through our own encrypted network paths (for example, WireGuard-based VPNs) to the services that process requests.

2) Encryption at rest

  • Disk encryption: Servers, databases, and storage volumes use full-disk encryption at rest (AES-256 class). On Linux, this is implemented via OS-level disk encryption (e.g., LUKS).

    • If a machine powers down or a disk is removed/discarded, the contents remain cryptographically scrambled, including the operating system partitions.
    • Encryption keys are operated under Abyrint control within the deployment model, not exposed as a general “managed cloud” convenience feature.

  • Blob-level encryption: File objects (“blobs”) are encrypted individually on the server side before being written to storage.

  • Encrypted backups: Database backups are encrypted as independent artifacts.

3) End-to-end encryption boundary

Abyrint uses end-to-end encryption (E2EE) tooling in other contexts where content is encrypted on the user’s device and is not readable from stored files or databases.

CODEX does not provide end-to-end encryption for workspace content. CODEX must be able to read and process the data it holds in order to build abstractions, lineage, overlays, and verification outputs. This is a normal and practical boundary for systems that compute on your data; we state it explicitly for clarity.

Access control and administrative boundaries

CODEX is not designed for open public sign-ups. Access is controlled and provisioned.

  • Role-based permissions restrict access to workspaces and functions.
  • Administrative access to production systems is restricted to a small number of authorized Abyrint operators.
  • Support access is controlled and logged. We do not provide broad internal access to customer data by default.

Where feasible, we separate:

  • identity and account metadata (needed for access) from
  • operational workspace content (the data you work with).

Logging, monitoring, and abuse prevention

To protect service integrity, CODEX maintains operational logs for:

  • authentication and session events,
  • abnormal access patterns,
  • service health and error diagnostics.

Logs are designed to avoid storing unnecessary personal data, but some metadata (e.g., IP addresses during authentication and abuse detection) may be processed for security and operational reasons. Retention is limited and governed by operational need and contractual scope.

We apply rate limits and abuse controls to reduce automated attacks and misuse.

Backups and resilience

Backups exist to protect availability and recoverability. Backup handling follows the same residency and access controls as production, within the agreed deployment scope.

  • Backup frequency: Databases are backed up frequently (deployment-specific cadence).
  • Rotation: Backups are typically rotated out after 7–14 days (depending on deployment and contract scope).
  • Deletion behavior: Because backups are point-in-time copies, deleted data may persist in backups until those backups rotate out. After rotation completes, data is irrecoverable from backups under normal operating procedures, unless the contract specifies a different process.

Privacy: what we collect and why

We aim to collect the minimum needed to operate the service.

Typically, CODEX processes:

  • Login identifiers used only to establish and administer access (for example, an email address at sign-in).
  • Security metadata used to protect sessions and detect misuse (for example, IP address and device/session information). This metadata is retained for a limited period and, where the product supports it, can be cleared by the user.
  • Workspace content provided by users or ingested from authorized sources.

Inside the platform, CODEX operates on opaque system identifiers assigned algorithmically. These identifiers are used for attribution, lineage, and audit integrity—without repeatedly embedding personal identifiers into operational records.

If a user is de-provisioned or leaves a team, their email record is deleted from production systems as part of offboarding. The system identifiers may persist in historical logs and artifacts to preserve referential integrity and auditability. Content created within a workspace remains part of the organization’s workspace resources, subject to the applicable agreement and workspace policies.

We do not sell user data. CODEX does not run ad tracking, Google Analytics, or similar third-party marketing telemetry.

CODEX runs on European infrastructure and does not depend on hyperscaler platforms for core hosting. Customer data is stored and processed within the EU (France or Germany, per deployment).

For performance, we may use a content delivery network (CDN) to serve public site assets (for example, JavaScript, CSS, images). Customer content and core API traffic do not traverse the CDN path. In practice: CDNs may help the website load faster, but they are not used to carry your organization’s data.

Customer content is transmitted directly to our EU-based edge and backend systems over TLS using certificates issued by European certificate authorities. Where we deploy edge collectors inside a client environment, those collectors authenticate using mutual TLS (mTLS) certificates provisioned and controlled by Abyrint.

Data sharing and third parties

Abyrint is the primary operator of CODEX. Infrastructure providers (OVHcloud and Hetzner) provide the underlying compute/storage facilities.

  • No sale / no advertising: We do not sell or rent customer content.
  • No AI training on customer content: We do not use customer content to train AI models, and we do not provide customer content to third parties for AI training.
  • Narrow third-party services: Depending on deployment configuration, we may use narrowly scoped services for specific functions (for example, transactional email). For transactional email we use Scaleway (France). Where third parties are used, they are selected to align with European residency and contractual requirements.

We do not rely on third-party cloud “black box” security controls for core platform security.

Consulting operations vs CODEX

Abyrint may handle operational data outside CODEX in the course of broader engagements (documents, internal coordination, client collaboration). That operational handling is separate from CODEX platform controls.

When an engagement uses CODEX as the working environment, CODEX policies and controls apply within the agreed scope.

Security contact

For security or privacy questions related to CODEX, contact the engagement owner or reach us via:

abyrint.com/about/contact