Private betaZynth Auth is currently in private beta testing.New organizations are created by invitation only, and no plan can be purchased yet.Request early access

Trust Centre

Security you can verify

Not a list of adjectives. What Zynth Auth enforces, what evidence it produces, and which of those claims you can check for yourself in the next thirty seconds.

Where does the data live?
Singapore (APAC region), on infrastructure we operate.
Who holds the signing and encryption keys?
We do, on the host, outside the application containers and outside version control.
Which sub-processors are involved?
A short, published list covering hosting and transactional email. See the DPA.
Who is responsible for backups and recovery?
We are, with a defined recovery path and an isolated backup component.
How do upgrades reach the platform?
Continuously, from signed and digest-pinned images, with no build step on the server.
Can it run with no outbound internet access?
Outbound calls are restricted to a vetted allowlist through an egress proxy.

Same codebase either way — the deployment model is an entitlement, never a different product.

What is enforced

Capabilities, not adjectives

Each one states what it does, the mechanisms behind it, and the evidence it leaves. Open any of them.

Tenant isolation

row-level

One organization's data cannot be reached from another's session — and that is a property of the database, not of the queries we remember to write.

  • Postgres row-level security sits beneath every request, so an unscoped query returns nothing rather than someone else's rows.
  • An always-scoped repository layer above it, with a build guard that refuses unscoped data access.
  • Every managed organization runs pooled today, and those two boundaries are the isolation — there is no per-customer database. A single-tenant tier with its own database is designed for but not built, and this page will say so on the day it ships.
  • Negative test suites prove isolation at the application layer and again at the database layer, against real Postgres.

Evidence produced · Every access decision is attributable to a tenant, and cross-tenant reads fail in CI rather than in production.

Access control & least privilege

least privilege

Who may do what is decided server-side on every call, and the platform's own components hold the narrowest privileges that let them work.

  • A fail-closed authorization engine with per-domain permissions, custom roles, and attribute policies — permissions are never trusted from a token.
  • The request-path database role can read and write rows and nothing else: it cannot alter schema, drop tables, or reach another database.
  • Workers, the audit sealer, and the security plane hold separately scoped roles, granted per table.
  • Phishing-resistant passkeys, authenticator codes, login throttling, Argon2id password hashing, and screening against known-breached passwords without the password ever leaving the platform.
  • Step-up re-authentication for sensitive operations, bound to the specific operation and usable once.

Evidence produced · Every privilege grant is declared in code and cross-checked against the live database roles by a CI probe that runs as the real role.

Data privacy & retention

residency + erasure

Where your data lives, how long it stays, and what happens when someone asks for it to be removed.

  • Managed hosting is in Singapore for APAC residency; self-hosting keeps everything inside your own infrastructure.
  • Erasure requests are processed asynchronously and completely, while the tamper-evident record of the erasure itself survives.
  • Retention is enforced per record class, and the evidence store deliberately cannot be purged by the component that writes to it.
  • TLS everywhere with automatically renewed certificates, and encryption at rest for sensitive data.
  • Customer-supplied destinations (webhooks, upstream servers) are reached only through a vetted allowlist, so data cannot flow somewhere unreviewed.

Evidence produced · Deletion and retention actions are audited like any other, so a privacy request has a record that shows what happened and when.

Evidence & audit trail

enforced in CI

The unusual one. Evidence is produced by construction — the build fails if an action would ship without it.

  • More than 240 distinct actions are registered, and every one must carry telemetry, a detection decision, an audit decision, and a control mapping — or an explicitly recorded exemption with a reason.
  • That requirement is a CI guard, not a policy: code that skips it does not merge.
  • Security-relevant actions are written to a hash-chained log that makes silent modification detectable, sealed by a dedicated append-only role.
  • More than 40 distinct control identifiers are mapped across the platform's actions, drawn from a catalogue of 58.
  • Per-framework evidence export returns the matching audit entries with their hashes, on every plan, so the evidence is yours rather than only ours.

Evidence produced · A continuously produced, tamper-evident record — not a reconstruction assembled in the weeks before a review.

Change management & provenance

signed + pinned

