Jaxon Security and Trust: A Guide for Commercial Partners

1. Purpose and Scope

This document outlines Jaxon's commitment to Security Assurance and Transparency for our commercial partners. It explains the threat model, architectural decisions, and operational controls that collectively ensure the confidentiality, integrity, availability, and auditability of your data within the DSAIL system.

At Jaxon, we view security as a foundational pillar of our partnership. This guide provides a comprehensive overview of the design intent behind our security controls, ensuring our technical safeguards align with the high-stakes requirements of the insurance industry.

Scope includes:

API and service architecture
Identity and access control
Data protection (in transit and at rest)
Long-running operations and workers
Logging and auditability
Infrastructure and operational posture

Out of scope:

Detailed cryptographic algorithms
Vendor-specific compliance paperwork
UI-level security ergonomics

2. Security Objectives

The platform is designed to meet the following security objectives:

Least Privilege by Default Every access—human or service—is scoped by asset type, operation, and version.
Immutability and Traceability All versioned assets are immutable. All executions and operations are durable and auditable.
Separation of Concerns Control planes (API, orchestration) are separated from data planes (execution, compilation, blob storage).
Defense in Depth No single control is relied upon exclusively; network, identity, cryptographic, and application-level controls overlap.
Explicit Long-Running Work Semantics Asynchronous work is modeled explicitly via Operations, enabling cancellation, audit, and recovery.
Confidence through Transparency System behavior is observable, explainable, and reviewable, providing you with full visibility into how your data is processed and protected.

3. Threat Model (High Level)

The platform assumes:

External clients are untrusted.
Internal services are not inherently trusted simply because they are "inside the network."
Documents and artifacts may contain sensitive or regulated data.
Operational logs are a potential leakage vector.
Failures and restarts are normal and must not cause data loss or silent corruption.

Threats considered include:

Unauthorized access to assets or versions
Privilege escalation via mis-scoped APIs
Data exfiltration via logs or debug tooling
Replay or duplication of long-running jobs
Partial execution leading to inconsistent state
Insider misuse of debugging or maintenance access

4. Architectural Overview (Security-Relevant)

The system consists of:

API Service (FastAPI) Stateless HTTP interface enforcing authentication, authorization, validation, and audit logging.
NGINX Reverse Proxy TLS termination, rate limiting, request size enforcement, and auth gateway (Authentik) integration.
Operations Orchestration (Temporal) Durable workflow engine responsible for executing and tracking long-running operations.
Worker Services
- Ruleset Executor: executes rulesets against documents/datasets
- Ruleset Builder: performs rule derivation, validation, and compilation
- Others TBD as functionality expands, subject to the same controls
Workers run Temporal Workers as their entrypoint. * Postgres (Metadata & State) System of record for assets, versions, runs, operations, RBAC, and audit-relevant metadata. * Object Store (NGINX + filesystem) Storage for document content, attachments, and build artifacts. * LLM Proxy (LiteLLM) Gateway for all LLM operations.

4.1 LLM Proxy and External Model Security

Workers access LLMs exclusively via a liteLLM proxy.
The proxy enforces:
- model allowlists (as exposed via GET /llms)
- per-deployment configuration
- provider-specific logging controls (including "no logging" backends)
Security implications:
- API and workers never embed provider credentials directly.
- Provider credentials are scoped to the proxy and rotated independently.
- LLM traffic is considered data egress and must be TLS-protected.

This isolates third-party model risk from core platform services.

5. Identity, Authentication, and Authorization

5.1 Authentication (Authentik)

To protect your sensitive data, the platform utilizes a robust Zero-Trust approach to identity, using Authentik as the identity provider via OAuth2/OIDC.
Every access attempt is individually authenticated and authorized, ensuring that only verified users and services can interact with your assets.
JWT validation (issuer, audience, signature, expiry) is enforced at the API boundary.
Service-to-service authentication uses TLS certificates or service identities.
No anonymous or shared credentials are permitted.

Implications re Authentik default accounts:

Default Authentik admin and bootstrap accounts must be disabled or rotated immediately after install.
No Authentik "local admin" credentials are permitted for routine operations.
All admin access must be federated (OIDC) and logged.

