Skip to main content

Alexandria EE — Compliance Posture

This document describes the compliance-relevant controls in Alexandria EE, aimed at customers preparing for SOC 2 Type II or ISO 27001 audits.

Audit Log​

Retention and Export​

All API actions are written to an append-only audit log stored in Postgres. Each row is cryptographically chained via HMAC (SHA-256) so tampering is detectable.

  • Schema: audit_log table — columns: id, principal, action, agent, session, metadata, hmac, prev_hmac, created_at.
  • Default retention: indefinite (no TTL). Implement retention via Postgres table partitioning or a scheduled DELETE WHERE created_at < NOW() - INTERVAL '1 year' job.
  • Export: GET /admin/audit/export (requires audit_export entitlement) returns NDJSON for ingestion into SIEM / log aggregation.
# Export all audit events as NDJSON
curl -s -X GET 'https://alexandria.example.com/admin/audit/export' \
  -H "Authorization: Bearer <admin-token>" > audit-$(date +%Y-%m-%d).ndjson

Chain Verification​

The HMAC chain can be verified at any time:

curl -s -X POST https://alexandria.example.com/admin/audit/verify \
  -H "Authorization: Bearer <admin-token>" | jq .

A verified: true response confirms no rows have been modified or deleted since the chain was written.

SOC 2 / ISO 27001 Controls Mapping​

Control DomainAlexandria EE ControlNotes
CC6.1 — Logical access controlsJWT-based auth; RBAC with roles (admin, user, agent, super_admin); per-user and per-agent tool intersectionAll access requires a valid JWT; tokens expire per jwt_ttl config
CC6.2 — AuthenticationPassword hashing (bcrypt); optional WebAuthn/FIDO2 passkeys; OIDC/SAML SSO (EE)Brute-force lockout configurable in auth.lockout
CC6.3 — AuthorisationPermission intersection: agent_allowed ∩ user_allowed ∩ server_ceiling; super_admin bypass is loggedTenant ceiling provides additional isolation in multi-tenant mode
CC7.2 — System monitoringPrometheus metrics (/metrics); OTLP traces and logs via otel-collector; ServiceMonitor for Prometheus OperatorAll auth failures logged at WARN level with caller identity and peer IP
CC9.2 — Incident responseAudit log HMAC chain detects tampering; /admin/audit/verify endpoint for on-demand integrity checkExport audit log to SIEM for alerting
A.12.3 (ISO) — BackupPostgres logical dump (see runbook); no stateful data in podsPVC is ephemeral in prod; all persistent state is in Postgres
A.14.2 (ISO) — Secure developmentBSL 1.1 license; all changes via tagged releases; Helm chart schema validationSchema values.schema.json enforces required fields; helm lint in CI
A.18.1 (ISO) — Regulatory complianceAudit log export for regulatory review; configurable retentionCustomer owns the Postgres instance and controls data residency

Encryption at Rest​

Postgres (application data)​

Alexandria EE stores all persistent data in a customer-managed Postgres instance. Encryption at rest is the responsibility of the Postgres operator:

  • GCP: Cloud SQL with diskEncryption: CMEK or Google-managed encryption (default on).
  • AWS: RDS with EBS encryption enabled (default on for new instances).
  • On-prem: Postgres with OS-level LUKS or ZFS encryption.

Alexandria does not store raw passwords in Postgres. Passwords are bcrypt-hashed before insert.

Kubernetes Secrets​

Sensitive values (JWT secret, admin password, database DSN, SCIM token, OIDC client secrets) are stored in Kubernetes Secrets:

  • At rest: encrypt Secrets with a KMS provider (GCP KMS, AWS KMS, Vault) via the Kubernetes EncryptionConfiguration API.
  • In transit: all Secret access goes over the Kubernetes API server with TLS.

For GitOps workflows, use External Secrets Operator (externalSecrets.enabled=true in values) to sync from Vault, AWS Secrets Manager, or GCP Secret Manager — never commit plaintext Secrets to version control.

TLS in Transit​

  • All external traffic to the API is TLS-terminated at the ingress (nginx, GCE LB, ALB, Istio gateway). The chart does not terminate TLS at the pod.
  • Internal pod-to-pod traffic within the cluster travels over the cluster network. Enable Istio mTLS or Cilium encryption for wire encryption between pods if required.

Model Weights (HF pull)​

When using HF model pre-pull (source_type: hf), Alexandria now verifies the commit SHA of the downloaded model against a pinned value (hf_pinned_commit field). This prevents supply-chain substitution from Hugging Face Hub.

Network Isolation​

The Helm chart ships a Kubernetes NetworkPolicy (networkPolicy.enabled=true by default) that:

  • Restricts ingress to the API pod from the configured ingress controller only.
  • Restricts egress to DNS (53), HTTPS (443), HTTP (80, 8080), Vault (8200, if enabled), and OTLP (4318, if enabled).
  • All other ingress/egress is denied by default.

For stronger isolation, enable Cilium (networkPolicy.cilium.enabled=true) which adds FQDN-scoped egress rules — only whitelisted domain names can receive outbound traffic.

Data Residency​

Alexandria EE has no telemetry callbacks, license verification calls, or data exfiltration channels. All data stays within your cluster/host. License keys are verified locally against the embedded public key — no outbound call is made.

The optional usage telemetry (POST /admin/telemetry/preferences) is opt-in per deployment and, when enabled, sends only anonymous aggregate counters (query count, model kind) — no query content, user data, or file contents.