SECURITY WHITEPAPER

This Security Whitepaper describes the technical and organizational security controls implemented by Lemnia LLC to protect customer data on the Lymnus platform. It is intended for enterprise procurement, due diligence, and security review purposes.

1. Security Overview

Lemnia LLC applies a defense-in-depth security architecture to the Lymnus platform. Security is embedded at every layer: infrastructure, application, data, network, and people. Our security program is aligned with industry best practices and is continuously reviewed and improved.

2. Infrastructure Security

2.1 Cloud Infrastructure

The Lymnus platform is hosted on Amazon Web Services (AWS), which maintains comprehensive compliance certifications including ISO 27001, SOC 1, SOC 2, SOC 3, PCI DSS, and FedRAMP. AWS physical and environmental security controls apply to all Lymnus infrastructure.

2.2 Network Architecture

All production resources are deployed within a private Virtual Private Cloud (VPC) with restrictive security group rules
Network traffic between services is encrypted and access is controlled by least-privilege security groups
Web application traffic is served exclusively over HTTPS with TLS 1.2 or higher
Public-facing infrastructure is protected by web application firewall (WAF) and DDoS mitigation controls provided by AWS

2.3 Availability and Redundancy

Production database: Amazon RDS with Multi-AZ deployment for automatic failover
Application servers: Auto-scaling EC2 instances across multiple Availability Zones
Object storage: Amazon S3 with cross-region replication for critical assets
Cache layer: Amazon ElastiCache with replication for session and token data
Real-time messaging: Self-hosted Laravel Reverb WebSocket server

3. Application Security

3.1 Secure Development

Security review is part of the development and deployment process for all significant features
Dependencies are regularly audited for known vulnerabilities
Code changes are reviewed before deployment
Security patching follows a defined process with priority given to critical vulnerabilities

3.2 Authentication

Password hashing using bcrypt with appropriate cost factor
Two-factor authentication (TOTP) available for all accounts
OAuth 2.0 integration with Google, Microsoft, and GitHub for federated authentication
SAML 2.0 Single Sign-On (SSO) for enterprise customers, supporting Okta, Azure AD, OneLogin, and Google Workspace
Session tokens are cryptographically random, stored in secure, HttpOnly cookies
Session invalidation on password change and explicit logout

3.3 Authorization

Role-Based Access Control (RBAC) at the team level (Owner, Admin, Member)
Granular Workspace Permissions controlling feature-level access for team members
API tokens with fine-grained permission scopes (read/write per resource type)
OAuth 2.0 authorization code flow with PKCE for third-party API clients
IP Allowlisting for enterprise accounts to restrict access by network origin

3.4 API Security

All API endpoints require authentication via Sanctum token or OAuth Bearer token
Rate limiting applied to all public-facing endpoints to prevent abuse
CSRF protection on all state-changing web requests
API tokens are hashed before storage; plaintext is shown only once at creation

3.5 Input Validation and Output Encoding

All user input is validated server-side using defined rule sets
SQL injection is prevented through the use of parameterized queries (Laravel Eloquent ORM)
Cross-site scripting (XSS) is mitigated through output encoding and Content Security Policy headers
File uploads are validated for type, size, and content before processing

3.6 Webhook Security

All webhook deliveries include an HMAC-SHA256 signature in the X-Lymnus-Signature header
Customers are advised to verify signatures on every delivery and reject replays older than 5 minutes
Webhook signing secrets are unique per endpoint and stored encrypted

4. Data Security

4.1 Encryption

Data in transit: TLS 1.2 or higher enforced on all connections (HTTPS, WebSocket Secure)
Data at rest: AES-256 encryption applied to S3 object storage and RDS database volumes
Sensitive credentials (API keys, OAuth tokens, payment tokens): Encrypted at the application layer using additional encryption before storage
Database connection strings, API keys, and secrets: Managed via environment configuration and not committed to version control

4.2 Data Isolation

Each customer's project data is stored under a namespaced path tied to their user ID, preventing cross-customer data access
Database queries are scoped to the authenticated user's resources at the ORM level
Shared infrastructure does not expose one customer's data to another

4.3 AI Data Processing

Customer data transmitted to AI model providers (Anthropic, OpenAI, Google) is sent via API calls over encrypted connections
We maintain Data Processing Agreements with all AI providers restricting the use of API-submitted data for model training
AI providers are listed as Sub-processors in our DPA

