Information Security Addendum

This Information Security Addendum ("Addendum") describes the technical and organisational measures Magdox Private Limited implements to protect Customer Data processed through the Magdox platform. It is incorporated by reference into our Terms of Service and, where applicable, our Data Processing Agreement. The controls described here apply to all Magdox plans unless stated otherwise. Where a control is planned rather than operational, we say so.

1. Encryption

In transit. All connections to the Magdox platform are encrypted using TLS 1.2 or above. Connections between the application and the PostgreSQL database require TLS; the database will not accept an unencrypted connection.

At rest. Account data, competitor watch lists, collected signals, digests, and uploaded documents are stored on Oracle Cloud Infrastructure block volumes and object storage, encrypted at rest with AES-256 by the platform.

Bring-your-own-key AI credentials. Where a customer supplies their own AI provider API key, that key is encrypted at the application layer with AES-256-GCM before it is written to the database, using a key held separately from the database itself. An authenticated cipher is used deliberately: it detects tampering rather than silently decrypting altered data.

Secrets management. Application secrets are held in a dedicated secrets manager (OpenBao) and injected into the running process at start-up. They are never written to disk as environment files and never committed to source control.

2. Authentication and Access Control

Identity provider. Authentication is handled by WorkOS. Magdox does not store customer passwords.

Multi-factor authentication. Every account may enrol a second factor, and the account holder chooses which: a time-based one-time password from an authenticator application, or a single-use code delivered by email. Two-factor authentication is mandatory for organisation administrators and can be required organisation-wide.

Passwordless sign-in. A time-limited, single-use code sent by email is available as an alternative to a password. A second factor is still required afterwards where one is enrolled, so passwordless sign-in is not a route around MFA.

Sign-in method. Accounts sign in with a password or a time-limited, single-use email code. Social and SAML-based enterprise single sign-on are not currently offered.

Sessions. Sessions are short-lived signed tokens held in cookies marked HttpOnly, Secure, and SameSite=Strict, and are additionally bound to a server-side session record. Signing out, revoking another device, or completing a password reset deletes that record and takes effect on the next request rather than waiting for the token to expire. Sessions also expire after a period of inactivity.

Role-based access control. Permissions within an organisation are governed by role. Administrative actions are re-checked on the server for every request; hiding a control in the interface is never treated as an access control.

Multi-tenant isolation. Every competitor, signal, digest, battlecard, and document is scoped to the owning organisation at the query layer. The organisation identity for a request is always derived from the authenticated session, never from a value supplied by the client, so a caller cannot reach another organisation's records by substituting an identifier.

3. Application Security

Cross-site request forgery. State-changing requests are rejected unless they originate from an allowed origin, verified against the request's Origin and Referer headers. Requests with neither are refused rather than allowed.

Browser hardening. Responses carry a Content Security Policy, HTTP Strict Transport Security, X-Frame-Options set to DENY, X-Content-Type-Options set to nosniff, and a restrictive Referrer-Policy. Framing of the application is disallowed, which prevents clickjacking.

Rate limiting. Authentication, password reset, and other sensitive endpoints are rate limited using a sliding window held in a shared store, so limits hold across application instances rather than being enforced per process.

Outbound request controls. Magdox retrieves publicly available pages on a customer's behalf. Before any such request, the target hostname is resolved and every resolved address must be publicly routable; addresses in private, loopback, link-local, and carrier-grade NAT ranges are refused. Redirects are followed manually and each hop is re-checked, so a public URL cannot redirect the fetch onto internal infrastructure.

Uploads. Uploaded documents are checked for size, declared type, file extension, and actual file signature before they are stored. Files are written under server-generated names; a filename supplied by a user never reaches the filesystem.

Audit logging. Authentication events, administrative changes, data exports, and account lifecycle actions are recorded in an audit log available to organisation administrators.

4. Artificial Intelligence and Customer Data

Your provider, your key. AI-assisted summaries, battlecards, and win/loss analysis run against an AI provider the customer chooses and authorises with their own API key. Magdox does not resell model access and does not send Customer Data to a model the customer has not configured.

No training on Customer Data. Magdox does not train, fine-tune, or evaluate any model on Customer Data. Where a customer's chosen provider offers its own data-use terms, those terms govern the customer's relationship with that provider directly.

