Data handling
Encryption at rest, data residency, retention, and sub-processor details.
Encryption at rest
Oxagen encrypts every store at rest:
| Store | Encryption | Key management |
|---|---|---|
| Postgres (Aurora PostgreSQL) | Aurora storage encryption | AWS KMS |
| Neo4j and ClickHouse | Encrypted EBS volumes on the application host | AWS KMS |
| Blob storage (binary assets) | Server-side encryption | Provider-managed |
Oxagen also encrypts plugin OAuth tokens and API key secrets at the application layer with AES-256-GCM before writing them to Postgres. The encryption key lives in AWS (KMS and Parameter Store), not in the database or in code.
Encryption in transit
Client connections to Oxagen services use TLS 1.2 or higher, terminated by Caddy on the application host. Neo4j and ClickHouse listen on the host's loopback interface only, and the security group opens nothing to them. Postgres runs on a separate Aurora cluster that admits connections from the application host only.
Data residency
The repository's AWS deployment targets us-east-1. That location alone does not establish residency for every processor. Model providers, Blob storage, and external connections have their own processing locations and terms. Review the configured providers for your deployment.
Data classification
- Identity: profiles and authentication records in Postgres. Telemetry can also carry identifiers and attribution.
- Operational records: conversations, agent runs, tool calls, memories, and uploads across the four stores.
- Telemetry: usage, timing, audit decisions, and recorded run events. Recorded content depends on the event and capture configuration.
- Billing: credit and subscription records. Stripe handles card details, while Oxagen stores its identifiers.
Avoid placing secrets in prompts or tool payloads. Credential custody for mediated connections does not prevent a person or external tool from supplying a secret as content.
Retention and privacy requests
Security audit records use the retention policies documented in Audit logging. Other stores and record types have their own deletion paths. Do not infer a common recovery window from a soft-delete field.
Privacy requests describes asynchronous exports, authenticated downloads, and the incomplete erasure cascade. An export retries when an artifact read fails. If retries fail, the request is marked failed without publishing an incomplete archive. An erasure request does not currently remove all personal data across the stores.
Sub-processors
Oxagen uses these sub-processors:
| Sub-processor | Purpose | Data categories |
|---|---|---|
| Amazon Web Services | Compute, Postgres (Aurora), the host that runs Neo4j and ClickHouse, and secrets (Parameter Store and KMS) | All categories (primary infrastructure) |
| Model gateway (OpenRouter or Vercel AI Gateway) | Model inference | Messages and system prompts sent to a model |
| Stripe | Payment processing and subscription management | Billing |
| Inngest | Background job orchestration | Job payloads (org and workspace IDs, capability names) |
DPAs are available on request for all primary sub-processors. Contact privacy@oxagen.sh.
Model providers and AI inference
Oxagen can fund inference through its model gateway or an organization-provided credential. Supported funding sources include OpenRouter, Vercel AI Gateway, OpenAI, Anthropic, and configured OpenAI-compatible endpoints. See Model funding.
Requests can contain prompts, messages, recalled context, and tool results. The configured model provider's terms govern that content. Do not treat an application preference as proof of the provider's training or retention policy.
Data processing agreements
Contact privacy@oxagen.sh for the current processing terms and available agreement. Confirm the scope against your deployment and its connected providers.