5.2 Authorization Model

WIth the exception of authentik-admin, users belong to one or more groups (these are effectively teams, not roles). Projects (and all assets within a project) are owned/accessed by groups, using an ownership table tracked in the platform database. This table correlates a project ID to a group ID (and optionally specific permissions on that project assigned to the group). The authorization mechanism works like so:

Any user is a member of (N >= 1) groups, as reported by the X-authentik-groups header.
In the UI, a user will select their active group ("team") from a dropdown list of groups to which the user belongs; this group is tracked in the client state.
API calls, whether from the UI or other programmatic accesses, must provide this active groupname in a separate header X-jaxon-active-group (along with the bearer token).
The API's authorization middleware performs this set of actions:
- Extract the X-authentik-groups list from the Authentik Outpost-injected headers, and verify against the bearer token (which is also required for API requests).
- Ensure that X-jaxon-active-group is a member of X-authentik-groups, rejecting the request if it is not.
- If the request is a POST to create a new project, assign a new row in the ownership table for the active group.
- Otherwise, confirm that the requested assets belong to a project that is owned by the active group.

5.3 Head Pointer Control

Mutable head pointers (e.g., setHead) are treated as explicit administrative actions, not implicit state changes. These actions are:

Authz-protected
Audited
Separate from immutable version creation

This preserves rollback capability without violating immutability guarantees.

6. Data Protection

6.1 Encryption in Transit

TLS 1.2+ (prefer 1.3) is required for:
- Client → NGINX
- NGINX → API
- API → Postgres/Blobstore
- API / Workers → Temporal
- API / Workers → Object Store
Plaintext connections are not permitted, even on internal networks.

Our Priority: Your Data Security

We enforce encryption in transit not only to protect the confidentiality of your data as it moves across the network, but also to verify service identities and prevent unauthorized access, ensuring the highest levels of business continuity.

The platform assumes a realistic threat model in which:

a single service may be compromised,
misconfigurations, SSRF, credential leaks, or container escapes may occur,
internal networks are not inherently trusted.

Under this model, TLS alone is insufficient unless combined with mutual authentication (mTLS) for service-to-service communication.

mTLS ensures that:

every service presents a cryptographic identity,
services can authenticate the identity of their peers,
a compromised service cannot impersonate other services,
lateral movement between services is restricted to explicitly trusted paths.

This design explicitly addresses scenarios where:

one worker or auxiliary service is compromised,
but core services (API, Vault, database, Temporal) must remain protected from unauthorized access.

mTLS does not attempt to protect against full host compromise; that condition is treated as a catastrophic security event and addressed through operational controls, monitoring, and incident response. Instead, mTLS is used to prevent all lesser classes of compromise from escalating into total system exposure.

By requiring TLS for all connections and mTLS for internal service-to-service communication, the platform:

enforces least privilege at the network layer,
prevents unauthorized internal access even when network reachability exists,
provides cryptographic attribution for inter-service calls,
supports auditability and forensic analysis.

This rigorous, layered approach ensures that your business remains protected against sophisticated threats, aligning with the rigorous security standards expected for your mission-critical insurance workloads.

6.2 Encryption at Rest

The platform employs a layered encryption-at-rest model that distinguishes between host-level storage encryption and application-managed encryption.

HashiCorp Vault is used as the sole key management system for application-managed encryption at rest. Vault is a required, first-class infrastructure component in the architecture.

Host-level disk and volume encryption (e.g., LUKS) is required but is managed outside the platform and is not keyed or controlled by Vault.

No alternative application-level key management mechanisms are supported.

Scope of Vault usage:

Vault manages all application-level cryptographic keys, including:

Any application-level database encryption keys (e.g., column-level encryption via pgcrypto).
Application secrets such as database credentials, service credentials, and Temporal credentials.
Internal PKI material used for mTLS.

Vault enforces access control, key rotation, and audit logging for all cryptographic material it manages.

At risk of redundancy with above checklist, here is our list of Vault-protected items:

