Tarosyn Legal

Security Overview

Last updated May 31, 2026

Tarosyn is built on the belief that your spiritual journey is deeply personal. Protecting the data you share with us — your readings, birth details, messages, and payment information — is a responsibility we take seriously. This page summarises the controls we have in place.

Visit the Trust Center

The single hub linking every security, privacy, compliance, and AI governance document — plus enterprise documentation requests.

compliance documents

Enterprise, security, and compliance teams can review and download our core governance documents directly. For the full library — including sub-processors, data retention, and audited controls — visit the Trust Center.

Data Processing Agreement (DPA)

Controller/processor roles, our sub-processor list, technical and organisational security measures, breach notification terms, and SCCs for GDPR-compliant data transfers.

View

Information Security Policy

Our formal commitments on security governance, access controls, risk management, and incident response — written for enterprise and partner review.

View

1. encryption in transit

All communication between your browser or mobile app and Tarosyn's servers is protected by TLS (Transport Layer Security). We require modern cipher suites and do not support legacy protocols such as SSLv3, TLS 1.0, or TLS 1.1.

HTTPS enforced across every endpoint — HTTP requests are redirected automatically Strict-Transport-Security (HSTS) headers encourage browsers to remember to always use HTTPS WebSocket connections (used for real-time features such as live reading sessions) are also TLS-encrypted

2. encryption at rest

Sensitive data stored by Tarosyn is encrypted at rest using industry-standard encryption provided by our hosting and storage infrastructure.

Database volumes are encrypted at the storage layer Object storage (uploaded images, generated artwork, documents) uses server-side encryption Passwords are never stored in plain text — they are hashed using a modern adaptive algorithm (bcrypt) before persistence Payment card data is not stored on Tarosyn servers — billing is handled entirely by Stripe, a PCI-DSS Level 1 certified processor

3. access controls

Access to Tarosyn systems follows the principle of least privilege — staff and automated processes are granted only the permissions required for their specific role.

Production database access is restricted to backend services and a small number of authorised engineers Administrative UI actions (content moderation, tier management, code proposals) require an authenticated session with verified god-mode or subadmin privileges — bot API keys cannot approve their own changes Destructive or sensitive admin operations (raw SQL, migration runs) additionally require a direct session, not just a bot key Multi-factor authentication is encouraged for all team members with access to production systems API endpoints enforce authentication and authorisation server-side; client-supplied roles or user IDs are never trusted without server validation

4. infrastructure & hosting

Tarosyn's backend services run on Replit's managed cloud infrastructure, which provides platform-level isolation, automatic TLS termination, and regular security patching of the underlying runtime environment.

Application containers are isolated at the platform level Outbound server-side fetches (image proxy, link previews) validate destination URLs against a blocklist of private and link-local IP ranges to prevent server-side request forgery (SSRF) Uploaded media is stored in object storage with server-controlled ACLs; content is served with X-Content-Type-Options: nosniff headers and, for executable MIME types, a Content-Disposition: attachment header to prevent same-origin script execution Dependency audits are run as part of our CI pipeline to flag known vulnerable packages

5. monitoring & incident response

We maintain structured server-side logging of authentication events, payment actions, and administrative operations. Logs are used to detect anomalies and to reconstruct event timelines during incident investigations.

Auth events (login, OAuth callbacks, Apple/Google native sign-in, failed attempts) are logged with contextual metadata Payment and entitlement changes are audit-logged with the acting user and method Moderation actions (content removal, bans, dismissals) are recorded in an audit trail We aim to investigate and resolve confirmed security incidents in a timely manner and will notify affected users as required by applicable law

6. third-party services

Tarosyn integrates with a small number of trusted third-party providers. We share only the data each service requires to perform its function.

Stripe — payment processing. Card data goes directly to Stripe and never touches Tarosyn servers. OpenAI — AI reading generation, Oracle chat, and image creation. Prompts include only the data necessary for the requested feature; we do not send raw contact lists or full user profiles. SendGrid — transactional email delivery (verification codes, notifications). Only the recipient address and relevant content are sent. Apple App Store / Google Play — in-app purchase verification. Transaction tokens are verified server-to-server against Apple's and Google's APIs. vulnerability disclosure

We welcome responsible security research. If you believe you have found a vulnerability in any Tarosyn service, please report it through our Bug Bounty programme. Valid reports are reviewed by the engineering team and, where appropriate, rewarded with Luna credits.

Please do not publicly disclose a potential vulnerability before we have had a reasonable opportunity to investigate and address it. We ask that you:

Describe the vulnerability clearly, including steps to reproduce Limit testing to your own account — do not access or modify other users' data Avoid automated scanning or denial-of-service techniques Give us a reasonable time to investigate before any public disclosure

For urgent security matters that cannot be submitted through the in-app form, email [email protected].

For the detailed operational policy behind these practices — data classification tiers, access provisioning and deprovisioning, incident response SLAs, audit log retention, and employee security training — see our Information Security Policy.

View the Bug Bounty programme changes to this overview

As our security programme matures we will update this page to reflect new controls and certifications. Material changes will be noted in the "Last Updated" date above. For questions about our security practices, contact [email protected].

Questions? [email protected]