ONE TENANT CAN NEVER SEE ANOTHER'S DATA.
Isolation is enforced four independent ways inside the database itself, and a cross-tenant attack suite replays every route as the wrong tenant before any change ships.
Everything on this page is true today, not planned. Ask us anything we have not covered and you will get a straight answer in writing.
Isolation is not a setting. It is four constraints.
Multi-tenant products usually rely on every query remembering to filter by customer. We assume that will eventually be forgotten, and we make the database refuse anyway. Any one of these four failing is caught by the other three.
Default-deny at the database
Row-level security is enabled on every tenant table with a default-deny policy. The application connects as a non-superuser role that cannot bypass it, so a query that has not pinned a workspace returns nothing at all.
Composite keys, so a leak is a constraint violation
Every record is keyed by (workspace, id), and every foreign key carries the workspace with it. A row in one workspace referencing a row in another is not merely a bad query — the database refuses to store it.
No way to route around the wrapper
A lint rule bans importing the database driver anywhere in application code. Every query in the product is forced through one wrapper that opens a transaction and sets the workspace for that transaction. There is no second path to the data.
A schema linter that fails the build
A test inspects the live database and fails the build if any table lacks a workspace column, a composite primary key, or an isolation policy. A developer cannot add a leaky table by accident, or under deadline.
Checkable, not decorative.
We attack our own isolation, on every commit
- 18 probe suites replay every ID-addressed route as the wrong tenant and scan the responses for canary values
- Dedicated probes for prospect access: cross-tenant, cross-POC, credential leakage, slug guessing, file access, passkeys
- Every API route must ship both a happy-path test and a cross-tenant denial test, or the build fails
- Over 4,500 automated tests across 370+ files; the test catalog is generated from the test runner, so it cannot drift from reality
Credentials and secrets
- Passwords are hashed with Argon2id — never encrypted, never recoverable, not even by us
- Connector tokens, webhook signing secrets and your OIDC client secret are sealed with AES-256-GCM, with your workspace ID bound in as additional authenticated data — a ciphertext copied into another workspace cannot be opened
- Without the encryption key the API answers 503 on secret writes rather than storing plaintext, and a webhook whose secret cannot be decrypted is marked dead rather than delivered unsigned
- API keys are HMAC-with-pepper, compared in constant time and rate-limited
- A rotation command re-seals every stored secret under a new key with no downtime
Access control that is capability-based
- Every gated action maps to a named permission; roles (SE, manager, AE, PM, admin, viewer) are presets over those permissions
- Each permission is documented against the exact routes it gates, and a parity test fails the build if a route guard and the published matrix disagree
- Sensitive surfaces — SSO configuration, connector credentials, billing, branding — default to workspace admins only
- Resource scoping rides alongside the matrix: owner checks, and a per-role, per-status matrix of which fields can be edited when
Sign-in
- Single sign-on via OIDC on Enterprise — Okta, Entra ID, Google Workspace, Keycloak or any OIDC provider. Authorization-code flow with PKCE, state and nonce, ID-token signatures verified against your provider JWKS using asymmetric algorithms only, and a verified email address required
- Shamir k-of-n break-glass recovery, so enforcing SSO can never lock your admins out: only a hash is stored server-side, shares are shown once, and a share set can be redeemed exactly once
- Login is throttled per source IP and per account before any password is verified; signup and prospect one-time codes are throttled too
- Session cookies are host-locked __Host- cookies in production, and the environment check fails closed — anything that is not development or test is treated as production
- Prospects can sign in with WebAuthn passkeys, bound to their own POC subdomain and provably useless in any other workspace
Data in transit and at rest
- TLS 1.2 or better on every connection, with TLS 1.3 negotiated by default on modern clients
- HSTS for one year with includeSubDomains on every response, so browsers refuse plaintext for the whole domain after first contact
- X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin and X-Frame-Options DENY, set at the edge
- Secrets you entrust to us are encrypted at rest as described above; other application data is stored unencrypted in Postgres on an access-controlled host
Every change is gated before it can ship
- Static analysis on every push and every pull request — semgrep with the OWASP Top Ten, JavaScript, TypeScript, Node and secret-detection rulesets — failing the build on any finding
- A dependency audit that fails the build on any high or critical advisory
- Both scans re-run nightly, because new advisories appear without a code change, and Dependabot opens weekly upgrade pull requests for packages, CI actions and container base images
- A real-browser end-to-end suite runs on every push with an error guard that fails on any undeclared 4xx, 5xx or console error — so a feature that renders correctly while silently failing permission checks cannot reach production
Outbound requests, integrations and environments
- Every outbound call the platform makes on your behalf — OIDC discovery and token exchange, webhook delivery, notification channels, connector and tracker calls — passes through a server-side request forgery guard
- Connector OAuth callbacks derive the workspace from an HMAC-signed state, never from the host, a query parameter or a session; the request’s own resolved workspace must match it, the state is single-use, and both the signature and the record expire in ten minutes
- Evaluation environments run an agent inside your own cloud account making outbound-only calls: we never hold your cloud credentials and never have inbound access to your infrastructure, and enrollment tokens are per-workspace and revocable
- Uploaded file keys are always derived server-side from a workspace-scoped database row, never supplied by the caller, with a path-traversal guard and dedicated leak probes
What is recorded, and where it runs
- Every POC carries a complete, append-only activity timeline — who did what and when, across planning, sign-offs, kickoff, prospect activity, status changes and integration syncs — visible to your team in the product
- seRevel runs on a dedicated server rented from a German hosting provider, with Cloudflare in front of the public surface
- A public status page at status.serevel.ai is backed by real uptime monitoring and is deliberately reachable on a path that does not depend on Cloudflare, so it still works during the outages it exists to report
- AI-assisted features are optional and can be switched off for your workspace entirely
The services that can touch your data.
This is the current list. Ask us and we will confirm it in writing, including what each one receives.
- HostingA German hosting provider — the application, the database and uploaded files
- CloudflareDNS, TLS termination and WAF for the public surface
- StripeSubscription billing; card data never reaches our servers
- PostHog (United States)Product analytics for the application
- Transactional emailSign-in links, invitations and notification email
- AI providerOnly for the optional AI-assisted features, and only when they are enabled for your workspace
Send us the questionnaire.
We answer security questionnaires directly, including the questions where the answer is no. If you need a Data Processing Agreement, an architecture and control summary, or a deletion request carried out, write to us and you will get a dated, written answer.
security@serevel.aiseRevel, Inc. · 131 Continental Dr, Suite 305 · Newark, Delaware 19713 · USA
Found something on this page you believe is wrong, or a vulnerability in the product? Report it to security@serevel.ai. We will acknowledge within two business days, and we will not threaten you for telling us.