Security is a first-class concern.

ThyncLabs treats security as a foundational engineering concern, not a compliance checkbox. We apply a layered security model across infrastructure, application, data, and people — informed by the OWASP Top 10, CIS benchmarks, and industry standard threat modelling.

Cloud Architecture

DesignLoop runs on hardened cloud infrastructure within a single primary region. All production services operate inside a private Virtual Private Cloud (VPC) with strict network segmentation between compute, database, and cache tiers.

• Compute: containerised workloads with minimal base images and read-only root filesystems where applicable
• Database: managed PostgreSQL with automated backups, point-in-time recovery, and encryption at rest
• Cache: Redis with AUTH, TLS, and no public endpoint
• Object storage: private buckets with pre-signed URL access; no public ACLs
• DNS & DDoS protection: edge-level protection with rate limiting and geo-blocking capabilities

Availability

• Multi-AZ deployment for database and stateful services
• Automated health checks with self-healing container orchestration
• Continuous uptime monitoring with alerting to on-call engineers
• Disaster recovery plan with RTO < 4 hours and RPO < 1 hour for production data

In Transit

• All traffic between clients and the DesignLoop API is encrypted using TLS 1.2 or higher
• TLS 1.0 and 1.1 are disabled; weak cipher suites are explicitly denied
• HSTS (HTTP Strict Transport Security) enforced with a 1-year max-age and includeSubDomains
• Internal service-to-service communication within the VPC is encrypted

At Rest

• All database volumes and object storage buckets are encrypted using AES-256
• Encryption keys are managed by the cloud provider's Key Management Service (KMS) with envelope encryption
• Application-level encryption applied to sensitive fields (e.g. voice transcripts) using a separate key hierarchy
• Key rotation is performed annually or upon suspected compromise

Secrets Management

Secrets (API keys, database credentials, signing keys) are never stored in source code, version history, or plain-text configuration files. They are injected at runtime via an environment-isolated secrets vault with audited access logs.

Principle of Least Privilege

Every service account, IAM role, and database user is granted the minimum permissions necessary to perform its function. Broad wildcard policies are prohibited in production.

Authentication

• JWT-based authentication with short-lived access tokens (15-minute expiry) and secure refresh flows
• Passwords are hashed using bcrypt with a cost factor of 12 or higher
• Email verification required before account activation
• Account lockout after repeated failed login attempts with exponential back-off
• Admin accounts require two-factor authentication (TOTP)

Role-Based Access Control (RBAC)

• Platform roles: user, recruiter, admin — enforced at the API handler level
• Enterprise roles: member, manager, owner — scoped to company workspace
• All admin endpoints require explicit admin middleware verification independent of JWT claims
• Privileged operations (plan changes, user deletion) require re-authentication

Internal Access

• Production database and infrastructure access requires VPN + MFA
• All privileged access is logged and reviewed quarterly
• Engineering access to production is limited to a named set of senior engineers
• No standing access — just-in-time access provisioning for incident response

• All inbound traffic passes through a web application firewall (WAF) with OWASP Core Rule Set
• DDoS mitigation at the edge layer; volumetric attacks are absorbed before reaching origin
• Rate limiting on all API endpoints: global and per-IP; stricter limits on authentication and payment endpoints
• Security group rules permit only the minimum required inter-service traffic; default-deny posture
• No SSH exposed to the public internet; all administrative access via bastion with MFA
• Egress filtering applied to prevent exfiltration via unexpected outbound connections

Code Review

All production changes require peer review via pull request before merge. Security-sensitive changes (authentication, payment, data access) require review by a security-aware engineer.

Automated Scanning

• Static analysis (SAST) runs on every pull request to catch common vulnerability patterns
• Dependency scanning via automated SCA tooling; critical/high CVEs block merge
• Container image scanning before deployment; images with critical vulnerabilities are rejected
• Secrets scanning prevents accidental credential commits

Security Testing

• Manual security review for all new authentication flows, payment integrations, and data access patterns
• Annual third-party penetration testing of production infrastructure and application layer
• Results are remediated according to severity SLAs (see Vulnerability Management)

We triage and remediate vulnerabilities according to the following SLAs:

Dependencies are monitored continuously. Critical CVEs in direct dependencies are patched and deployed within the SLA window above, independent of the normal release cycle.

Detection

Anomaly detection and alerting is configured across authentication events, API error rates, infrastructure metrics, and third-party integrations. All production alerts are routed to an on-call rotation with 24 × 7 coverage.

Response Process

• Triage: identify scope and severity within 1 hour of detection
• Containment: isolate affected systems or revoke compromised credentials immediately
• Investigation: root cause analysis with timeline reconstruction
• Remediation: patch, deploy, and verify fix
• Post-mortem: blameless review published internally within 5 business days

Breach Notification

In the event of a data breach affecting your personal data, we will notify affected users by email within 72 hours of becoming aware of the breach, as required by applicable data protection law. Enterprise customers will be notified directly via their designated security contact.

Session Data

• Voice transcripts are encrypted at the application layer before storage
• Whiteboard diagram data is stored per-user with access controls enforced at the API layer
• Session data is isolated between users — no cross-user data leakage is architecturally possible

Enterprise Data Isolation

• Enterprise company data is logically isolated by company_id at the database row level
• All queries are parameterised to prevent SQL injection
• Enterprise admin roles cannot access data outside their own company workspace

Backups

• Automated daily database snapshots retained for 30 days
• Backups are encrypted at rest using the same KMS key hierarchy as production data
• Backup restoration is tested quarterly

• All engineering hires undergo background verification
• Security awareness training is mandatory at onboarding and annually thereafter
• All employees sign confidentiality agreements covering customer data
• Access to production systems is provisioned on a need-to-know basis and revoked immediately on offboarding
• Workstations require full-disk encryption, screen lock, and approved endpoint security tooling
• Phishing simulation exercises are conducted quarterly

DesignLoop is designed with the following frameworks and regulations in mind:

We deeply value the security research community. If you discover a vulnerability in DesignLoop, we ask that you report it responsibly so we can address it before it is disclosed publicly.

How to Report

• Email: support@thynclabs.com
• Include a clear description of the vulnerability and steps to reproduce
• Provide your contact details for follow-up
• We will acknowledge receipt within 24 hours and provide a resolution timeline

Our Commitments

• We will not take legal action against researchers acting in good faith
• We will keep you informed of remediation progress
• We will publicly acknowledge your contribution (with your permission) after the fix is deployed

Scope

• In scope: thynclabs.com and all subdomains, DesignLoop API, authentication flows, payment flows
• Out of scope: social engineering attacks on ThyncLabs employees, physical attacks, denial-of-service, third-party services (Razorpay, cloud provider)