Security & Compliance

User access is managed through robust authentication mechanisms:

• Utilizes Supabase Auth, supporting secure email/password authentication (with email confirmation) and Google OAuth 2.0.
• Employs short-lived JWTs (JSON Web Tokens) stored securely in httpOnly cookies with a 15-minute expiry and automatic sliding refresh for enhanced session security.
• Internal staff access to production systems is strictly controlled based on the principle of least privilege using AWS IAM roles and undergoes quarterly access reviews.
• Future roadmap includes support for SCIM provisioning and SSO integration (Okta, Azure AD) targeted for Q4 2025.

We ensure your data remains isolated and inaccessible to other tenants:

• PostgreSQL Row-Level Security (RLS) is strictly enforced on all critical multi-tenant tables, including datasets, fine_tuning_jobs, and fireworks_fine_tuning_jobs.
• RLS policies ensure that database operations (SELECT, INSERT, UPDATE, DELETE) are restricted, allowing users to access only the data associated with their authenticated user ID (auth.uid()).
• All user-uploaded files and generated outputs stored in AWS S3 utilize unique, UUID-based object keys. User-identifiable information is intentionally excluded from S3 paths to prevent enumeration or accidental exposure.

Data is protected both while stored and during transmission:

• In Transit: All communication with Trainified web interfaces and APIs is secured using TLS 1.3, ensuring data confidentiality and integrity during transmission.
• At Rest (Secrets/Keys): Sensitive user-provided credentials (OpenAI API keys, Fireworks API keys, Fireworks Account IDs) are encrypted server-side using AES-256-GCM before being stored in user metadata within the Supabase database.
• At Rest (Storage): Underlying storage for the Supabase PostgreSQL database and AWS S3 buckets is encrypted using AWS Key Management Service (KMS), providing an additional layer of protection for all stored application and user data.

Handling of sensitive credentials and application secrets:

• The application's master ENCRYPTION_KEY (used for encrypting user keys) and other backend service credentials (like database passwords, AWS keys) are securely stored using AWS Secrets Manager in production (Supabase Vault may be used in development environments).
• We follow a 90-day rotation policy for critical secrets where feasible, utilizing automated rotation hooks when supported by the service.
• Strict logging policies are in place to ensure that no secrets, API keys, or sensitive credentials are ever written to application logs. Error traces automatically redact sensitive patterns.

Security controls applied at each stage of the data processing pipeline:

Our cloud infrastructure is designed with security best practices:

• Hosted entirely on Amazon Web Services (AWS) within the us-west-2 region (unless an optional EU region is selected).
• Utilizes AWS Virtual Private Cloud (VPC) with private subnets for backend workers and database instances, minimizing direct exposure to the public internet.
• AWS Security Groups restrict network traffic. Ingress is limited primarily to HTTPS (port 443) from trusted sources (like Cloudflare or ALB). Egress traffic is restricted to necessary endpoints (port 443 for external APIs, port 22 for specific jump-box access if applicable).
• AWS services interact using IAM Roles with temporary credentials wherever possible, minimizing the use of long-lived IAM access keys.
• The Redis cluster (used for job queuing) requires password authentication and supports TLS for encrypted connections.

We continuously monitor the platform and have procedures for responding to incidents:

• Infrastructure and application logs are aggregated using AWS CloudWatch. AWS CloudTrail provides an audit trail of API calls within our AWS account.
• Supabase provides built-in database audit logs, which are retained for 30 days.
• Key performance metrics and security events trigger alerts via CloudWatch Alarms, integrated with PagerDuty for 24x7 on-call rotation.
• We maintain an incident response plan with a Service Level Agreement (SLA) of 4 hours to acknowledge critical security or availability incidents.

Our ongoing commitment to meeting industry compliance standards:

• SOC 2 Type I: Audit preparation is in progress, targeting report submission in Q3 2025.
• Data Processing Addendum (DPA): A standard DPA is available for customers requiring GDPR or other data processing compliance documentation.
• EU Data Residency (Optional): Planned for Q4 2025, offering customers the option to process and store data exclusively within AWS EU regions.

We value the security community. If you believe you've discovered a security vulnerability in our platform, please notify us immediately at security@trainified.com.

We are committed to working with researchers who submit security reports. We follow a 90-day coordinated disclosure policy and maintain a public Hall of Fame to recognize contributions (details available upon request).

Policies regarding how long your data is stored and how it is removed:

• User-initiated deletion of datasets or fine-tuning job records results in the immediate removal of corresponding database rows and associated objects (uploaded files, extracted text, generated output) from AWS S3.
• Temporary files generated during processing (e.g., chunked results) are automatically cleaned up shortly after job completion or failure.
• Unreferenced S3 objects (e.g., from incomplete uploads or orphaned processes) are automatically identified and deleted after a 30-day retention period via S3 Lifecycle policies.
• Encrypted nightly backups of the primary PostgreSQL database are taken and retained for 30 days. These backups are stored securely in a separate, restricted AWS account.