Security

1. Overview

ThorAI is built on a security-first architecture. We apply the principle of least privilege across all internal systems, encrypt sensitive data at every layer, and treat security as an ongoing programme: not a one-time checklist. This page summarises the key controls we maintain to protect the platform, our vendors, and their customers.

2. Infrastructure

• Cloud hosting: ThorAI runs on Google Cloud Platform (GCP), one of the world's most secure cloud environments. GCP maintains ISO 27001, SOC 2 Type II, and PCI-DSS certifications at the infrastructure level.
• Network isolation: all services run inside private Virtual Private Cloud (VPC) networks. Public-facing services are exposed only through load balancers with strict ingress rules. Internal services are not reachable from the public internet.
• DDoS protection: network-level DDoS mitigation is provided by GCP Cloud Armor and applied to all customer-facing endpoints.
• High availability: critical services are deployed across multiple availability zones to prevent single points of failure. Automated failover is in place for database and application tiers.
• Backups: databases are backed up continuously with point-in-time recovery (PITR). Backups are encrypted, stored in a separate GCP region, and tested regularly.

3. Data Protection

• Encryption at rest: all data stored in ThorAI databases and object storage is encrypted using AES-256.
• Encryption in transit: all communication between clients and ThorAI services is encrypted using TLS 1.2 or higher. Older TLS versions and weak cipher suites are disabled.
• Envelope encryption for sensitive fields: high-sensitivity data (KYC documents, payout credentials, webhook secrets) is protected by a dedicated Key Encryption Key (KEK) using ECDH-based envelope encryption. Even a full database compromise does not expose these fields without the KEK.
• Password hashing: vendor passwords are hashed using industry-standard algorithms. Passwords are never stored or logged in plain text under any circumstances.
• Secrets management: application secrets, API keys, and credentials are managed via a dedicated secrets management platform (Doppler). Secrets are never hardcoded in source code or configuration files.

4. Access Controls

• Principle of least privilege: all internal services and personnel are granted only the minimum access required to perform their function. Access is reviewed periodically and revoked immediately upon role changes or offboarding.
• Multi-factor authentication (MFA): MFA is enforced for all internal personnel accessing production systems, cloud consoles, and secrets management.
• Role-based access control (RBAC): the platform enforces strict per-store data isolation. A vendor cannot access another vendor's store data, orders, or customer records under any circumstances.
• Audit logging: all privileged actions on production systems are logged with timestamps, user identity, and IP address. Logs are retained for a minimum of 12 months and are tamper-evident.
• Session management: vendor sessions use short-lived cryptographically signed tokens. Sessions expire after inactivity and are invalidated immediately upon logout or password change.

5. Application Security

• Secure development lifecycle: security considerations are integrated into every stage of development. Code changes go through peer review before being merged to production.
• Input validation: all user-supplied input is validated and sanitised server-side. We apply parameterised queries throughout the data layer to prevent SQL injection. Output is escaped to prevent cross-site scripting (XSS).
• CSRF protection: all state-changing requests require CSRF tokens bound to the authenticated session.
• Dependency management: third-party dependencies are audited regularly for known vulnerabilities. Critical security patches are applied promptly.
• Rate limiting: authentication endpoints, OTP delivery, and sensitive API routes are rate-limited to mitigate brute-force and enumeration attacks.
• Content Security Policy (CSP): HTTP security headers including CSP, HSTS, and X-Frame-Options are applied to all customer-facing pages.

6. Payment Security

• ThorAI does not store, process, or transmit raw payment card data. All card handling is performed exclusively by Paystack, a PCI-DSS Level 1 certified payment processor.
• Webhook events from payment partners are verified using HMAC signatures before any order state is updated. Replay attacks are mitigated by timestamp validation and idempotency checks.
• Payout credentials (bank account details, Mobile Money wallets) are stored using envelope encryption and are only decrypted within isolated, audited processes at settlement time.

7. Incident Response

ThorAI maintains a documented incident response plan. In the event of a security incident:

• Detection: automated alerting monitors for anomalous activity, failed authentication spikes, and unusual data access patterns 24/7.
• Containment: affected systems are isolated immediately upon confirmation of a breach. Access credentials are rotated and impacted services are taken offline if necessary to limit damage.
• Notification: affected vendors are notified within 72 hours of our confirming a personal data breach. Where required by law, the relevant data protection authority is also notified within the same window.
• Post-incident review: every significant incident results in a post-mortem report. Findings are used to strengthen controls and prevent recurrence.

8. Responsible Disclosure

We welcome reports from security researchers. If you discover a vulnerability in ThorAI, please report it to us responsibly before disclosing it publicly:

• Email support@trythorai.com with a clear description of the vulnerability, steps to reproduce, and any supporting evidence (screenshots, logs, proof-of-concept).
• We will acknowledge your report within 2 business days.
• We will investigate and provide a status update within 10 business days.
• We ask that you do not access, modify, or delete data belonging to other users while investigating.
• We will not take legal action against researchers who follow this policy in good faith.

We do not currently operate a public bug bounty programme, but we recognise meaningful contributions privately and intend to formalise a programme in the future.

9. Contact

Security reports: support@trythorai.com
General support: support@trythorai.com