Security

1. Encryption

All traffic between Subscriber devices and the Service is encrypted in transit using Transport Layer Security (TLS) version 1.2 or higher. Internal traffic between our application and our database is encrypted in transit and isolated to a private network.

Data at rest in the primary PostgreSQL database and in associated object storage is encrypted using industry-standard symmetric encryption. Encryption keys are managed by the cloud provider's key-management service and rotated on a regular schedule.

2. Authentication

Magic Monkei uses an industry-standard authentication library. Passwords are stored as salted hashes using a memory-hard password-hashing algorithm; cleartext passwords are never written to disk or logs. We support passkey (WebAuthn) authentication and email-based verification. We rate-limit authentication endpoints to mitigate credential-stuffing and brute-force attempts.

3. Payment-data handling

Payment-card data is collected and processed exclusively by Stripe, a PCI DSS Level 1 service provider. Magic Monkei does not receive, transmit, or store full card numbers, expiration dates, or card verification values. Our systems hold only a Stripe customer identifier and the billing metadata required to display billing history and issue invoices.

4. Infrastructure

The Service runs on a self-managed Kubernetes cluster hosted in a leading public-cloud region. Production workloads execute in dedicated namespaces with network policies restricting inter-service traffic. Access to production infrastructure is limited to a small set of named operators authenticated via single sign-on with hardware-key multi-factor authentication; access is logged and auditable.

Operational logs and distributed traces are streamed to a third-party observability provider. Logs are scrubbed of payment-card data, password values, and session tokens before transmission.

5. Backups and continuity

Primary databases are backed up on a daily basis. Backups are encrypted at rest and stored in a separate region from the primary cluster. We periodically test restoration procedures.

6. Incident response and breach notification

Magic Monkei maintains an incident-response process that includes detection, triage, containment, root-cause analysis, and remediation. In the event of a personal-data breach that is likely to result in a risk to the rights and freedoms of affected Subscribers, we will notify the competent supervisory authority within seventy-two (72) hours of becoming aware of the breach, and we will notify affected Subscribers without undue delay where required by applicable law.

7. Vulnerability disclosure

If you discover a security vulnerability in the Service, please report it confidentially to [email protected] (or, if you cannot reach that address, to [email protected]). We commit to acknowledging receipt within five (5) business days and to providing a status update within ten (10) business days.

We do not currently operate a paid bug-bounty program. We do thank researchers in our changelog with their permission. We ask that you do not exploit the vulnerability beyond what is necessary to demonstrate it, do not access or modify data that is not your own, and give us a reasonable opportunity to remediate before public disclosure.

8. Your responsibilities

Account security is shared. We ask that you choose a strong, unique password (or, preferably, register a passkey), keep the device on which you receive verification codes secure, and notify us immediately at [email protected] if you suspect that your account has been accessed without your authorization.