Trust centre
Security you can inspect, not just trust
How projects are isolated, what is encrypted and with which keys, what we log, and where each claim can be checked.
Security at a glance
The posture in one block. Each line is stated in full below, next to the layer that enforces it.
- In transit
- TLS 1.3
- At rest
- AES-256-GCM, envelope keys
- Tenancy
- Per-project Postgres pools
- Workloads
- SPIFFE SVID mTLS
- Audit
- Hash-chained privileged mutations
- Region
- The region you select
Every section on this page names what enforces the control it describes, because a control that is only a convention is not a control. Where a claim can be checked without asking us, the check is named next to it: the isolation table says where each control is enforced, the supply-chain table says how each one works, and the endpoints section lists what you can fetch, diff and monitor yourself.
Reporting a vulnerability is a page of its own: the disclosure policy states how to report, the acknowledgement and triage times we target, and the safe harbour for good-faith research.
Projects are separated at the data layer, not by convention.
Tenant separation is the property everything else depends on, so it is stated as a table with the layer that enforces each control.
| Layer | Control | Enforced at |
|---|---|---|
| Database | Per-project Postgres pools; a project never shares a pool with another project. | Connection provisioning |
| Access control | RBAC is evaluated at the SDK boundary, so every data path passes the same permission check. | SDK / API boundary |
| Cross-tenant guard | Runtime guard blocks cross-project access; the guard is covered by CI enforcement, not code review alone. | Runtime + CI |
| Credentials | Project credentials are scoped to that project. Other products are wired with the keys those products issue. | Credential issuance |
| Infrastructure detail | Customer contracts stay above the infrastructure: no raw provider, orchestration, namespace, node, volume, queue or scheduler identifiers are exposed. | Contract surface |
| Workload identity | Platform services authenticate to each other with SPIFFE SVID mTLS in the internal trust domain, so a stolen static secret is not a platform-wide key. | Service mesh |
A control only counts if it fails closed. Each row above is checked by automated tests or CI gates in the platform repository; the CI gates are what we rely on, not reviewer memory.
Encrypted in transit, encrypted at rest, keys wrapped per tenant.
| State | What we do |
|---|---|
| In transit | TLS 1.3 for public and internal API traffic. |
| At rest | AES-256-GCM, with envelope encryption: per-tenant data keys wrapped by a master key held in an HSM boundary. |
| Secrets | Customer secrets are write-only through the API and console — reads return metadata, never values. |
| Logs | PII, tokens and passwords are redacted from every log line using a single redaction set, with negative-leak tests in CI. |
| Build outputs | Artifacts and images are addressed by content digest, so what ran is what was built. |
Why envelope encryption
A single platform-wide data key would make one leak catastrophic and key rotation a platform outage. Wrapping per-tenant keys means rotation happens per tenant, and a compromised data key exposes one project rather than every project.
What we do not claim
We do not publish a hardware-security-module vendor, a key-ceremony document, or a third-party cryptographic audit on this page. If your procurement needs those artefacts, ask us and we will tell you exactly which ones exist today and which do not.
Privileged actions leave a tamper-evident record.
Every privileged mutation — issuing a token, deploying, changing a secret, promoting a build to production — is written to a hash-chained audit table. Each entry commits to the previous one, so removing or editing history is detectable rather than merely discouraged.
- What is recorded: actor, project, action, target, timestamp and outcome.
- Why chained: an append-only log with a chain lets a reviewer prove a record was not rewritten after the fact.
- Export: the trail is exportable for compliance review, so you can keep your own copy.
Deployments additionally carry an immutable identity: a deployment is identified by the digest of what was built, so “this is the build that is live” is checkable after the fact instead of inferred from a mutable tag.
Read the release story
If a confirmed incident affects customers, we notify affected customers and regulators where the law or our agreements require it. Service impact is shown on the status page, and we may publish details in the changelog.
Endpoints you can call yourself.
Trust claims are cheap. These are the published surfaces you can fetch, diff and monitor without an account.
| Endpoint | What it proves |
|---|---|
/.well-known/security.txt | The disclosure contact and policy URL are machine-readable, with an expiry date so a stale copy is detectable. |
/.well-known/jwks.json | The public verification keys for platform-issued tokens: anyone can validate a signature against these keys without asking us. |
/.well-known/openid-configuration | The issuer metadata for the same key material, so a client can discover how to verify rather than hardcoding assumptions. |
/api/v1/health/status | Per-service health, overall status and the release identity of the deployment serving it. |
/healthz | A single cheap probe for “is the web application answering”, suitable for your own monitoring. |
How to check a token
- Fetch the key set from
/.well-known/jwks.jsonand cache it. - Select the key by the token’s
kidheader. - Verify the signature, then validate issuer, audience and expiry.
- If verification fails, treat the token as invalid — do not fall back to parsing the payload.
Key rotation is additive: new keys are published before they sign anything, so a client that refreshes the set keeps verifying through a rotation.
Pinned dependencies, digest-pinned images, audited pull requests.
| Control | How it works |
|---|---|
| Dependency pinning | Installable dependencies are locked in a lockfile that is reviewed as part of the change, so a version cannot drift silently. |
| Image identity | Container images are pinned by SHA-256 digest rather than a moving tag. A tag can be repointed; a digest cannot. |
| Pull-request gates | Dependency audit and secret scanning run on every pull request, alongside architecture and boundary checks. |
| Secret hygiene | Secrets, tokens, passwords and kubeconfig material are never committed; a dedicated check block fails the build if they are. |
| Redaction | Log and error paths pass through the shared redaction set with negative-leak tests, so a new log line cannot quietly start leaking a token. |
Supply-chain controls protect customers indirectly, so we keep them boring and mechanical: pin, scan, block, redact — on every change, not on a quarterly review.
Where your data lives, how long we keep copies, how deletion works.
| Topic | Published position |
|---|---|
| Region pinning | Data stays in the region you select. Cross-region replication only happens with explicit opt-in. |
| Backups | Logical backups plus continuous WAL streaming, encrypted at rest and kept for a limited period on a rolling basis. |
| Account deletion | Deleted data is removed from live systems within a reasonable period, and from backups as they expire on their normal rotation. |
| Sub-processors | The current inventory, the data each one can see and its region are published on /legal/sub-processors. Business customers are told of intended changes as the Terms of Service set out. |
| Customer data in marketing | Never. This site publishes no customer names, logos, usage numbers or case studies. |
Backups are not a feature you opt into
Backups run by default because the failure mode of not having them is unrecoverable. They are an operational safeguard for the platform, not a recovery service for your content: keep your own exports of anything you cannot afford to lose.
Deletion is a schedule, not an intention
Deletion has two stages: removal from live systems, then expiry of the rolling backups that still hold a copy. Business customers who need the current periods for a data-retention review can ask for them.
Legal documents — privacy, terms, cookies — describe the same handling in contractual language.
Design intent we can state, attestations we will not fake.
Controls are designed against SOC 2 Type II expectations, and engineering follows industry baselines: OWASP ASVS L2 for application security, CIS Benchmarks for host and runtime hardening, and NIST SP 800-53 Moderate as the control catalogue we map to.
Those are design targets, not a claim of certification. We do not display a SOC 2 badge we have not earned, and we do not sell an ISO certification line on a pricing page.
Formal attestation reports, when they exist for your evaluation, are shared with enterprise customers under NDA. Email security@sylphx.com and ask for the current status of a specific report — you will get a direct answer about what exists today.
| Framework | How we use it |
|---|---|
| SOC 2 Type II | Control design target; attestation status shared on request |
| OWASP ASVS L2 | Application-security review baseline |
| CIS Benchmarks | Host and runtime hardening baseline |
| NIST SP 800-53 Moderate | Control mapping catalogue for enterprise reviews |
| RFC 9116 | Machine-readable disclosure file (security.txt) |
For a security questionnaire or a DPA, email contact@sylphx.com. The facts on this page, the sub-processor inventory and the legal documents are what we answer from, so you can start there and we will fill the gaps.
Records and contacts
How to report a vulnerability, the acknowledgement and triage times we target, and the safe harbour for good-faith research.
The same contact, policy URL and expiry, in the RFC 9116 file a scanner reads.
Every third party that can process customer data, the region it operates in and the contract in place.
Material security-relevant changes are announced here, so a change that is not in it has not been announced.
Live per-service health, the release identity serving it, and the raw endpoints behind the page.