Security Policy.

1.1.Security is a foundational principle at CreateLixir Technologies (“CreateLixir”, “we”, “us”, or “our”). Protecting customer data, safeguarding user accounts, and preserving the integrity of the CreateLixir platform are among the highest priorities of our engineering, operations, and product organisations.

1.2.Security is not an isolated function within CreateLixir. It is embedded across the software development lifecycle, from architectural design and code review through to deployment, monitoring, and incident response. Every product decision is evaluated through a security lens, and every change to the platform is subject to controls designed to preserve confidentiality, integrity, and availability.

1.3.CreateLixir operates on the assumption that threats evolve constantly. We continuously invest in improving our controls, refreshing our tooling, expanding our monitoring surfaces, and strengthening the operational posture of the platform. The practices described in this Policy reflect our current approach and are expected to evolve alongside the industry and the regulatory environment.

1.4.This Policy describes the security posture of the CreateLixir platform, applications, application programming interfaces, and related services (collectively, the “Services”). It applies to every user of the Services and shall be read together with the CreateLixir Privacy Policy, Terms of Service, Billing Policy, and Refund Policy.

The following principles guide the design, operation, and evolution of security at CreateLixir. They inform the trade-offs we make, the controls we implement, and the culture we cultivate across every team.

1. Confidentiality. Customer data is accessible only to those parties that require access for the delivery of the Services. Access is governed by contractual obligations, technical controls, and continuous monitoring.
2. Integrity. Data is protected against unauthorised modification. Changes to customer data are governed by application-level controls, and infrastructure changes are governed by version control, code review, and deployment automation.
3. Availability. The Services are engineered to remain available in the face of routine failures, unusual traffic patterns, and adverse events. Redundancy, graceful degradation, and disciplined operational practices support continued availability.
4. Privacy by Design. Privacy considerations are addressed early in the design process. Data minimisation, purpose limitation, and user control are treated as design constraints, not afterthoughts.
5. Least Privilege. Users, systems, and internal personnel are granted the minimum level of access required to perform their function. Privileges are audited, reviewed periodically, and revoked when no longer required.
6. Secure by Default. Sensible security defaults are applied at every layer of the platform, so that users do not need to opt in to reasonable protection. Users retain the ability to adopt stronger controls where their circumstances require.
7. Continuous Improvement. Security is a practice, not a project. CreateLixir continually reviews its controls, retires legacy approaches, and adopts improved tooling and operational patterns as the landscape evolves.
8. Transparency. Where operationally responsible, CreateLixir communicates openly with customers about our security posture, incidents affecting the Services, and the trade-offs behind our design choices.

3.1.CreateLixir operates on reputable cloud infrastructure providers that are widely recognised for their security posture, operational maturity, and compliance attestations. Underlying hardware, hypervisor, and low-level network security are the responsibility of the cloud provider under the shared-responsibility model. CreateLixir is responsible for the security of the configurations, workloads, and data it deploys on top of that infrastructure.

3.2.Deployments are performed through automated pipelines driven by version-controlled configuration. Manual intervention in production is minimised, and every change is traceable to a code commit, an approved merge, and an executed pipeline run.

3.3.CreateLixir maintains logical isolation between development, staging, and production environments. Access to each environment is separately governed, and production credentials are neither reused across nor present within lower environments.

3.4.Networks are segmented by role, with dedicated segments for application workloads, database systems, background processing, and administrative access. Cross-segment communication is permitted only where required, over authenticated and encrypted channels.

3.5.Infrastructure configuration is subjected to security review during design and continuous inspection during operation. Deviations from the intended baseline are surfaced through monitoring and remediated in accordance with the vulnerability-management practices described in Section 11.

3.6.The Services are engineered to remain available in the face of routine hardware failure. Critical components are deployed with redundancy across availability zones where the cloud provider offers this capability, and the platform is designed to degrade gracefully in the face of partial infrastructure loss.

