Privacy Policy

Zynth Media Technology ("we", "us") provides Zynth Auth, a multi-tenant identity and access management platform. This policy explains how we handle personal data for which we are the controller — primarily account, security, and billing data for the people who administer a Zynth Auth tenant, and visitors to this website.

Where we process the personal data of your end-users on your behalf (for example, the identities your organization manages in the platform), we act as a processor and those activities are governed by our Data Processing Addendum, not this policy.

• Account data — email address, name, and organization name you provide at sign-up.
• Authentication data — password hashes (Argon2id; we never store plaintext passwords), encrypted MFA secrets, and passkey (WebAuthn) public-key credentials.
• Security telemetry — IP address, user agent, and authentication/authorization events, used for anomaly detection and the tamper-evident audit log.
• Billing data — plan and usage counts. Card details are handled by PayPal and never touch our systems.
• Support communications — the content of messages you send us.
• Early-access applications — what you submit on our early-access page: your name, work email, role and organization; your application's name, URL, description, stage and platforms; what you would connect and what you want to test; expected scale and timing; and the records of your consent and of your beta acknowledgement (when, and which wording). Held for the sole purpose of selecting and contacting beta testers; deleted on request. The submission is also recorded as an event in our security event store, with the IP address it came from, for abuse detection; that event is purged after 30 days and is not linked back to your application once it is gone.
• Website visit data — our edge access log records, for each request to this website, the page, the status code, the browser's self-reported name (user agent) and the referring site; the IP address and identifying headers are deleted before the line is written, and the log is kept for 30 days. Our cookieless analytics process the IP address only transiently at ingest — to derive a country and a visitor hash that rotates daily — and do not store it (see “Cookies and analytics”).
• Documentation assistant — if you use the Ask AI assistant on our documentation site, the question you type and the documentation excerpts retrieved for it are sent to our AI provider (listed on our sub-processors page) to generate the answer. No account identity or IP address is sent with it; your IP address is used only for an in-memory rate limit that is never written down. Do not put personal data in a question.

• To provide and operate the service (performance of our contract with you).
• To secure the service — detecting brute-force, credential-stuffing, token theft, and other anomalies (our legitimate interest, and yours, in security).
• To process payments for paid plans (performance of contract).
• To communicate service, security, and account notices (legitimate interest / legal obligation).
• To contact you about the private beta when you asked us to (consent, which you can withdraw by asking us to delete your request).
• To comply with legal obligations, and to establish or defend legal claims.

Under the GDPR our legal bases are contract, legitimate interests, consent (where we ask for it, such as your early-access request), and legal obligation. Equivalent bases apply under the Singapore PDPA and the Philippines Data Privacy Act.

We do not sell personal data. We share it only with the sub-processors that help us run the service, each listed with its purpose and processing location on our sub-processors page and in our Data Processing Addendum — the list is derived from the platform’s egress allowlist, and every outbound connection is restricted by that allowlist, so data cannot flow to a destination we have not vetted and named.

The managed offering is hosted in Singapore (APAC region) to support data-residency and sovereignty requirements. Some sub-processors (email, payments, optional social sign-in) operate in the United States; where personal data is transferred internationally we rely on appropriate safeguards such as standard contractual clauses.

If you run Zynth Auth self-hosted, personal data stays entirely within your own infrastructure and this section does not apply.

• Encryption in transit (TLS) and at rest.
• Strict tenant isolation enforced at the database with Postgres row-level security, not just application code.
• Fail-closed design — missing keys, unreachable dependencies, or ambiguous authorization result in denial, never insecure degradation.
• A tamper-evident, hash-chained audit log; least-privilege database roles; and a signed, digest-pinned software supply chain.

We keep personal data only as long as needed for the purposes above or as required by law, and apply configurable retention policies to security and audit data (GDPR Art 5(1)(e) storage limitation). When you close an account, we delete or anonymize associated personal data within a reasonable period, except where retention is legally required.

Depending on your location, you have rights to access, rectify, erase, restrict, and port your personal data, to object to certain processing, and to withdraw consent. Administrators can exercise many of these directly from the in-product Privacy & Data centre (data export and subject-request tools); you can also contact us at any time.

You have the right to lodge a complaint with your data-protection authority (for example, the Singapore PDPC, the Philippines NPC, or your EU/EEA supervisory authority).

Zynth Auth takes some decisions automatically, without a person reviewing them first, because a security control that waits for a human is not a security control. Those decisions can significantly affect an individual — they can end a session or block access.

• What is automated — containment (freezing) of an agent identity, revocation of active sessions and of issued tokens, and rate limiting or throttling of requests. A budget on how much an agent can change, and how often it can be denied, engages that agent's kill switch automatically when exceeded. Disabling a person's account is something our automation is structurally incapable of doing on its own: that class of action is capped so that it may only ever be RECOMMENDED to a human, who signs it — a ceiling that cannot be lifted by configuration. The effect of session revocation on a human user is that they are signed out and can sign in again.
• The logic, in general terms — authentication and authorization events are evaluated against detection rules and behavioural baselines (for example credential-stuffing and brute-force patterns, token replay signals, an agent acting outside its granted scope, or abnormal request volume). Where a rule fires above its threshold, or an agent exhausts its change budget, the protective measure is applied.
• What is NOT automated — autonomous response ships switched off, and while it is off the engine only records what it would have done: it takes no action and makes no proposal. Its measures are ranked by how much harm they can do, and the most damaging rank is capped at recommending to a person. Whether an agent action is held for human approval is set by that agent's oversight mode, a per-permission risk ceiling and per-tool approval flags; where the approvals control is not enabled, such an action is refused rather than performed.
• Human review — a contained agent identity can only be released by a person: releasing is restricted to a human holding the necessary permission, and an administrator in the affected tenant is notified when containment happens. An executed autonomous action can be reverted by a human reviewer. Every such action is written to a tamper-evident, hash-chained audit log, so the reason for it can be reconstructed and verified.
• Objection and contest — you may express your point of view and contest an automated decision affecting you by writing to the contact address below, and a person will review it; your tenant administrator can also raise it on your behalf.

These measures are necessary for the performance of our contract and for the security of the service and its other users. We do not use automated decision-making for profiling unrelated to security, for advertising, or to evaluate individuals commercially.

We use strictly-necessary cookies to keep you signed in (httpOnly, SameSite=Strict). We do not use third-party advertising or cross-site tracking.

Website analytics are first-party and cookieless. We self-host them (Umami) and serve them from our own domain, so no data goes to a third-party analytics provider. No cookie is set and no persistent identifier is assigned — a visit is counted against a hash that rotates daily — so there is no consent banner and no consent gate; we rely on our legitimate interest in understanding aggregate site usage, which you may object to using the contact address below.

Zynth Auth is a business product and is not directed to children. We do not knowingly collect personal data from children.

We may update this policy; material changes will be posted here with a new effective date. For any privacy question or to exercise a right, contact us at legal@zynthmedia.com; security matters may also be raised at security@zynthmedia.com.