English

简体中文

English

简体中文

9.6 BioLine Supplementary Regulations for Data Protection ​

Data security is a very important issue in computing. We invest heavily in data security for two reasons. First, the BioLine platform is a cloud-computing platform that processes many types of data, including genomic data, using existing tools and adds AI-agent capabilities; it involves various types of data relating to individuals, so the value of user data and personal privacy are especially important. Second, BioLine is built on cloud servers provided by cloud partners, where, in addition to important data, the analysis flows, technical results, and commercial value created by different organisations and users all need protection. BioLine is therefore designed and built to very strict security and privacy requirements. This document describes the security measures adopted while building the BioLine platform to ensure a high level of security and to implement the user permission-control system.

1. Regulatory Policy for Special Data ​

For the relatively special category of genomic data, we note that although several frameworks and regulations for genomic data exist (such as HIPAA, CLIA, and ISO/IEC 27001), they do not fully cover the specific requirements for processing genomic data on cloud platforms. In designing and developing BioLine, we strictly follow the principles and spirit of these regulations and comply with the currently effective laws of the People's Republic of China, including the Data Security Law, the Personal Information Protection Law, the Biosecurity Law, the Regulations on the Administration of Human Genetic Resources, the Measures for the Administration of Scientific Data, and, for AI services, the Interim Measures for the Administration of Generative AI Services.

2. Approach Adopted ​

BioLine's security design spans the infrastructure level, the business-logic level, and the AI-agent security level. At the infrastructure level, we integrate security measures widely used in the cloud-computing industry, including data encryption, identity authentication, API rate limiting, VPC protection, firewall protection, and vulnerability protection. At the business-logic level, the focus is to provide business logic that is both easy to manage and well protected, while supporting collaboration and permission management among users and keeping datasets and workflows secure; to this end we use de-identified objects, fine-grained access control, and file-sharing mechanisms. At the AI-agent security level, an architecture of "separation of orchestration and execution, with boundary isolation" ensures the large model does not access raw data and the downstream execution environment is controlled and isolated. The following uses a partner cloud provider as an example.

3. Infrastructure Level ​

3.1 Encryption. On BioLine, all information processed by the system is encrypted both in transit and at rest. For data in transit, there is no link within the system that allows unencrypted transfer, and links with an encryption option (such as HTTPS) are forced to use SSL/TLS. "At rest" corresponds to several storage states, including temporary compute storage, first-layer caches, and object storage, all encrypted server-side by default using the industry-standard AES256 algorithm. When data is no longer used at a specific location, or an authorised user decides to delete it, the data is securely erased according to industry erasure standards to ensure data security.

3.2 Authentication. Cloud authorisation follows the best practices advocated by the cloud provider and uses strict key authentication. At the system level, users authenticate with a username and password; upon successful authentication, a time-limited temporary token is generated for short-term system access and securely stored, reducing the possibility of gaining access by brute force.

3.3 API rate limiting. All access to the system (including front-end web operations) is via APIs, and each user's access to system APIs is subject to a maximum rate limit, limiting the possibility of malicious users tampering with the system through denial-of-service attacks.

3.4 VPC protection. BioLine's cloud server instances run in a virtual private cloud (VPC), providing a dedicated virtual network environment logically isolated from the rest of the cloud, with private IP ranges, subnets, route tables, and gateways.

3.5 Firewall protection. BioLine uses cloud security groups as virtual firewalls controlling inbound and outbound network traffic; each instance is associated only with the necessary security groups, and different security-group rules provide fine-grained control over inter-instance communication.

3.6 Vulnerability protection. BioLine uses some third-party open-source libraries and software; the team takes proactive action, conducts regular vulnerability assessments, promptly remediates detected risks, and actively follows the cloud provider's security guidance to improve vulnerability protection.

4. Business-Logic Level ​

4.1 Object de-identification. Every entity in the BioLine system is represented by a 128-bit UUID. A UUID cannot reveal an entity's information (such as a file's name, metadata, owner, creation date, or project). BioLine uses only an extremely sparse subset of all possible values, so users cannot realistically obtain information about other users or projects by guessing or deriving UUIDs.

4.2 Fine-grained access control. Access control on BioLine is highly granular, with six permission types—Manage, Upload, View, Modify, Run, and Share—that can be set separately for each user on each project. Files are grouped by project, and each project member may hold different permissions, ensuring users can only access information relevant to their work; permissions also cover intra-group data sharing.

5. AI-Agent Security Level ​

For the new AI-agent capabilities, BioLine adopts a security design of "separation of orchestration and execution, with boundary isolation":

  • Orchestration-data separation: the large model acts only as an orchestrator that understands needs, plans steps, and tracks progress; it does not access raw sequencing data and does not enter the compute environment to execute arbitrary code.
  • Execution isolation: customised downstream analysis runs in local containers that default to --network none (no external network) and --cap-drop ALL (no extra privilege escalation); stage/ is mounted read-only to the downstream to prevent write-back contamination of upstream outputs; container memory, CPU, and GPU resources are controlled, and containers are destroyed after the job.
  • Minimum-necessary transmission: when invoking a (proprietary or third-party) large model, only the natural-language instructions, orchestration information, and necessary metadata required to complete the task are transmitted; raw sequencing data does not enter the model.
  • Credential protection: AccessKey and AccessSecret are used only for login authentication and are not written into repository files, Job directories, or parameter-override files or other persistent materials.
  • Audit and traceability: upstream specs and plans, polling status traces, Skill snapshots, AI-customised scripts, and execution logs are all retained, ensuring the analysis process is traceable and results reproducible, and supporting auditing of AI-generated content and prompts.