Encryption is applied at multiple layers of the platform to protect customer information in motion and at rest.

4.1 Encryption in Transit

All communications between the CreateLixir user interface, the CreateLixir application programming interfaces, and the underlying services are encrypted in transit using Transport Layer Security (TLS) 1.2 or higher, with modern cipher suites and forward secrecy enabled. HTTP Strict Transport Security (HSTS) is applied to enforce encrypted connections. Certificates are issued by reputable certificate authorities and are rotated in accordance with industry practice.

4.2 Encryption at Rest

Primary databases, object storage buckets, and backup volumes are encrypted at rest using industry-standard algorithms provided by the underlying cloud infrastructure. Encryption keys are managed through the cloud provider’s key-management services, with rotation policies aligned with vendor recommendations.

4.3 Backup Encryption

Backup snapshots and long-term archives are encrypted at rest and, where transferred across networks, in transit as well. Access to backup data is limited to personnel with an operational need and is subject to the access-control principles described in Section 6.

4.4 Why Encryption Matters

Encryption is not a substitute for other controls, but it is a foundational protection against the loss or disclosure of data in circumstances such as the physical theft of storage media, the interception of network traffic, or the compromise of a peripheral system. CreateLixir treats encryption as one layer in a defence-in-depth strategy.

5.1.CreateLixir authenticates users through a trusted identity provider. Authentication artefacts, including passwords, session tokens, and multi-factor authentication factors, are stored and processed by the identity provider in accordance with industry-standard practices.

5.2.Passwords are never stored in plaintext by CreateLixir or its identity provider. Passwords are hashed using modern algorithms with per-user salts, and are subject to complexity guidance intended to protect against common attacks such as credential stuffing and brute-force enumeration.

5.3.Sessions are governed by short-lived, revocable tokens. Session artefacts are transmitted over encrypted channels, are subject to expiration on idle timeout and on explicit sign-out, and can be revoked centrally in the event of suspected compromise.

5.4.Multi-factor authentication (“MFA”) is supported and strongly encouraged. Users are able to enrol supported factors from their account settings. MFA materially reduces the risk associated with credential-only compromise and is one of the most effective self-service controls available to a user.

5.5.Sign-in attempts are monitored for anomalies. Suspicious activity — including sign-ins from unfamiliar locations, sign-ins across an unusual number of devices, or sign-in patterns consistent with automated attack tooling — may trigger additional verification steps, rate limits, or protective account restrictions.

5.6.Account recovery is offered through verified secondary contact methods. Recovery flows are designed to balance accessibility with resistance to social-engineering attacks, and are subject to progressive verification depending on the sensitivity of the account.

5.7.Devices are treated as first-class subjects. Users may review the sessions and devices associated with their account and revoke access from any device that is no longer trusted.

6.1.Access to the Services and to the customer data processed within them is governed by role-based access control (“RBAC”). Roles reflect the responsibilities of the parties involved and are assigned in accordance with the principle of least privilege.

6.2.Within the product, workspace owners and administrators are able to invite members, assign roles, revoke access, and configure permissions on projects and resources. Role definitions and the associated permissions are documented and refined over time.

6.3.Internal administrative access to production systems is restricted to a small number of authorised personnel with an operational need. Access requires multi-factor authentication, is logged, and is periodically reviewed by the engineering leadership.

6.4.Personnel who no longer require access — whether due to role changes, project completion, or departure from CreateLixir — have their access revoked promptly. Off- boarding is treated as a security-sensitive process and is subject to an explicit checklist.

6.5.Workspaces are logically isolated from one another. Data belonging to one workspace is not accessible to users of another workspace absent an explicit sharing relationship configured within the product.

CreateLixir is designed as an AI-native platform, and the security of AI interactions is treated as a first-class concern. The following practices govern our approach to AI security.

7.1 Protected AI Interactions

