Security at OriginChain.
OriginChain is a managed AI-native database with single-tenant compute and storage, region-isolated by default, encrypted in transit and at rest, with every privileged action audit-logged. Trading positions, patient vitals, and inventory ledgers run on it today.
Single-tenant by construction.
One customer per virtual machine. One block volume. One bearer token. One DNS record. Cross-tenant reads are not blocked by a permission check - there is no shared compute or storage to read across in the first place.
Dedicated compute
Every customer instance runs on its own dedicated virtual machine. No shared process, no shared memory, no shared kernel. Cross-tenant reads are not a permission check - they are physically impossible.
Dedicated storage
Each instance gets its own block volume. No shared block device, no shared file system, no shared cache. Customer data and customer transaction logs never touch another tenant's bytes.
Dedicated bearer + DNS
One bearer token, one TenantId, one DNS record per instance. Tokens are bound to a single tenant at issue time. A slug or route mismatch returns 403 - it never returns a row.
Tenant-scoped at the storage layer
Every storage key is scoped to a single TenantId. Even inside the engine's own internal indices, lookups outside a tenant's scope are unreachable by construction. Defense in depth, behind the physical boundary.
Encrypted, end to end.
TLS on every wire. AES-256 on every disk. Customer-managed keys available on Enterprise.
TLS 1.2 minimum, TLS 1.3 preferred, on every external endpoint and every replication hop. Per-region auto-renewing wildcard certificates. New certs are picked up without restart.
All block volumes encrypted with AES-256 by the managed-disk service. Keys rotated automatically by the managed key service on managed configurations.
Bring your own KMS key. Customer-managed keys wrap the data key; revocation severs decrypt instantly. Available on Enterprise.
Continuous backups, replica streams, and OTLP exports all flow over TLS to encrypted storage. The backup channel never leaves your region.
One bearer, one tenant, constant-time check.
Tokens are scoped to a single tenant at issue time. Comparison is constant-time. Rate limits are per-key, fairness is enforced inside the commit window, and every write supports idempotency.
Long-lived API keys (oc_live_sk_…) and short-lived JWTs both resolve to the same (TenantId, roles) tuple at the ingress. Token comparison is constant-time. Mismatch returns 403, never a row from the wrong table.
A four-dimension token bucket per API key - bytes/s, ops/s, ask/s, concurrent_queries - with per-key configurability. Fairness scheduling at the write path ensures a loud key cannot starve quiet ones inside the same tenant.
Every mutating request accepts an Idempotency-Key header. Replays return the original response, so retries are safe across timeouts, network blips, and proxy hiccups.
Mint, list, and revoke bearer tokens directly from the console. Rotation honors the previous key for 60 seconds - long enough for a rolling deploy, short enough to close a leaked token fast.
Every privileged action, append-only.
Console actions and administrative API calls - bearer mint, rotate, revoke, schema register, schema edit, PITR run, failover - land in an append-only events table. Retention follows your configuration; export to your SIEM at any time.
Recorded fields
RFC 3339, microsecond precision, UTC.
Bearer token id, console user id, or system principal.
Resource path: tenant, schema, key, or job id.
Mint, rotate, revoke, register, edit, restore, failover, export.
Source IP of the API or console request, captured at the ingress.
200 / 403 / 409 / 500 with the engine error code, when applicable.
Retention by configuration
90 days
365 days
Custom - contractual
See /pricing for the full pricing breakdown.
Durable on commit. Automatic failover. Snapshot and restore.
A write is acknowledged only after it is flushed to durable storage, so an acked write is on disk before you get the response. On high-availability configurations a standby is promoted automatically in about a minute. Storage is snapshotted daily to an encrypted vault, and off-box archiving with restore-to-timestamp is available in preview. Standby replication is asynchronous, so plan for the most recent writes to be at risk in an abrupt primary loss, and read the recovery caveats in ops → write durability.
A write is acknowledged only after it is flushed to durable storage on the instance. A 2xx means it has left the buffer and is on disk, so it survives the database process being killed. Recovery after an abrupt power loss or a full storage volume carries caveats - see /docs/ops#durability.
Replication does not block the primary's acknowledgement, so an abrupt loss of the primary can cost the most recent writes. The recovery point is seconds, not zero - make your writes idempotent and retry on failover.
The old primary's claim has to expire and a grace window pass, which promotes the standby in about a minute; an operator-triggered promotion is closer to 25 seconds. A single-primary claim fences the old primary, so promotion is atomic and split-brain cannot happen.
Every instance's storage is snapshotted daily to an encrypted vault, independent of anything running inside the database. This is the floor: on total instance loss, worst-case exposure is the time since the last snapshot.
With off-box archiving enabled, recent changes ship to encrypted object storage and you can restore to a chosen timestamp. Granularity tracks the archive cadence - seconds on a busy instance, up to tens of minutes on a quiet one. It is opt-in and still in preview; ask us before you depend on it.
A scheduled drill re-attaches a recent snapshot on a throwaway host and runs the engine's integrity check end-to-end. It covers the volume-snapshot path; the off-box archive path is drilled by hand, not on a schedule.
Backup retention
Retention is what we hold, and it is also what we delete. The automated snapshot vault expires on a 30-day schedule. Anything longer - and any deletion deadline you need us to meet - is agreed per deployment rather than selected from a menu, so ask us before you rely on a specific window for a compliance obligation. On a deployment spread across more than one node, snapshots are taken per node: a restore is per-node consistent, not coordinated across the whole group, so treat multi-node recovery as an operator-run procedure we scope with you.
Compliance posture.
Certifications live and underway, plus the contractual instruments customers ask for first. Need an audit timeline, a letter of intent, or a security questionnaire? Talk to us.
Optimistic CAS - predictable, never silent.
Concurrent edits to the same row are protected by single-row
compare-and-set on a server-managed
_oc_row_version
column. A stale write fails fast with a version mismatch instead of
silently overwriting the other client's edit. Last-writer-wins is
explicit and predictable: the winner is the one who read the latest
version.
Single-row CAS
put_row_cas,
get_row_versioned,
delete_row_cas.
Every row carries a server-managed
_oc_row_version;
stale writes return a version mismatch, never a silent overwrite.
Always-on, minimal overhead, every API surface.
Email security@originchain.ai.
Send a minimal reproduction, the affected version, and your assessment of severity. For an encrypted channel, request our PGP key and we'll respond signed.
Reporters are credited by name in release notes unless they prefer to remain anonymous.
Scope is the OriginChain managed cloud, the engine binary, and the customer-facing console. The static marketing site is out of scope.
- 24 hours First human response acknowledging your report.
- 7 days Triage: severity, reproducibility, and a fix plan.
- 30 days Patch released or a public advisory, whichever comes first.
- + Remote code execution in any ingress path (HTTPS, SSE, the bearer-auth layer)
- + Auth or access-control bypass in the engine or the managed platform
- + Tenant-to-tenant crossover on the managed cloud (network, identity, or process boundary)
- + Data exfiltration or corruption via a crafted query or row write
- + LLM prompt-injection that escapes the plan compiler and reaches storage
- + Cryptographic or integrity flaws in the durability, recovery, full-text, vector, or backup subsystems
- + Bypass of per-tenant rate-limit / quota or per-API-key bucket accounting
- + Concurrency hazards that violate single-row CAS or schema-cutover atomicity
- − Denial-of-service from obviously abusive query volume within your configuration's quota
- − Issues requiring a compromised host or physical access to disk
- − Vulnerabilities in third-party dependencies already tracked by their maintainers
- − Social engineering of OriginChain staff or support
- − The marketing site (originchain.ai) - it is a static deployment
Want the technical depth?
The architecture page covers the substrate, key shapes, replication topology, and recovery in detail. For audit timelines, BAA / DPA questions, or a security questionnaire, write security directly.