You can establish what is running, that it is what we published, and that nobody bypassed review to put it there.

  • Images are built in CI and signed keyless. The server never builds — it verifies every signature and deploys the exact verified digests, aborting the whole deploy on any verification failure.
  • Application containers have no direct route to the internet; every outbound call passes an allowlist proxy.
  • Services run non-root on a read-only filesystem with no-new-privileges and all Linux capabilities dropped. Datastores sit on internal-only networks.
  • Branch protection applies to administrators. Every change is a reviewed pull request through required checks that no one — including the owner — can bypass.
  • Layered supply-chain defence: blocking static analysis, dependency auditing, pinned build actions, and continuous scoring, because no single scanner is trusted alone.

Evidence produced · Every deployed artifact is digest-pinned and signature-verified at deploy time, and the deploy refuses rather than degrades.

Monitoring & response

dead-man's switch

Detection that is wired to a response, and an alerting path designed around the fact that monitoring usually fails as silence.

  • Behavioural detections over the event stream, each raised against the organization it belongs to.
  • Runtime security monitoring on the host, watching what containers actually do rather than only what they were built from.
  • A dead-man's-switch alerting design: the absence of a signal is itself alertable, so a broken pipeline cannot look like a quiet week.
  • Documented incident response and service-degradation procedures, with restore paths rehearsed rather than assumed.
  • Backups with a defined recovery path, and the backup component isolated from the plane it protects.

Evidence produced · Detections, alerts, and operator acknowledgements are part of the same audited record as everything else.

Continuous assurance

We do not ask you to take testing on faith. The platform runs scored drills against its own production and keeps the results — the same evidence a reviewer would ask us to produce.

  • Scheduled drills execute the scenarios that matter — containing a running agent, an autonomy response, a federated workload identity handshake — and each one is scored PASS, FAIL, GATED or UNPROVEN rather than left to a green tick.
  • A declared-but-undriven scenario scores UNPROVEN by construction: a drill cannot quietly pass by skipping the part that would fail.
  • Race scenarios run real concurrent actors against the live API and assert the invariant, not the absence of an error message.
  • Findings become work: each one is a tracked defect, fixed in code rather than documented around.

Evidence produced · Dated run records with per-scenario verdicts, the evidence each leg produced, and the findings that came out of them.

AI oversight

human in the loop

Autonomous agents are governed principals — identified, bounded, and stoppable at the moment they act.

  • Every agent holds its own cryptographic identity and a risk profile that scales how much oversight it attracts. It is never a shared account wearing a human's badge.
  • Authority is delegated from the human the agent acts for and can only ever tighten, never widen.
  • A fail-closed gateway checks allowlist, delegation scope, and rate and budget caps on every single tool call.
  • Sensitive actions park for real-time human approval — bound to the specific action and usable once.
  • A separately permissioned kill switch severs an agent mid-session at the transport, without waiting for it to finish.
  • Where the platform can act on its own, it must first earn that autonomy from its own record of human-approved decisions, and a reversal demotes it.

Evidence produced · Every agent action, approval, refusal, and reversal is recorded with the human accountable for it.

Verify it yourself

Don't take our word for any of it

These run right now, from your machine, against production. No account, no sales call.

your terminal

The issuer is real and standards-shaped

curl -s https://auth.zynthmedia.com/.well-known/openid-configuration | jq .
show expected output

The full OpenID Provider metadata document — endpoints, supported algorithms, PKCE.

The signing keys are published

curl -s https://auth.zynthmedia.com/.well-known/jwks.json | jq '.keys[0].alg'
show expected output

"RS256" — tokens verify offline, in any language, with no call back to us.

There is a route to report a vulnerability

curl -s https://zynthmedia.com/.well-known/security.txt
show expected output

An RFC 9116 contact document — address, expiry, and policy link — served on the domain a researcher would actually scan.

On image signatures · Image signatures are verified at deploy time by the server itself, which aborts rather than degrading. The registry is private, so we do not publish a verification command that would fail for you — licensed self-host customers verify the signed bundles they receive directly, with cosign and a published checksum.

When things go wrong

Fail closed, on purpose

A security platform is defined by what it does when something is missing, unreachable, or ambiguous. Trigger any of them.

A signing key is missing at startup

Refuses to start

Outside development the configuration validator requires real keys and raises. There is no insecure fallback to degrade into.

We hold no third-party attestation today

We are not going to imply otherwise with a badge. What runs instead is mechanical: every action must carry its telemetry, detection, audit, and control decisions before it can merge, and the record it produces is continuous and tamper-evident rather than assembled before a review. Independent assessment is on the roadmap, and we will say so plainly here on the day it exists.

Request the full control package

Resources

The rest of the paperwork

The documents a review asks for, and the fastest way to tell us about a problem.