Prompts, responses, and intermediate reasoning artefacts are transmitted over encrypted channels and scoped to the user or workspace that originated them. AI interactions are subject to the same workspace-isolation guarantees that govern the rest of the platform.

7.2 Context Isolation

Context provided to an AI agent — including project memory, retrieved documents, and prior conversational turns — is scoped to the workspace and user issuing the request. Context from one workspace is not intermingled with context from another workspace, and users are not exposed to context belonging to workspaces they have not been invited to.

7.3 Secure Prompt Handling

Prompts are validated and normalised prior to submission to underlying models. Where prompts are augmented with retrieved context, that context is itself scoped to the requesting user’s permissions. Sensitive prompt content is not written to unbounded logs, and where logging is required for observability or debugging, it is subject to the same access controls as other customer data.

7.4 Workspace Boundaries

AI agents operate within the boundary of the originating workspace. Actions taken by an agent that affect data — for example, edits to project artefacts or invocations of external systems — are performed with the permissions of the requesting user and are subject to the audit trail described in Section 12.

7.5 AI Request Validation

AI requests are subject to rate limits, abuse detection, and payload validation, in order to prevent denial-of-service, prompt-injection, and other categories of abuse. Anomalous request patterns may be throttled or blocked in accordance with the abuse policies applicable to the Services.

7.6 Responsible AI Processing

CreateLixir is committed to responsible AI processing. We consider the security implications of new AI capabilities during design, and we work to prevent categories of harm — including data leakage across tenants, insecure code generation, and unintended execution of sensitive operations — through a combination of engineering controls, red-team review, and continuous improvement.

8.1.CreateLixir practices data minimisation. We collect only the information required to provide, secure, and improve the Services, and we design new features with the smallest useful data footprint in mind.

8.2.Customer data is stored on secured infrastructure with encryption at rest, network segmentation, and role-based access. Storage systems are subject to the monitoring practices described in Section 12.

8.3.Access to customer data by CreateLixir personnel is restricted, logged, and subject to periodic review. Personnel accessing customer data as part of a support interaction do so only with the customer’s authorisation or as required to investigate an incident affecting the Services.

8.4.Retention of customer data is governed by the CreateLixir Privacy Policy and by contractual obligations undertaken in enterprise agreements. When data is no longer required, it is deleted, anonymised, or rendered irrecoverable through secure procedures.

8.5.Backup copies are retained for the period required for operational recovery, in accordance with the business-continuity practices described in Section 14.

9.1.Traffic entering CreateLixir infrastructure is inspected and filtered at multiple layers, including perimeter firewalls, application-layer filtering, and identity-aware proxies for administrative interfaces.

9.2.All public endpoints are exposed over HTTPS. Legacy cipher suites and insecure transport protocols are disabled. Endpoints handling elevated privileges are subject to additional authentication and network restrictions.

9.3.Application programming interfaces are secured with authentication, request signing where appropriate, and rate limiting. Rate limits protect the Services and their users from abuse, degradation, and denial-of-service conditions.

9.4.CreateLixir benefits from the distributed denial-of-service (“DDoS”) protection provided by our infrastructure and edge providers. Additional application-layer protections are applied against categories of abuse commonly observed against Internet-facing services.

9.5.Internal service-to-service communication is authenticated and encrypted. Service credentials are scoped to their intended use, rotated in accordance with our operational practices, and revoked promptly where compromise is suspected.

10.1.CreateLixir practices a secure software development lifecycle (“SDLC”). Security considerations are incorporated during design, implementation, review, and deployment.

10.2.Engineers are trained in secure coding practices, including protection against injection attacks, cross-site scripting, insecure deserialisation, insecure direct object references, and other categories of vulnerability commonly enumerated by the Open Web Application Security Project (OWASP).

10.3.All code changes are subject to peer review prior to merging into main branches. Reviewers evaluate changes not only for correctness and clarity, but also for security implications, including permission handling, input validation, and error surfaces.

