Privacy Policy

Zynth Media Technology ("we", "us") provides Perihelium, 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 Perihelium 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. Notifications about a detection, which can include the IP address or email address involved, are delivered to our operators through the alert channels named on our sub-processors page. Where an event involves an email address, such as a failed sign-in or a password-reset request, the event and the audit log record a keyed pseudonym of the address rather than the address, and the audit log records the network an IP address sits in rather than the address itself; to investigate attacks we keep the address from a failed sign-in or reset request in a separate store for 30 days and then delete it.
• 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 (see “Cookies and analytics”) record, for each page view, the page, the referring site, the browser, operating system, device class, screen size and language the browser reports, and a location derived from the IP address — country, and region or city where the lookup supplies them (our reports show country only). The IP address is used only transiently at ingest, to derive that location and a visitor hash, and is not stored.
• 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.
• Security assessments — when AI-written security summaries are enabled, the summary of a set of detections is generated by our AI provider (listed on our sub-processors page) from rule names, severities, counts and times only. The IP address or account a detection is about is replaced by a pseudonym before anything is sent; the provider does not receive the address or account, and the pseudonym cannot be matched with another customer’s. Self-hosted deployments send no detections to any provider unless the operator sets a provider key.

• 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: the platform’s own outbound connections are restricted to that allowlist, so they cannot reach a destination we have not vetted and named. The one exception is a destination you choose yourself — a webhook endpoint, or an OpenID Connect back-channel-logout endpoint. We send to exactly the address you registered, through a dedicated egress proxy that refuses every private, internal and cloud-metadata address; the recipient is your own system, not our sub-processor.

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 Perihelium self-hosted, personal data stays entirely within your own infrastructure and this section does not apply.

• Encryption in transit: every connection to the service uses TLS, with certificates renewed automatically.
• Encryption of the most sensitive stored secrets: authenticator (MFA) secrets, webhook signing secrets and single-sign-on client secrets are encrypted before they are written to the database, with keys held outside the database. Passwords and recovery codes are never stored in a recoverable form — only as salted Argon2id hashes. Other stored data is protected by the access controls below and by the hosting provider’s infrastructure, not by a further layer of application-level encryption.
• Encrypted backups: database backups are encrypted on our server, with a public key, before they leave it, so the storage provider holds only ciphertext; the decryption key is kept offline and is not on the server.
• 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.

When an organization is deleted we can restore it for 30 days. After that we delete every record it owned (its members' memberships, settings, credentials, integrations and logs), leaving only the tamper-evident audit log described below and an empty record of the organization's identifier. Database backups age out on their own schedule, so the data is gone from every backup within 120 days of the organization being deleted. Records of the confirmations you give before a payment-related action are kept for 13 months, the card-dispute period, and then deleted. A note an administrator writes on a data-subject request is limited to 1000 characters, and any email address in it is removed when it is saved.

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.

When we carry out a request to erase a person, we remove their profile, their sign-in credentials (password hash, authenticator secrets, recovery codes and passkeys), their memberships in every organization and the identity-provider identifier held on them, their connected-app consents (and end their live sessions), the IP address on their consent history, and the email address, IP address and session identifier on the security events of their own actions; their email address is replaced by a placeholder. On the request itself we remove the email address, IP address and free-text description; the request keeps its type, status, dates and any notes our administrators recorded, as the record that it was handled.

Two things are deliberate. We do not alter the tamper-evident audit log: it is retained unaltered so that its integrity can be proven, because we need it to meet legal obligations and to establish, exercise or defend legal claims (GDPR Art 17(3)), and what it holds about a person is limited by design: it records a keyed pseudonym in place of an email address and the network of an IP address in place of the address itself, although entries written before that change can still contain an IP address or email address that was recorded when an action took place. The address kept for security investigation is removed when we erase a person. And a request to erase a person is refused while that person is the only active owner of an organization that is still active, because carrying it out would leave the organization without an owner.

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).

Perihelium 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 one strictly-necessary cookie to keep you signed in to the console (httpOnly, SameSite=Strict, scoped to the sign-in API path); this website sets no cookie. The console also keeps the page you were heading to in the browser’s session storage while you complete a social or single-sign-on sign-in, and removes it afterwards. 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 nothing is written to your device. A visit is counted against a hash of values we do not store, computed with a salt that rotates, so a returning visitor is recognised only within that rotation window, and no identifier is assigned to your device. 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. Analytics records are kept until we delete them; the separate store built from the web-server log is deleted automatically after 400 days.

Perihelium 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.