Untrusted content handling. Content collected from third-party websites is attacker-influenced by nature: anyone who controls a tracked page controls what we read from it. Such content is isolated inside per-request delimiters that cannot be predicted or closed by the content itself, and the model is instructed to treat everything within them as data rather than instructions. This is a mitigation, not a guarantee, and AI-generated output should be treated as a research aid rather than a verified statement of fact.

Optional. The platform is usable without configuring any AI provider. Signal collection, change detection, and delivery do not depend on it.

5. Infrastructure

Magdox runs on Oracle Cloud Infrastructure in the India West (Mumbai) region (ap-mumbai-1), keeping Customer Data within Indian jurisdiction consistent with the Digital Personal Data Protection Act, 2023.

The database is self-managed PostgreSQL on a dedicated instance in a private subnet with no public IP address and no inbound route from the internet. Application, background worker, and database instances are placed in separate fault domains, so a single hardware failure group cannot take down compute and data together. Administrative access to all hosts is over a private WireGuard-based network (Tailscale); no host exposes SSH to the public internet.

6. Backup and Disaster Recovery

6.1 Region strategy. Mumbai (ap-mumbai-1) is the primary region. Backups replicate to India South (Hyderabad, ap-hyderabad-1). Both are within India, so replication does not move Customer Data outside Indian jurisdiction. Mumbai is a single-availability-domain region, which is why fault domain separation and off-region backup replication carry the resilience rather than in-region availability domain spread.

6.2 What is backed up.

Data	Method	Frequency	Retention
PostgreSQL database	Logical dump to object storage, verified readable before it is accepted	Nightly	14 days
PostgreSQL write-ahead log	Continuous archiving to object storage for point-in-time recovery	At least every 5 minutes	16 days
Database block volume	Automated volume snapshots	Daily, with weekly and monthly retention	Up to 12 months
All of the above	Cross-region replication to Hyderabad	Asynchronous, near real time	Matches source
Application code	Not backed up; redeployed from source control	—	—

Backups are verified at creation: a dump that cannot be read back, or that is implausibly small, is rejected rather than stored. Restore procedures are exercised against a scratch database rather than assumed to work.

6.3 Recovery model. Magdox uses a backup-and-restore model. We do not currently maintain standby compute in the disaster recovery region. On loss of the primary region, infrastructure is rebuilt from source-controlled infrastructure-as-code, the most recent database backup is restored from the replicated copy, and the write-ahead log is replayed forward. We state this plainly because a warm or pilot-light standby is a materially different commitment, and we do not claim one we do not operate.

6.4 Recovery objectives.

Measure	Target
Recovery Point Objective (data loss) — primary region recoverable	Approximately 5 minutes, via write-ahead log replay
Recovery Point Objective (data loss) — full region loss	Up to 24 hours, bounded by the last replicated nightly dump
Recovery Time Objective (time to restore)	Best effort; not contractually committed

These are engineering targets, not service level guarantees. Because we do not hold standby compute, recovery time depends on rebuilding infrastructure and restoring data, and we will not publish a recovery time commitment we have not demonstrated. Customers with a contractual recovery time requirement should contact us before relying on the platform for that purpose.

7. Sub-processors and Payments

The third parties that process Customer Data on our behalf, and the purpose of each, are listed in our Data Processing Agreement. We give at least 14 days' notice before adding a new sub-processor.

Payment card data. All card data is handled exclusively by Dodo Payments through their hosted checkout as Merchant of Record. Magdox does not collect, transmit, process, or store cardholder data, and is therefore outside PCI DSS scope as the upstream merchant.

8. Certifications

Magdox does not currently hold ISO 27001, SOC 2, or any equivalent certification, and we will not claim one we have not earned. The controls in this Addendum are operational today; certification is independent verification of such controls, not a precondition for them. Our current position is described on our Security page.

9. Reporting a Vulnerability

We welcome reports from security researchers. Please write to [email protected]. We aim to acknowledge reports within three business days. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service degradation, and give us reasonable opportunity to remediate before disclosure.

10. Changes to This Addendum

We may update this Addendum as our security architecture changes. Material changes are communicated in the same way as changes to our Terms of Service. Where a control described here is later weakened or withdrawn, we will say so explicitly rather than quietly removing the paragraph.