10.4.Third-party dependencies are managed with attention to provenance, licence, and known vulnerabilities. Dependency versions are tracked, updates are applied in accordance with our patching cadence, and vulnerable packages are remediated in accordance with Section 11.

10.5.Security testing is applied at multiple points in the lifecycle, including automated scanning within the build pipeline, targeted testing of new features, and periodic review of critical components.

10.6.Deployments are validated prior to production release. Failed validations block promotion until remediated, and rollback procedures are exercised as part of ongoing operational practice.

11.1.CreateLixir performs security assessments of its platform, its dependencies, and its infrastructure on an ongoing basis. Assessments include automated vulnerability scanning, dependency auditing, and targeted review of high-risk components.

11.2.Identified vulnerabilities are triaged according to their severity, exploitability, and blast radius. Severity is evaluated with reference to widely accepted scoring frameworks and to the specific context of the affected component within the CreateLixir platform.

11.3.Remediation is undertaken on a schedule commensurate with the assessed severity. Critical and high-severity issues are prioritised for expedited remediation, and interim mitigations may be applied where a full patch is not immediately available.

11.4.Patches are applied through the same automated pipelines used for feature deployments, ensuring that security fixes benefit from the same review, testing, and rollback protections as any other change.

11.5.CreateLixir welcomes reports from external researchers under the responsible-disclosure process described in Section 17.

12.1.Production infrastructure is monitored continuously for health, performance, and security signals. Metrics, logs, and traces are collected across the platform to support both operational visibility and incident investigation.

12.2.Application activity relevant to security — including authentication events, permission changes, sensitive configuration updates, and administrative actions — is recorded to an activity log with sufficient granularity to support audit and investigation.

12.3.Threat-detection tooling is applied to network, application, and identity layers of the platform. Alerts are surfaced to the responsible on-call engineers and are triaged in accordance with the incident-response process.

12.4.Access to monitoring data is itself governed by the access-control principles described in Section 6. Sensitive fields are redacted where operational visibility does not require them.

12.5.Performance and capacity metrics are used to identify degradations early, to plan capacity, and to inform the reliability practices described in Section 14.

13.1.CreateLixir maintains an incident-response process intended to detect, contain, remediate, and learn from security and reliability incidents. The process is exercised through drills and refined through post-incident review.

13.2.Detection. Incidents may be detected through automated alerting, user reports, external researcher notifications, or routine operational observation.

13.3.Investigation. Upon detection, an initial responder assesses the scope, severity, and potential impact of the incident, and engages additional personnel as required.

13.4.Containment. Immediate steps are taken to prevent further impact, including but not limited to revoking credentials, isolating affected components, and applying interim mitigations.

13.5.Recovery. Once containment is achieved, affected services are restored to normal operation. Where data has been affected, recovery may involve restoring from backups or replaying validated transactions.

13.6.Communication. Affected customers are notified in accordance with the applicable contractual and legal obligations. Where circumstances permit, CreateLixir communicates the facts, the impact, the remediation, and the preventative measures being adopted.

13.7.Continuous Improvement. Every material incident is subject to a post-incident review focused on identifying contributing factors and implementing durable improvements. The output feeds into engineering priorities, operational runbooks, and, where appropriate, this Policy.

14.1.CreateLixir operates a backup strategy designed to support the recovery of customer data in the event of operational failure, data corruption, or the loss of a primary storage system. Backups are encrypted, segregated from primary storage, and retained for a period appropriate to their purpose.

14.2.Disaster recovery procedures are documented and exercised periodically. Recovery objectives are established for critical components, and improvements are informed by observed exercise outcomes.

14.3.Service availability is supported by redundancy across independent failure domains, graceful degradation for non-critical paths, and capacity headroom to absorb unexpected load.

14.4.Data recovery procedures are validated as part of disaster-recovery exercises. Where an exercise identifies a deviation from expected outcomes, the deviation is treated as an operational bug and remediated.

