Security at Oneop, control by control
This page is a list of the specific controls that exist in the code — how tenants are separated, how sessions are kept apart, how credentials are stored, and what happens when a webhook signature does not verify. Every one of them is a mechanism you can ask about by name.
Last updated August 8, 2026
Where does Oneop run, and who hosts it?
The application and its PostgreSQL database run on a single dedicated server atHetzner Online GmbH, in Germany. There is no separate database vendor — Postgres runs on the same machine, on a private Docker network, and is not reachable from the internet at all.
- No inbound ports are open. Traffic reaches the application through a Cloudflare Tunnel, which dials outward from the server; the host firewall denies all ingress. There is no origin address to find and no port to scan.
- The internal operator console sits behind a second gate — its own tunnel route, fronted by Cloudflare Access, in addition to being a separate application that ships disabled.
- Files and attachments live in Cloudflare R2, in a bucket created in Cloudflare's European Union jurisdiction, so object data stays in the EU.
- Backups run nightly with continuous write-ahead log shipping to that same EU object storage, encrypted with a key held off the server.
The same two facts — Hetzner, and Germany — are stated on theprivacy policy, thedata processing agreement and thesubprocessor register. They are meant to be identical in all four places, and a build check asserts that they are.
How does Oneop keep one customer's data out of another customer's account?
Isolation is a property of the schema, not a filter that a developer has to remember. The database carries 329 tables; 275 of them have a tenant_id column, and every query against them is scoped to the tenant on the session.
The other 54 are worth accounting for individually rather than waving at, because "the rest are platform tables" is the kind of sentence that hides things. 28 belong to the operator console, which is a separate application that ships disabled. 18 are child records that inherit the boundary through a foreign key to a tenant-scoped parent — a WooCommerce order row reaches its tenant through the integration that pulled it. 4 hold global reference data: tax jurisdictions, EU VAT rates, provincial tax authorities, languages. 3 are the shared directory of publicly published company information used for prospecting, which holds no customer business data by design. The last one is the tenant registry itself.
- Every tenant-scoped table carries
tenant_id. Scoping happens at the data layer, on every read and every write. - No endpoint reads or writes across a tenant boundary. The one place that spans tenants is the internal operator console, which is a separate application that ships disabled (see Identity).
- Public registration always provisions a new tenant. A caller-supplied
tenantIdis rejected outright, and the new user's role is hardcoded rather than read from the request body. - CRM
PATCHendpoints run a mass-assignment guard, so a field that is not on the allowlist cannot be written by adding it to a request.
Are the customer app, the support console and the client portal the same login?
No. They are three separate session principals, with three different cookie names and three different signing secrets. In production the server refuses to boot if the secrets are not all distinct — this is a startup assertion, not a deployment convention.
- Three principals: the tenant app, the internal operator console, and the project client portal — each with its own cookie and its own signing secret.
- Boot-time enforcement: production start throws unless all three session signing secrets are distinct values. A client-portal session cannot reach the staff app, and a staff session cannot reach the portal.
- Passwords are hashed with scrypt: 64-byte derived key, 16-byte per-user random salt, constant-time comparison on verify. No password is ever stored or logged in plaintext.
- Google and Microsoft OAuth sign-in for tenant users.
- SAML 2.0 single sign-on against your own identity provider — SP-initiated AuthnRequest, an assertion consumer endpoint, downloadable SP metadata, configurable attribute mapping, and real signature, issuer and expiry validation.
- SCIM 2.0 user provisioning — users are created, updated and de-provisioned automatically from your IdP.
- TOTP two-factor for tenant users, enabled for your workspace on request. Two-factor is mandatory, on every route, for internal Oneop operators.
- Login, invite acceptance and password reset are each rate-limited independently.
How are the credentials I give Oneop stored?
Third-party credentials — mailbox passwords, integration keys, DKIM private keys — are encrypted with AES-256-GCM before they are written, and no API route returns a private key back to a caller. Mailbox and integration credentials live per tenant in the integrationstable, never in shared server-wide configuration.
What stops a webhook URL from being pointed at your internal network?
Every surface where a customer can supply a URL — webhook blocks, API-call blocks in the chatbot, the crawler, the SIEM audit stream, IMAP connection setup — goes through an SSRF guard that resolves the hostname and rejects private, loopback and link-local addresses. The guard runs again on every redirect hop, not once at configuration time, which is what closes the DNS-rebinding window.
Redirects are followed manually with a hop ceiling, and every request carries a timeout.
What happens if a webhook signature does not verify?
The request is rejected. Every inbound webhook fails closed:
Signature comparisons use constant-time equality.
| Source | Verification | On missing or invalid key |
|---|---|---|
| Postmark (inbound email) | Bearer token against a configured shared secret | 503 — rejected, not trusted |
| SendGrid Inbound Parse | Shared secret | 503 — rejected |
| DocuSign | HMAC-SHA256 against a configured signing key | 401 |
| HelloSign / Dropbox Sign | HMAC-SHA256 against a configured signing key | 401 |
| Stripe | Signature verification | Rejected |
| Zoom | HMAC against a configured secret token | Rejected |
Can the AI guardrails be turned off?
Two of them cannot. Prompt-injection detection and PII redaction run on every AI call, on every plan, with no toggle — they execute before any per-workspace setting is even read. A detected injection pattern blocks the call outright rather than degrading it.
Every AI call also passes through a single metered choke point that reserves credits against the tenant's balance before the model is called, so AI spend is attributable per tenant rather than pooled. A build-breaking test fails CI if any AI Workforce file bypasses the router or omits the tenant ID.
Tool allowlisting, action-value ceilings and confidence thresholds are an additional layer on top, available on Pro and above and switched on for your workspace when you want them.
Configurable · Pro and above · shown off, its default
No plan, workspace or setting reaches this layer.
What can Oneop staff see, and is it recorded?
The internal operator console is a separate application, disabled unless explicitly enabled, with its own login, its own cookie and mandatory two-factor on every route. When an operator needs to see a customer account to answer a support request, the session is boxed:
- Time-boxed to 30 minutes by default, hard ceiling of two hours, dead after 15 minutes idle.
- Revocable mid-session by another operator, and re-checked on every request rather than only at the start.
- Hard-blocked from changing a plan or payment method, changing a password, touching MFA, adding or removing team members, creating or deleting integration credentials, bulk-deleting contacts, or running a data erasure.
- Bulk exports require the operator to record a written reason under their own name first.
The operator audit log is append-only — there is no update route and no delete route — is scrubbed of credential material on the way in, exports to CSV, and can be streamed to your own SIEM over HTTPS with an HMAC-SHA256 signature, at-least-once delivery, and a retention floor of one year.
Inside the tenant app there is a security-event log covering logins, MFA changes, data exports and erasures. It has no delete route.
Schema changes ship as 225 hand-written, idempotent SQL migrations, so re-applying one is a no-op.
Can I get my data out, and can I erase a person?
Both, from inside the app. Export covers contacts, conversations, tickets and deals. Erasure anonymises the contact and user records for a named individual, and the request itself is written to the security-event log.
The data processing agreement and the dated subprocessor list are linked below, and both are public documents you can read before you sign anything.
Reporting a vulnerability
Email security@oneop.io with the affected URL or endpoint, the steps to reproduce, and the impact you believe it has. You will get a human acknowledgement. Please do not run automated scanning against production or access data that is not yours.
Documents
- Data processing agreement — the terms under which Oneop processes personal data on your behalf.
- Subprocessors — every third party that touches customer data, dated.
- Privacy policy
- Terms of service
- Changelog — what shipped, when.
- Roadmap — what has shipped, what is opt-in, and what is next.
Security questions
Where is my data hosted?
The application and its PostgreSQL database run on one server at Hetzner Online GmbH in Germany; there is no separate database vendor. Files and attachments are held in Cloudflare R2, in a bucket created in Cloudflare’s European Union jurisdiction. The server has no open inbound ports — traffic arrives through a Cloudflare Tunnel that dials outward, and the host firewall denies all ingress.
Is my data separated from other customers' data?
Yes. 275 of the 329 database tables carry a tenant_id column and every query against them is scoped to the tenant on the session, so isolation is enforced at the data layer rather than by application convention. No API route reads or writes across a tenant boundary.
Can Oneop staff log into my account?
Only through a time-boxed, logged impersonation session in the internal operator console, which stays disabled unless it is explicitly enabled. That session expires in 30 minutes by default, dies after 15 minutes idle, can be revoked mid-session, is re-checked on every request, and is blocked from billing, password, MFA, team-membership and destructive actions.
Does Oneop support SAML SSO and SCIM?
Yes. SAML 2.0 SP-initiated SSO with real signature, issuer and expiry validation, plus SCIM 2.0 user provisioning and de-provisioning.
How are the credentials I give Oneop stored?
Third-party credentials — mailbox passwords, integration keys, DKIM private keys — are encrypted with AES-256-GCM before they are written, and no API route returns a private key back to a caller. They live per tenant in the integrations table, never in shared server-wide configuration.
How do I report a security issue?
Email security@oneop.io with the affected URL or endpoint, the steps to reproduce, and the impact you believe it has. You will get a human acknowledgement.
Start on the free plan and see the real thing
No credit card, no trial countdown — just the product with its plan limits.
Sign-up opens when the app launches. We will email you once — no marketing list.