Legal

Security Policy

Last updated  ·  May 2025

Security Policy

Last Updated: May 2, 2026  ·  Effective Date: May 2, 2026

1. Our Security Commitment

At Lost Boy Graphics, security is not an afterthought — it is a foundational design principle of the Axelis platform. We process sensitive data on your behalf: AI conversation histories, OAuth tokens granting access to your social media accounts, Google Suite data, and more. We take the responsibility of protecting that data seriously.

This Security Policy describes the technical and organizational measures we have implemented to protect your data. We are transparent about our current security posture and our roadmap for continued improvement.

🔒

Encryption Everywhere

Data is encrypted in transit using TLS and at rest using AES-256. No unencrypted sensitive data leaves our systems.

👤

Least Privilege Access

Internal access to user data is limited to personnel who require it for their job function. All access is logged.

🔍

Continuous Monitoring

We monitor our systems for anomalous activity, security events, and potential breaches around the clock.

Secure Development

Security is considered at every stage of the software development lifecycle, from design through deployment.

2. Encryption in Transit

All communication between your device and the Axelis platform — and between Axelis and its service providers — is encrypted in transit using industry-standard protocols:

TLS Configuration

  • Protocol version: TLS 1.2 (minimum) and TLS 1.3 (preferred). Older, insecure protocols (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) are disabled.
  • Cipher suites: Only strong cipher suites are enabled. Weak ciphers (RC4, 3DES, export-grade ciphers) are disabled.
  • Certificate management: We use certificates from trusted Certificate Authorities (CAs). Certificates are rotated before expiry. HSTS (HTTP Strict Transport Security) is enabled with long max-age values to prevent downgrade attacks.
  • Perfect Forward Secrecy (PFS): Enabled using ECDHE key exchange, ensuring past communications cannot be decrypted if a long-term key is ever compromised.

HTTPS Enforcement

All HTTP requests to axelis.ai and its subdomains are automatically redirected to HTTPS. HSTS headers prevent browsers from making non-encrypted connections. Our HSTS policy includes the includeSubDomains and preload directives.

API Communications

All API calls between Axelis and third-party providers (Anthropic, OpenAI, Supabase, Stripe, Google APIs, social platform APIs) are made exclusively over TLS-encrypted connections. We verify SSL certificates for all outbound connections and reject invalid or self-signed certificates.

3. Encryption at Rest

Data stored by Axelis is encrypted at rest using AES-256, which is the same encryption standard used by government agencies and financial institutions worldwide.

Database Encryption

Our primary database (Supabase/PostgreSQL) uses transparent data encryption (TDE) at the storage level. Encryption keys are managed by Supabase's key management infrastructure and are not stored alongside the data they encrypt.

File Storage Encryption

User-generated content (images, video files, documents) stored in object storage is encrypted at rest using AES-256. Access to stored objects requires authenticated, time-limited signed URLs.

Backup Encryption

All database backups are encrypted using the same AES-256 standard before being stored. Backup storage is isolated from the primary data environment and is access-restricted.

Sensitive Field Encryption

Particularly sensitive data fields — including OAuth access tokens, refresh tokens, and API keys stored on behalf of users — are encrypted at the application layer using AES-256 in addition to the database-level encryption, providing defense in depth. This means the data is encrypted twice: once at the application layer and once at the storage layer.

4. Authentication & Access Control

User Authentication

  • Password hashing: Passwords are hashed using bcrypt with a work factor appropriate for current computational capabilities. Plaintext passwords are never stored or logged anywhere in our system.
  • Multi-Factor Authentication (MFA): MFA is available and strongly recommended for all accounts. Enterprise plan users may be required to enable MFA by their organization's policy.
  • Session management: Sessions use signed JWT tokens with short expiration times (1 hour for access tokens, 60 days for refresh tokens). Sessions can be invalidated remotely from your account settings.
  • OAuth for connected accounts: We use OAuth 2.0 industry-standard flows for all third-party account connections. We request only the minimum scopes necessary for the features you use.
  • Rate limiting: Authentication endpoints are rate-limited to prevent brute-force attacks. Accounts are temporarily locked after repeated failed login attempts, with notifications sent to the account owner.