5. Access Control

5.1 Principle of Least Privilege

Internal access to production systems follows the principle of least privilege. Staff are granted only the minimum permissions required for their role. Access rights are reviewed regularly and revoked promptly upon role change or departure.

5.2 Administrative Access

Multi-factor authentication is required for all administrative access to production systems
Production access is logged and monitored
Direct database access is restricted to authorized personnel via secure bastion infrastructure

5.3 Employee Security

Security awareness training for employees with access to customer data
Background checks conducted for roles with significant access to production systems
Confidentiality agreements signed by all staff

6. Monitoring and Incident Response

6.1 Security Monitoring

Application error rates, anomalous traffic patterns, and authentication failures are monitored continuously
Audit logs record all administrative actions, authentication events, and significant data operations
Automated alerts notify on-call personnel of anomalies

6.2 Incident Response

Lymnus maintains a documented incident response plan covering:

Detection and triage of potential security incidents
Containment and investigation procedures
Communication and escalation paths
Recovery and post-incident review

In the event of a confirmed security incident involving customer personal data, affected customers will be notified within 72 hours of our becoming aware of the incident, as required by GDPR and our Data Processing Agreement.

6.3 Vulnerability Management

Scheduled vulnerability scanning of infrastructure and application components
Penetration testing conducted periodically by internal or third-party security specialists
A responsible disclosure program is available for security researchers at contact@lymnus.com
Critical vulnerabilities are prioritized for remediation within defined SLA windows

7. Business Continuity and Backup

7.1 Backup

Production database: Automated daily backups with point-in-time recovery capability
Backups retained for a minimum of 7 days
Backup data is encrypted and stored in geographically separate S3 buckets
Backup restoration is tested periodically to verify integrity

7.2 Recovery Objectives

Recovery Point Objective (RPO): 24 hours (maximum potential data loss in a worst-case scenario)
Recovery Time Objective (RTO): 4 hours (target time to restore service after a catastrophic failure)

These are operational targets, not contractual guarantees for standard plans. Enterprise SLA contracts may specify enhanced RTO/RPO commitments.

7.3 Disaster Recovery

Critical infrastructure configuration is codified and version-controlled for rapid reproduction
Multi-AZ deployment provides automatic failover for database and application tiers
Runbooks for major failure scenarios are maintained and reviewed periodically

8. Compliance and Certifications

8.1 Data Protection Regulations

GDPR (EU General Data Protection Regulation): Compliance through Privacy Policy, DPA, Data Retention Policy, and technical controls
UK GDPR: Compliance maintained for UK-based customers
CCPA (California Consumer Privacy Act): Rights fulfilled as described in our Privacy Policy

8.2 Payment Card Security

Payment processing is handled entirely by Stripe, which is PCI DSS Level 1 certified. Lemnia LLC does not store, process, or transmit cardholder data. Lymnus's PCI DSS scope is minimal as a result.

8.3 AWS Compliance Inheritance

Lymnus inherits a number of compliance controls from AWS, which holds certifications including ISO 27001, SOC 1/2/3, PCI DSS, and FedRAMP. AWS compliance reports are available to customers under NDA through AWS Artifact.

8.4 Independent Assessments

Lymnus undergoes periodic third-party security assessments. Customers may request a summary of assessment findings under NDA as part of enterprise procurement.

9. Third-Party Security

We evaluate the security practices of critical third-party providers before integration and maintain contractual data protection requirements with all sub-processors. The current list of sub-processors is published in our Data Processing Agreement.

10. Customer Security Responsibilities

While Lymnus secures the underlying platform, customers are responsible for:

Managing team member access and permissions within the Platform
Using strong, unique passwords and enabling two-factor authentication
Securing API tokens and rotating them regularly
Configuring IP Allowlisting to restrict access from unauthorized networks (enterprise)
Reviewing connected app integrations and revoking access when no longer needed
Ensuring data uploaded to the Platform complies with applicable laws and their own security policies

11. Security Questions and Disclosure

For security-related questions, vendor security reviews, or to report a vulnerability, contact:

Security: contact@lymnus.com

Legal / Compliance: contact@lymnus.com

Lemnia LLC

131 Continental Dr, Suite 305, Newark, Delaware 19713, United States

Website: https://lymnus.com

This whitepaper describes Lymnus's security posture. Security controls are continuously reviewed and improved. The latest version of this document is available at https://lymnus.com/legal.