Concrete measures. Not promises.
Here is exactly how Caelis isolates your data, who can see what, and what happens before anything is published. Not marketing language about security — the actual mechanisms.
- Data sharing between customers
No query can read another customer's data.
Isolation is enforced in the database itself, not just in application code. Even if somewhere in Caelis' own code forgot to filter by customer, the database's own access rules stop the query from returning anything at all from other customers.
Customer A queries
Own data
Database access rule
Enforced per query
Customer A's rows
Customer A queries
For Customer B's data
Database access rule
Enforced per query
No rows
- Access keys and credentials
Third-party access keys are stored encrypted, separately.
When Caelis connects to WordPress, Shopify or other systems, the access key is stored encrypted with its own key management — never in plain text, never in a shared config file. Every connection gets its own, minimally scoped key: if one integration were compromised, it grants access to nothing else.
- What gets published
Nothing publishes without your approval.
A new capability Caelis adopts is always off by default, and requires approval before it can run at all. You decide when, or whether, Caelis can publish without asking first — it never happens automatically from day one.
- Caelis' own access to your account
When Caelis' own team looks at something in your account, it's read-only and logged.
The Caelis team's cross-customer access is used for support and operations, requires two-factor authentication, and the cross-customer connection itself is read-only — it cannot write to any account. Changes the team makes on your behalf, such as setup during an onboarding you asked for, never happen across accounts: they run against one named account through the ordinary action engine, and are recorded in the immutable action log. The team never approves content on your behalf — publishing is always your own decision.
- Monitoring and recovery
Failures are detected, and data can be recovered from a daily backup.
The database is backed up daily, with eight days of history. The recovery point is therefore the last 24 hours, not the second before a fault. The mechanism has been tested in our development environment; point-in-time recovery (PITR) is not enabled.
No certifications Caelis doesn't actually have.
Caelis is not SOC 2 or ISO 27001 certified today. The measures above are real and in production, but that is a different claim from a formal certification — and we say so plainly instead of implying something we can't document.
Common questions about security
Only for support and operations, and only with two-factor authentication enabled. The connection the team uses across customers is read-only. Setup changes you asked for run against one named account and are recorded in the action log. The team never approves content on your behalf.
No. Isolation is enforced in the database, not just in application code — a query cannot return data from another customer even if something in the code were to fail.
Encrypted, with its own key management, never in plain text. Every integration gets its own, minimally scoped key.
Not today. The measures on this page are real and in production, but that is a different claim from a formal certification, and we say so plainly.