mTLS identities
Database credentials (postgres, temporal db)
Temporal client credentials
LLM provider credentials (access keys)
- .env for dev, Vault Agent in a sidecar container for prod
Authentik internal secrets (DB password, SMTP creds, OAuth client secrets)

NOT stored in vault:

Authentik credentials

Note:

For dev deployments, .env/config files at docker-compose time may be used for LLM and Authentik bootstrapping. But these must be sourced from Vault in prod deployments.

Storage-layer responsibilities:

Postgres:

Runs on encrypted disks or volumes (LUKS or equivalent), managed at the host or infrastructure layer.
May use Vault-managed keys for application-level encryption where applicable (e.g., pgcrypto).
Does not rely on Vault for disk or filesystem encryption.

Object storage:

Implemented via NGINX writing to the local filesystem.
Server-side encryption is mandatory.
Encryption keys are provided via Vault.
Object storage encryption operates independently of host disk encryption.

Application services:

Never generate, persist, or embed encryption keys.
Never store master encryption keys locally.
Obtain short-lived credentials or derived cryptographic material from Vault at runtime.

Explicit prohibitions:

Encryption keys MUST NOT be:

hard-coded,
checked into source control,
stored in Docker Compose files,
stored in Kubernetes manifests,
injected as long-lived environment variables.

Application-level encryption MUST NOT be implemented using custom or ad-hoc key management mechanisms.

Disk-level encryption alone is not sufficient to meet platform security requirements; it must be complemented by Vault-managed application-level encryption where sensitive data or secrets are involved.

Operational requirements:

Vault access is authenticated using service identity (not static tokens).
Vault audit logging is enabled and retained.
Key rotation policies are defined, enforced, and documented.
Vault sealing and unsealing procedures are documented and operationally controlled.

Business Assurance Rationale:

By centralizing application-level key management in Vault, we provide explicit control and auditability over all cryptographic material. This model eliminates ambiguity in data protection responsibilities and ensures your sensitive information remains secure at rest, supporting your internal security governance requirements.

6.3 Data Minimization

Binary content is never embedded in JSON responses.
APIs expose metadata and references; blobs are streamed or accessed via pre-signed URLs.
Document content and extracted text are never logged.
- Logging of LLM prompts/responses that may contain prompt or content is permitted only at DEBUG level.
- DEBUG-level logging is disabled by default in all production deployments.
  - Enabling DEBUG logging in production requires:
    - explicit deploy-time configuration
    - documented approval
    - time-bounded enablement
- Even at DEBUG, logs must be:
  - tagged with data_classification
  - excluded from long-retention audit indices
- No DEBUG logs are exposed via /operations/{id}/logs unless explicitly authorized.

7. Immutability, Versions, and Auditability

7.1 Immutable Versions

All primary assets (Documents, Rules, Rulesets, Datasets) are versioned and immutable.

Edits create new versions.
Drafts exist only as pre-version mutable workspaces.
Runs and labels reference immutable versions only.

This ensures reproducibility and non-repudiation.

7.2 Runs

A Run represents the application of a single Ruleset version to one or more Documents (or a Dataset).

Runs are immutable once created.
Run state is driven by an associated Operation.
Results and metrics are read-only artifacts.

7.3 Operations

Operations are the only cancellable entities in the system.

All long-running work is represented as an Operation.
Operations have explicit lifecycle states.
Cancellation is best-effort, auditable, and asynchronous.

This prevents implicit background work and "ghost execution."

8. Logging and Audit Posture

8.1 Structured Logging

All services emit structured (JSON) logs with standard fields:

request_id / operation_id
actor identity
resource type and version
outcome and error codes

8.2 Log Classification

Logs are categorized:

Audit Events (security-relevant, long retention)
Operational Telemetry (performance, lifecycle)
Debug Logs (restricted, short retention, disabled by default in prod)

8.3 Log Protection

Logs are transmitted over TLS.
Log storage is encrypted at rest.
Access to audit logs is restricted and monitored.
/operations/{id}/logs exposes filtered, authorized views—not raw log access.

ELK (or equivalent) is treated as a high-value target, not a convenience tool.

8.4 Logging Policy

Logging levels and allowed content:

