Skip to content
Start free

Security

Clear controls.
Defined responsibilities.

Understand the request path, identity model and deployment controls before putting your application into production.

Read the access reference Report a vulnerability
Public transportHTTPS endpoints
IdentityApplication and database access
IsolationShared or dedicated deployment

Follow the request. Keep the identity clear.

Application authorization and database permissions are separate parts of the design.

Application and database responsibilitiesIllustrative HTTP request path
Your applicationOriginChainDB
01 / User interface

Browser or mobile app

Authenticate your users and send requests to your application server.

User session
02 / Application server

Keep credentials here

Apply application access rules and choose the intended database identity.

Server-side secret storage
03 / Database endpoint

Authenticate the request

The credential determines the database identity and applicable query checks.

Query-specific enforcement
Public requestHTTPS + Authorization: Bearer <token>Credential scope depends on its type and deployment.
Which identity reaches the database?
Administrative bearer
The master bearer acts as a database administrator. It is not a test of a restricted user's permissions.
Database user
Database-user credentials carry that user's roles. Validate the documented enforcement for each query path.
Organization member
Console membership is a separate identity layer; it does not itself grant database-user permissions.
Read the enforcement reference

Example HTTP application pattern. Keep full-access database bearers out of browser and mobile client code.

Deployment isolation

The configuration matters.

Dedicated infrastructure and shared hosting have different isolation and recovery properties.

Free and Starter

Shared infrastructure

These databases run on shared, scale-to-zero infrastructure. Each database has its own hostname and bearer credential.

For Free, public TLS ends at the shared load balancer; traffic then travels over the private network to the database.

Dedicated configurations

Dedicated compute and storage

Virtual machines and database storage serve one customer. An optional standby is a separate deployment choice.

Dedicated configurations: encrypted nightly snapshots, included.

Standby replication is asynchronous. Review the configured backup path and current recovery caveats separately.

Deployment reference Durability and recovery

Access and operational records

Choose the control
for the request.

Use the deployed service's capabilities and the intended database identity when evaluating access.

Credential handling guide

Credential handling

Keep full-access bearers in server-side secret storage. Plan credential replacement across clients, and revoke exposed credentials.

Rotation procedure

Database-user reads

The documented read controls include table grants, row policies and column masking. Test the intended identity and each query path.

Policies and identities

Write restrictions

Write-grant letters alone do not establish a write barrier. Use service-enforced read-only credentials or a separate database where a write boundary is required.

Enforcement scope

Authorization audit

The engine records user, role, grant and policy changes in a hash-linked audit chain. Console preview history is a separate record.

Audit reference

Responsible disclosure

Report a security issue.

Send a minimal reproduction, the affected version, and your assessment of severity.

security@originchain.ai

Encrypted disclosure

For encrypted disclosure, request a PGP key by email before sending sensitive details.

Reporter credit

Reporters are credited by name in release notes unless they prefer to remain anonymous.

Published response targets

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.

Disclosure scope and exclusions

Scope is the OriginChainDB managed cloud, the engine binary, and the customer-facing console. The static marketing site is out of scope.

In scope

  • 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.

Out of scope

  • 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 OriginChainDB staff or support.
  • The marketing site (originchaindb.com) — it is a static deployment.

Review your deployment with us.

For questionnaires, current assessment status or contractual requirements, contact the security team.

Talk to security Trust resources Technical architecture