Internal Access Controls

  • Access to production systems and user data is restricted on a strict need-to-know, least-privilege basis.
  • All internal access to sensitive systems requires MFA.
  • Internal access is logged and auditable. Access logs are retained for 90 days.
  • Access privileges are reviewed periodically and revoked immediately upon role changes or separation from the company.

5. API Key & Secret Management

Axelis integrates with numerous third-party APIs. Proper management of API keys and secrets is critical to platform security.

Third-Party API Key Storage

  • API keys for services like Anthropic, OpenAI, Replicate, RunwayML, and others are stored as encrypted environment variables in our deployment environment, never hardcoded in source code.
  • These keys are never exposed to users or included in client-side code bundles.
  • API keys are rotated on a regular schedule and immediately upon any suspected compromise.

User-Provided API Keys

If users provide their own API keys for certain integrations, those keys are:

  • Stored encrypted at rest using AES-256 application-layer encryption
  • Never logged in plaintext in application logs or error reports
  • Transmitted only over TLS-encrypted connections
  • Accessible only to the account that owns them and to the systems necessary to use them
  • Deletable at any time from your account settings

OAuth Token Security

OAuth access and refresh tokens for connected accounts (Twitter, Google, Meta, etc.) are treated as highly sensitive credentials:

  • Stored with application-layer AES-256 encryption in addition to database-level encryption
  • Used only for the purposes you authorized and never shared with other users or third parties
  • Revoked and deleted immediately when you disconnect an account
  • Revoked and deleted within 30 days of account deletion

6. Third-Party Security

Axelis relies on a carefully selected set of third-party providers. We evaluate each provider's security posture before integration and maintain data processing agreements with all providers who handle personal data.

ProviderRoleKey Security Features
Supabase Database & Authentication SOC 2 Type II, AES-256 at rest, TLS in transit, row-level security policies, GDPR-compliant
Stripe Payment Processing PCI-DSS Level 1, tokenized card data, fraud detection, never shares raw card data
Anthropic AI Inference (Claude API) Enterprise-grade security, data processing agreements, no training on API data by default
OpenAI AI Inference SOC 2 Type II, data processing agreements, enterprise data privacy protections
Replicate Image/Video Generation Encrypted transit, data processed in secure containers, model outputs not shared across users
RunwayML AI Video Generation TLS encryption, enterprise data handling terms available
Google Cloud OAuth Provider / API ISO 27001, SOC 2/3, FIPS 140-2 encryption, comprehensive audit logging

We conduct periodic reviews of our third-party providers' security documentation, compliance certifications, and data processing agreements. If a provider's security posture materially degrades, we will evaluate alternatives.

7. Application Security

Secure Development Practices

  • Code reviews: All code changes undergo review before deployment. Security-sensitive changes receive additional scrutiny.
  • Dependency management: Third-party dependencies are monitored for known vulnerabilities using automated scanning tools. Critical vulnerabilities are patched promptly.
  • OWASP Top 10: Our development practices address the OWASP Top 10 most common web application vulnerabilities, including injection attacks, broken authentication, cross-site scripting (XSS), and others.

Input Validation & Output Encoding

  • All user inputs are validated and sanitized before processing.
  • SQL queries use parameterized statements to prevent SQL injection.
  • Output is properly encoded to prevent cross-site scripting (XSS) attacks.

Cross-Site Request Forgery (CSRF)

All state-changing API endpoints require CSRF tokens. We use SameSite cookie attributes and Origin header validation to provide additional layers of CSRF protection.

Content Security Policy (CSP)

We implement strict Content Security Policy headers to limit the sources from which the Axelis web application can load resources, reducing the risk of cross-site scripting and data injection attacks.

Rate Limiting

API endpoints are rate-limited to prevent abuse, credential stuffing, and denial-of-service attacks. Rate limits are applied per IP address and per authenticated user account.

8. Infrastructure Security

  • Network segmentation: Production, staging, and development environments are isolated from each other. Database servers are not publicly accessible; they accept connections only from application servers within the same private network.
  • Firewalls: Network-level firewall rules restrict inbound and outbound traffic to only what is necessary for the Service to function.
  • Secrets management: Secrets, credentials, and configuration values are managed via environment-specific secret stores and are never committed to version control systems.
  • Logging and monitoring: We maintain security event logs for all production systems. Anomaly detection alerts notify our team of suspicious activity in real time.
  • Patching: Operating system and software patches are applied promptly. Critical security patches are applied within 24–72 hours of release.
  • Backups: Regular automated backups are performed and tested for restorability. Backups are stored in a separate, access-controlled environment.