AUDIT
- What: auth events, access decisions, head pointer changes, operation lifecycle
- Content: IDs, versions, actors, timestamps
- Retention: long
- Access: restricted
INFO
- What: state transitions, successful operations, high-level metrics
- Content: IDs, counts, durations
- Retention: medium
- Access: standard ops
WARN
- What: recoverable anomalies, retries, degraded behavior
- Content: IDs, error codes (no payloads)
- Retention: medium
ERROR
- What: failed operations, unhandled exceptions
- Content: IDs, error summaries (no content)
- Retention: medium-long
DEBUG
- What: developer diagnostics, optional LLM I/O
- Content: may include sensitive data
- Retention: short
- Deployment: disabled by default

Hard rule: Document content and extracted text MUST NOT appear in AUDIT, INFO, WARN, or ERROR logs under any circumstances.

9. Debugging and Maintenance Access

9.1 No Standing Backdoors

There is no always-on "devtools" container in production.

9.2 Controlled Debug Access

Debugging is performed via:

Ephemeral debug pods or containers
Time-limited access
Explicit approval and audit logging
No default access to databases or secrets
Enabling DEBUG logging is treated as a maintenance action and follows the same approval and audit requirements as ephemeral debug access.

This supports operational needs without introducing permanent attack surfaces.

10. Resilience and Failure Modes

All critical state is persisted durably.
Workers can crash or restart without losing work.
Operations can be retried or canceled deterministically.
Partial failures do not result in silent corruption.

Temporal provides:

Durable execution state
Retry and timeout semantics
Cancellation and heartbeat tracking

11. Security Architecture Summary

Our architecture supports your compliance and regulatory requirements by:

Enforcing least privilege at API and worker layers
Using immutable versioned artifacts for traceability
Explicitly modeling long-running work
Encrypting data in transit and at rest
Minimizing data exposure in logs
Providing durable, queryable audit records
Ensuring high availability and resilience for critical insurance operations

The system is designed so that security posture is a consequence of the architecture, not a bolt-on feature.

12. Deployment and Operational Model

Jaxon provides on-premise, self-hosted software. We do not host, store, or process your data. All Jaxon components run within your designated secure infrastructure (on-prem or private cloud).

12.1 Operational Responsibilities

Because our software runs in your environment, our operational responsibilities differ from a standard SaaS provider:

Data Sovereignty: Your data never leaves your environment. Jaxon has no access to your inputs, outputs, or processed documents.
Infrastructure Control: You are responsible for the management, patching, and monitoring of the host infrastructure.
System Assurance: You are responsible for the security posture of the operating environment, including penetration testing, vulnerability management, and uptime SLAs.

12.2 How We Support Your Compliance

While you operate the environment, Jaxon provides the security-hardened architectural foundation required to meet rigorous compliance standards:

Auditability: We provide comprehensive, structured audit logs that can be ingested into your security monitoring (SIEM) systems to fulfill your internal and regulatory logging requirements.
Security by Design: Our software is built with Zero-Trust principles (mTLS, Vault-managed encryption, least-privilege RBAC), which simplifies your efforts to achieve SOC 2 or ISO 27001 compliance for your internal deployments.
Data Training Restrictions: Our software contains explicit architectural constraints that prevent data usage for external model training.
HIPAA/Data Governance: Because we do not house your data, we simplify your Business Associate Agreement (BAA) and data-retention requirements—you define the retention policies within your own infrastructure.

12.3 HITRUST Alignment

Jaxon is not HITRUST-certified, as we are a software vendor and not a cloud hosting provider. However, our software architecture incorporates the core security principles required by the HITRUST Common Security Framework (CSF), including granular access controls, immutable audit trails, and comprehensive application-level encryption. We provide full architectural transparency to assist your team in mapping our controls to your internal HITRUST compliance roadmap.

13. Our Commitment to Your Security

At Jaxon, we view your security as our Shared Fate. We are committed to being active partners from day one, ensuring our world-class security technologies are engineered directly into the platforms you use. We provide full transparency into our controls and align our posture with the rigorous demands of the insurance industry, ensuring your business is protected, detectable, and recoverable against any threat.