Security & tenant isolation

This page answers the questions an enterprise security questionnaire asks: where does our data live, how is it kept apart from other customers', what happens when something is deleted or revoked, and how do we know the software running is the software that was reviewed. It is a plain-English summary of controls that exist and run in production today.

Your data is isolated by two independent boundaries

Every organization runs on the shared (pooled) tier today. Yours is a tenant, and tenant isolation does not rest on a single mechanism. A cross-tenant leak would require two independent failures, not one bug:

An always-scoped data layer. Every read and write of tenant-owned data goes through a repository layer that carries your tenant identity by construction — the scoping is applied at one chokepoint, derived from your authenticated session, and a query that would reach across tenants is impossible to express. An automated build check (an AST guard in our CI) fails the build if any code bypasses this layer, and a new data table cannot be added without an explicit isolation decision.
Database row-level security beneath it. PostgreSQL row-level security policies sit under the application, so even a hypothetical bug that evaded the layer above still cannot return another tenant's rows. The policies fail closed: with no tenant context set, they match nothing — no context, no rows.

Both boundaries are generated from one source of truth, so they cannot disagree about where the line is, and both are verified by negative test suites — automated tests that attempt cross-tenant access as an attacker would (direct-ID probes, unscoped queries against a real database) and prove it returns nothing. Isolation is tested the way it would be attacked, not just asserted.

Need stronger separation than shared infrastructure? The dedicated isolation tier gives an organization its own database/instance, and self-host keeps everything inside your own perimeter.

Deletion and revocation take effect immediately

Access removal is instant, not "at next token expiry." Roles and memberships are re-resolved from the database on every request — a token never carries standing permissions — so removing a user's access takes effect on their next call. A single revocation lever (used by "sign out of all devices", enterprise SSO logout, directory-driven SCIM deprovisioning, and — where you have enabled it — autonomous response) invalidates every session for a user across every device at once.
Right-to-erasure is honored as a first-class, audited operation, with guards that fail closed rather than partially delete.
Stolen tokens can be neutralized. Sessions support optional sender-constraining (DPoP), which binds a token to a client key so a copied token is useless without the key — and cannot be downgraded to ordinary bearer use.

Does the platform ever act on our users by itself?

Only if you switch it on, and only within limits you cannot be talked past. Zynth Auth includes an autonomous-response engine that can act on a security signal — today, ending a user's sessions when their refresh token is replayed. Four things a security review should know:

It is off by default and does not turn itself on. Every organization starts at Manual for every class of response, which acts on nothing. On self-hosted installs the capability is additionally dormant at the deployment level.
Unattended action must be earned, not configured. Raising a class above "propose and wait for a human" requires your people to have adjudicated this engine's proposals on your traffic — enough of them, spanning at least a fortnight, with no reversals in the trailing 30 days. The thresholds are floors: they can be raised, never lowered.
The blast radius is bounded before anything happens. Per-class budgets cap both actions per hour and, more importantly, distinct people affected per day; hitting either halts that class and raises a critical alert. The engine can never act on someone who holds its off-switch.
Everything is reversible, recorded, and stoppable. Actions are undoable, every decision (including the ones where it declined to act) is in an inspectable ledger and the audit chain, unattended actions notify, and a one-call emergency stop is always available to your own admins.

This is the human-oversight evidence for EU AI Act Article 14 and ISO/IEC 42001 as well as SOC 2 CC7.3.

Every security-relevant action is recorded in a tamper-evident log

Security-significant events are written to a hash-chained audit log: each entry cryptographically covers the previous one, so any edit, deletion, or reordering breaks the chain and is detectable. The log is append-only and never purged, and its integrity can be verified on demand.

That same log is the source of compliance evidence. Each entry is stamped with the controls it evidences, and readiness/evidence reports are generated from live activity per framework — SOC 2, ISO 27001, GDPR, HIPAA, and the APAC frameworks (Philippines Data Privacy Act, Singapore PDPA), with AI-governance frameworks (EU AI Act, ISO 42001, OWASP for agentic apps) evidenced by the agent-identity layer. Because coverage is enforced by our build (every action must map to a control), the evidence base grows automatically as capabilities ship — it isn't reconstructed at audit time.

On certification, plainly: Zynth Auth holds no third-party attestation or certification today, and does not imply one. Naming a framework above describes the evidence our platform produces for you against that framework's controls — it is not a claim that we are certified against it. Independent assessment is on the roadmap, and this page will say so on the day it exists.

The software that runs is the software that was reviewed

Signed, verified images. Release images are cryptographically signed (cosign/keyless), and the deploy step verifies each signature before running the image, failing closed on any mismatch. Our servers never build images themselves.
Least-privilege by default. Application processes connect to the database with a permission- limited role (they cannot alter schema, drop, or reach another database); containers run non-root with a read-only filesystem and all Linux capabilities dropped.
Default-deny networking. Application containers have no direct internet access — all outbound traffic passes through an allowlist proxy that denies and logs anything not explicitly approved. (This also makes air-gapped self-host a natural fit.)
Opt-in surface. Enterprise federation (SSO/SCIM) and other advanced surfaces ship disabled by default and return a plain 404 until an administrator turns them on — attack surface is opt-in.

Where your data can live (residency)

Managed SaaS runs in APAC (Singapore) with a portable, region-agnostic design; self-host lets you keep data and control entirely inside your own region and network — the signed release channel, verifiable offline bundle and licence gating are built and in use, with commercial general availability sequenced separately (see Deployment models) — the sovereignty option for regulated buyers. See Deployment models.

What we deliberately do not do

We never see card data. Payment details stay with the processor via tokenization — Zynth Auth is out of scope for cardholder data (PCI DSS SAQ-A).
We are not a general log sink. We provide identity-centric security and export to your SIEM; we don't ingest arbitrary infrastructure logs.

Reporting a vulnerability

Our security contact is published machine-readably per RFC 9116 at /.well-known/security.txt — on both origins, so scanning either the website or the application finds it. The disclosure policy is on the trust centre. A self-hosted install publishes the same document with your contact (SECURITY_CONTACT), not ours.

Trust centre — the public control, sub-processor, and disclosure summary, written for procurement and security reviews.
Deployment models — SaaS vs. self-host, and what self-host guarantees.
Tenants & users — the isolation model in the data model.
Tokens & sessions — how tokens, revocation, and DPoP work.