14.5.Business-continuity planning takes account of the operational, technical, and personnel dimensions of sustained disruption. Roles and responsibilities are defined in advance, and communication procedures are rehearsed as part of ongoing preparedness.

15.1.CreateLixir integrates with a curated set of trusted third-party providers, including cloud infrastructure, identity, payment processing, communications, and analytics services. Third-party providers are selected with attention to their security posture, operational maturity, and privacy practices.

15.2.Prior to onboarding, third parties are subject to a security evaluation appropriate to the sensitivity of the integration. Ongoing relationships are subject to periodic review, and adverse events involving third parties are treated as inputs into the CreateLixir incident-response process.

15.3.Privacy considerations are addressed during vendor selection, including the categories of data shared, the purposes for which it is shared, the applicable legal basis, and the safeguards provided by the vendor.

15.4.Service reliability of critical third parties is monitored, and dependencies are diversified where operationally feasible in order to reduce the impact of any single-vendor failure.

Security is a shared responsibility. While CreateLixir is responsible for the security of the platform we operate, customers play an essential role in the security of their accounts, their workspaces, and the data they entrust to the Services. Customers are encouraged to:

1. use strong, unique passwords for the CreateLixir account and avoid reuse across services;
2. enable multi-factor authentication where available, and secure the associated devices with a screen lock and up-to-date operating system;
3. protect application programming interface keys and other credentials issued by CreateLixir; keys should be treated as secrets, rotated periodically, and never committed to public repositories;
4. review workspace membership and permissions periodically, and remove access that is no longer required;
5. report suspicious activity — including unexpected sign-ins, unfamiliar sessions, and unauthorised changes to workspaces — to CreateLixir promptly;
6. keep account information, including the registered email address and recovery contact details, accurate and current so that CreateLixir can reach you in the event of a security matter; and
7. keep browsers, operating systems, and any related developer tooling up to date, as a substantial portion of real-world compromise originates in end-user devices rather than in the platform itself.

17.1.CreateLixir welcomes reports of potential security issues from security researchers, customers, and the broader community. Responsible disclosure is an important part of maintaining a secure platform, and we appreciate the contribution of researchers who work with us in good faith.

17.2.Reports may be submitted to security@createlixir.com and should include, where possible, a description of the issue, the steps required to reproduce it, the affected components, the potential impact, and any supporting artefacts such as screenshots or proof-of- concept code.

17.3.Researchers acting in good faith are expected to:

1. avoid actions that could harm the availability, integrity, or confidentiality of the Services or of other users;
2. avoid accessing, modifying, or exfiltrating data that does not belong to the researcher;
3. refrain from disclosing the issue publicly until CreateLixir has had a reasonable opportunity to investigate and remediate;
4. comply with applicable laws and regulations; and
5. engage constructively with CreateLixir during the investigation and remediation of the reported issue.

17.4.CreateLixir shall acknowledge receipt of good-faith reports within a reasonable time and shall communicate the status of the investigation, the remediation, and the disclosure timeline as circumstances permit.

18.1.Security is a moving target. The threats we face, the tools available to us, and the expectations of our customers evolve over time, and this Policy will evolve with them.

18.2.CreateLixir may amend, modify, or update this Policy from time to time. The “Last Updated” date at the top of this Policy reflects the most recent revision. Material changes shall be communicated by reasonable means, including by posting the revised Policy on the CreateLixir website and, where appropriate, by direct notice to affected users.

18.3.Continued use of the Services following the effective date of any amended Policy shall constitute the user’s acceptance of the amended Policy. Users who do not agree with the amended Policy may discontinue use of the Services in accordance with the Billing Policy.

For any security concern relating to the CreateLixir platform — including suspected account compromise, responsible-disclosure reports, security questions, and privacy concerns — please contact the CreateLixir security team. We shall acknowledge and respond within a reasonable time, taking into account the urgency and complexity of the matter raised.