9. Vulnerability Disclosure

We welcome security researchers who identify potential vulnerabilities in the Axelis platform. We are committed to working with the security community to make Axelis safer for everyone.

Responsible Disclosure Guidelines

If you believe you have found a security vulnerability in Axelis:

Report the vulnerability to us privately

Email elijahgreen@lostboygraphics.com with the subject line "Security Vulnerability Report." Include a clear description of the vulnerability, steps to reproduce, and the potential impact.

Allow us time to investigate and remediate

We ask for a minimum of 90 days to investigate and remediate the issue before public disclosure. We will acknowledge your report within 5 business days and keep you informed of our progress.

Do not access or modify user data

During your testing, do not access, modify, delete, or exfiltrate other users' data. Test only with accounts you own. Do not perform denial-of-service testing or social engineering attacks.

Coordinate on public disclosure

We will coordinate with you on the timing and content of any public disclosure. We will credit you for your discovery (unless you prefer to remain anonymous).

In Scope: axelis.ai and all subdomains, Axelis mobile applications, Axelis API endpoints. Out of Scope: Third-party services we use (Supabase, Stripe, Google, etc.) — report those directly to those providers. Social engineering, physical security attacks, and denial-of-service testing are also out of scope.

We do not currently offer a monetary bug bounty program, but we do offer our sincere thanks, public credit (if desired), and a commitment to treat all good-faith reporters with respect. We will not pursue legal action against researchers who follow these responsible disclosure guidelines.

10. Incident Response

We maintain an incident response plan for security events. Our response process follows industry best practices:

PhaseActivitiesTimeline
Detection & Triage Identify and confirm the incident, assess severity and scope, activate response team Within 1 hour of detection
Containment Isolate affected systems, revoke compromised credentials, implement emergency controls to limit damage Within 4 hours of detection
Eradication Identify and eliminate root cause, remove malicious artifacts, patch vulnerabilities exploited Within 24–72 hours
Recovery Restore affected systems from clean backups, verify integrity, gradually restore services Based on incident severity
Notification Notify affected users and, where required by law, relevant regulatory authorities Within 72 hours of confirmed breach (GDPR requirement)
Post-Incident Review Root cause analysis, documentation, process improvements, prevention of recurrence Within 2 weeks of resolution

User Notification

In the event of a security incident that affects your personal data, we will notify you via email at your registered address within 72 hours of confirming the breach (or as required by applicable law). Our notification will include:

  • A description of the nature of the breach
  • The categories and approximate number of individuals affected
  • The likely consequences of the breach
  • The measures we have taken or propose to take to address the breach
  • Steps you can take to protect yourself

11. Compliance & Certifications

As a growing company, our compliance posture reflects our current size and the trajectory of our security program:

Standard / FrameworkStatusNotes
GDPR (EU Data Protection) Active Privacy Policy, Data Processing Agreements, and data subject rights processes in place
CCPA / CPRA (California) Active Consumer rights request processes implemented
Meta Platform Data Policy Active Data deletion instructions URL and user data handling requirements met
OWASP Security Practices Active Development practices aligned with OWASP Top 10
SOC 2 Type I In Progress Targeted for 2026. We are building toward SOC 2 readiness, including evidence collection and control implementation.
SOC 2 Type II Aspirational Target: 2027. Full audit covering a minimum 6-month observation period.
ISO 27001 Aspirational Long-term goal aligned with enterprise customer requirements.

Enterprise customers who require specific compliance documentation, security questionnaires, or penetration test reports should contact elijahgreen@lostboygraphics.com. We will provide available documentation under NDA where applicable.

12. Security Contact

For security-related inquiries, vulnerability reports, or security documentation requests:

For general privacy and data protection inquiries (not security vulnerabilities), refer to our Privacy Policy contact section.

We take all security reports seriously and will acknowledge your message within 5 business days. Our security team is committed to investigating and addressing all credible reports promptly.