MinT Security & Compliance Whitepaper

Mind Lab Toolkit

Service Provider: MINDAI PTE. LTD.

Version: v2.0

Published: July [ ], 2026

Effective: [ ], 2026

[PLEASE READ CAREFULLY] This Security & Compliance Whitepaper (the "Whitepaper") describes the technical and organisational security measures adopted by MINDAI PTE. LTD. ("Mindai", "we", "us") for MinT (Mind Lab Toolkit) as at the publication date set out above. This Whitepaper is intended to assist Enterprise Customers, their security teams, and their counsel in conducting vendor security assessments. It is informational in nature and does not, of itself, constitute a contractual commitment. Contractual security commitments are set out in the MinT Terms of Service, the Data Processing Agreement ("DPA"), and applicable order forms.

[FORWARD-LOOKING STATEMENTS] Items identified in this Whitepaper as "on the roadmap", "planned", or "under development" reflect Mindai's current intentions as at the publication date and are subject to change. Customers should not rely on such items in making purchasing decisions and should confirm the then-current status of any such item with Mindai at the time of engagement.

Article 1 — Introduction and Scope

MinT is an AI platform provided by Mindai comprising two independent components: (a) the "Training Platform" — a reinforcement-learning infrastructure for the training, fine-tuning, and evaluation of machine-learning model weights ("Training Outputs"), with outputs consisting of model parameters rather than user-facing content; and (b) the "Model Gateway" — providing API access to Macaron model series and third-party open-source models (such as DeepSeek, GLM, etc.) for the Customer's own AI business purposes. This Whitepaper describes the security architecture, controls, and governance practices Mindai applies to both components of MinT and to Customer Data processed on the platform.

Unless otherwise defined, capitalised terms used in this Whitepaper have the meanings given to them in the MinT Terms of Service and the MinT Privacy Policy.

Article 2 — Mindai's Security Commitment

Mindai's security programme is built on four principles:

• Customer Data ownership — Customer Data belongs to the Customer. Mindai processes Customer Data only for the purpose of providing the Service and in accordance with the Customer's documented instructions.

• Defence in depth — security controls are applied at the physical, network, host, application, data, and identity layers, such that compromise of any single layer does not result in the compromise of Customer Data.

• Least privilege — access to Customer Data by Mindai personnel is limited to a narrowly scoped set of roles, granted on a just-in-time basis, logged, and reviewed.

• Transparency — Mindai publishes its security posture (this Whitepaper), its Subprocessor list, and its incident-notification practices, and makes available summary reports of third-party audits to Enterprise Customers upon request under confidentiality.

Article 3 — Security Governance

Security at Mindai is owned by the Head of Security, who reports to executive management and is responsible for the design, implementation, operation, and continuous improvement of the information security management system (ISMS). The Head of Security is supported by a dedicated security function covering security engineering, security operations, governance-risk-compliance (GRC), and incident response.

Mindai maintains a written information-security policy framework, approved and reviewed by executive management, covering the domains listed in ISO/IEC 27001:2022 Annex A. Policies are reviewed at least annually, and upon material change to the Service, threat landscape, or applicable law. All personnel with access to Customer Data are required to acknowledge the policy framework as a condition of access.

Mindai operates a risk-management process aligned with ISO/IEC 27005. Risks are identified, assessed (impact × likelihood), treated (accept, mitigate, transfer, avoid), and tracked in a central risk register. Material risks are escalated to executive management on a quarterly cadence.

Article 4 — Certifications and Compliance Standards

4.1 Current Certifications

Mindai has obtained the following certifications as at the publication date of this Whitepaper:

• Classified Protection of Cybersecurity, Level 3 (PRC MLPS 2.0, "等保三级") — assessed against GB/T 22239-2019 by an accredited assessment body and filed with the competent public-security authority. The MLPS Level 3 scheme is the PRC national baseline for information systems processing important information and serving a significant user base.

4.2 Standards Alignment

Notwithstanding the current certification portfolio, Mindai's security programme is designed to be consistent with the following international standards and frameworks:

• ISO/IEC 27001:2022 (Information Security Management Systems) — Annex A control set;

• ISO/IEC 27701:2019 (Privacy Information Management) — controls for data controllers and processors;

• ISO/IEC 27017:2015 (Cloud Service Information Security);

• ISO/IEC 27018:2019 (Protection of PII in Public Clouds Acting as PII Processors);

• NIST Cybersecurity Framework (CSF) 2.0 — Identify, Protect, Detect, Respond, Recover, Govern;

• NIST SP 800-53 (Security and Privacy Controls) and NIST SP 800-63B (Digital Identity);

• Cloud Security Alliance Cloud Controls Matrix (CSA CCM) v4.

4.3 Roadmap

The following certifications are currently on Mindai's compliance roadmap. Indicative target windows are provided below; Customers should confirm current status at the time of engagement.

• ISO/IEC 27001:2022 certification — target window: [TBD];

• SOC 2 Type II report (security, availability, confidentiality criteria) — target window: [TBD];

• ISO/IEC 27701:2019 certification (privacy extension) — target window: [TBD].

4.4 Independent Audits

Mindai engages qualified independent third parties to conduct security assessments, including at least annual application-level penetration tests against the MinT Platform Layer. Material findings are tracked to closure in Mindai's vulnerability-management workflow. Summary reports are available to Enterprise Customers upon request under appropriate confidentiality undertakings.

Article 5 — Shared Responsibility Model

Security of the MinT service is a shared responsibility between Mindai, the Customer, and (where applicable) Mindai's IaaS-Layer Subprocessors. The following table summarises the allocation of responsibilities; it is illustrative and does not replace the allocation set out in the Terms of Service, the DPA, or applicable order forms.

Article 6 — Data Protection

6.1 Data Ownership

Customer Data belongs to the Customer. As between Mindai and the Customer, the Customer retains all right, title, and interest in and to Customer Data, Training Data, and Training Outputs. Mindai processes Customer Data as a data processor (PDPA "data intermediary"; GDPR "processor"; PIPL "受托人") only on the documented instructions of the Customer and solely for the purpose of providing the Service, as set out in the DPA.

Mindai does not use Customer Data, Training Data, or Training Outputs to train, fine-tune, or evaluate Mindai's own models, and does not disclose such data to any third party except to authorised Subprocessors as set out in the Subprocessor list and under equivalent written obligations.

6.2 Multi-Tenant Isolation

MinT implements logical isolation between tenants at the control-plane, orchestration, storage, and metadata layers, such that one tenant cannot access or enumerate the resources, data, or training artefacts of another tenant. Isolation is enforced through tenant-scoped identifiers, tenant-scoped cryptographic material, and authorisation checks at every API boundary.

For Enterprise Customers with heightened isolation requirements, private deployment (see Article 16) is available, under which Customer workloads run on infrastructure dedicated to, and under the administrative control of, the Customer.

6.3 Data Residency

The location at which Customer Data is stored and processed is determined by the deployment mode selected by the Customer:

• Cloud deployment: Customer Data is stored and processed on mainland-China nodes of licensed cloud-service providers engaged by Mindai. Customer Data of cloud-deployment customers is not, in the ordinary course of operation, transferred outside the People's Republic of China.

• Private / on-premises deployment: Customer Data is stored and processed on infrastructure controlled by the Customer. The Customer determines the location of, and is responsible for any cross-border movement of, such Customer Data.

The current list of Subprocessors, including the identity and location of cloud-service providers for cloud-deployment customers, is maintained on the Subprocessor Page and is also available to Enterprise Customers on request. See also the MinT Privacy Policy, Article 9.

6.4 Encryption

Mindai applies end-to-end encryption to Customer Data across the storage, compute, and network planes, consistent with the following standards:

• Encryption in transit: TLS 1.2 or higher for all client-to-service and service-to-service communications over public networks. Control-plane APIs support TLS 1.3 and modern cipher suites; legacy protocols (SSLv2/v3, TLS 1.0/1.1) are not accepted.

• Encryption at rest: AES-256 (or equivalent) for Customer Data stored in object storage, block storage, and managed databases operated by the MinT Platform Layer.

• Encryption of sensitive platform-internal material: service-to-service authentication tokens, secrets, and credentials are stored in a dedicated secrets-management system with access controls and audit logging.

6.5 Key Management

Cryptographic keys used to protect Customer Data at rest are managed in a key-management service (KMS) operated by Mindai's IaaS-Layer Subprocessor, with separation between key-administration and key-use privileges. Customer-managed keys (BYOK / CMEK) for cloud-deployment customers are on Mindai's product roadmap. For private-deployment customers, the Customer controls the key-management infrastructure in its own environment.

6.6 Backup and Deletion

Customer Data is backed up on a regular cadence consistent with Mindai's business-continuity objectives (see Article 13). Backups inherit the same encryption, access-control, and isolation properties as production data.

On termination of the Service or upon the Customer's documented deletion instruction, Customer Data is deleted from production systems within the time frame set out in the DPA, followed by deletion from backup systems in the ordinary course of backup rotation. Upon request, Mindai will provide written confirmation of deletion.

Article 7 — Identity and Access Management

7.1 Native Account System

MinT provides a native account system supporting strong password policies (length, complexity, history, and age), account lockout on repeated failed login, session timeout, and detection of anomalous sign-in (e.g., unusual geolocation or impossible-travel).

7.2 Multi-Factor Authentication (MFA)

MinT supports multi-factor authentication for user sign-in, protecting against credential compromise from phishing, password reuse, and brute-force attacks. Customers are strongly recommended to enforce MFA for all users with administrative privileges or access to sensitive resources.

7.3 Single Sign-On (SSO)

MinT does not, at v2.0, provide a standardised out-of-the-box SSO integration in the cloud-deployment product. Customers requiring SSO — including integration with enterprise identity providers such as SAML 2.0, OIDC, DingTalk, Feishu, WeCom, Microsoft Entra ID (Azure AD), or Okta — may obtain such integration as part of a private-deployment engagement, under which SSO can be custom-configured against the Customer's identity provider. Standardised SSO for cloud-deployment is on Mindai's product roadmap.

7.4 Role-Based Access Control (RBAC)

Within an Enterprise Customer's tenant, administrators may define roles and assign granular permissions over projects, training jobs, datasets, model artefacts, and billing resources. Roles follow the principle of least privilege and support segregation of duties.

7.5 Privileged Access (Mindai Personnel)

Access by Mindai personnel to production systems containing Customer Data is restricted to a narrowly scoped set of roles, granted on a just-in-time basis via an internal privileged-access-management (PAM) system, subject to MFA, session recording, and time-bounded approval. All privileged-access sessions are logged and subject to periodic review.

7.6 API-Key Management

Programmatic access to MinT is authorised via API keys issued under the Customer's control. API keys may be scoped to specific projects, permissions, and IP-address ranges, and may be rotated or revoked at any time by the Customer.

Article 8 — Network Security

8.1 Architecture

The MinT Platform Layer is deployed across segmented network zones — public-facing API ingress, application tier, data tier, and management tier — with strict firewall rules between zones and default-deny inter-zone traffic. Public-facing endpoints are fronted by a content-delivery network and web-application firewall, with rate-limiting, IP reputation filtering, and traffic anomaly detection.

8.2 DDoS Protection

MinT inherits volumetric and protocol-level DDoS protection from its IaaS-Layer Subprocessors, with network-layer mitigation capacity in excess of the scale of common denial-of-service events. Application-layer rate limits are enforced at the API gateway.

8.3 Administrative Access

Administrative access to production systems is only permitted through bastion hosts protected by MFA, mutual TLS, and source-IP allow-listing. Direct SSH or RDP to production hosts from the public internet is not permitted.

8.4 Network Segmentation and Egress

Compute workloads running Customer training jobs execute in segmented network environments with restricted egress. Egress endpoints are controlled via allow-lists to prevent data exfiltration through unintended network channels.

Article 9 — Application Security

9.1 Secure Software Development Lifecycle

Mindai follows a secure software-development lifecycle (SSDLC) that integrates security review at design, implementation, testing, and deployment stages. Requirements include threat modelling for new features, peer code review on all merges, automated static application security testing (SAST), dependency-vulnerability scanning (SCA), and container-image scanning.

9.2 Vulnerability Management

Mindai maintains a vulnerability-management programme that triages findings from internal tooling, independent penetration tests, and responsible-disclosure reports. Severity is assessed using CVSS v3.1, and remediation is tracked to closure within time frames aligned with severity (critical within a matter of days; high within weeks; medium and low within the ordinary release cadence).

9.3 Third-Party Penetration Testing

Mindai engages qualified independent third parties to conduct application-level and infrastructure-level penetration tests against the MinT Platform Layer at least annually, and following material architectural changes. Summary reports are available to Enterprise Customers under confidentiality on request.

9.4 Responsible Disclosure

Security researchers who identify vulnerabilities in MinT are invited to report such vulnerabilities to contact@mindlab.ltd. Mindai will acknowledge receipt of valid reports, coordinate remediation, and will not pursue legal action against researchers who act in good faith, respect Customer privacy, and comply with Mindai's responsible-disclosure guidance.

Article 10 — AI-Specific Security

10.1 Training-Data Isolation

Training Data uploaded by a Customer is stored and processed in tenant-scoped storage, with access restricted to the uploading Customer's tenant. Training jobs are executed in tenant-scoped compute environments; no Training Data of one Customer is accessible to another Customer's training jobs at the data, memory, or artefact level.

10.2 Training-Data Desensitisation and Minimisation

MinT supports — and where reasonably practicable, encourages — Customers to perform desensitisation and minimisation of Training Data prior to upload, in a manner consistent with applicable data-protection law. Mindai's technical guidance and platform controls are designed in alignment with the following frameworks:

• ISO/IEC 27018:2019 — controls for the protection of Personally Identifiable Information (PII) in public clouds acting as PII processors;

• GDPR Article 25 — Data Protection by Design and by Default;

• GDPR Article 32 — Security of Processing, including pseudonymisation and encryption;

• PIPL Article 51 — obligations on personal-information processors to adopt technical measures such as de-identification and encryption.

10.3 Model-Weight Protection

Training Outputs — the model weights produced by Customer training jobs — are treated as Customer Confidential Information. Model weights are stored in tenant-scoped encrypted storage, access-controlled to the Customer's tenant, and are not made available to other Customers, to Mindai personnel outside narrowly scoped support scenarios, or to third parties, except as directed by the Customer (for example, pursuant to the Customer's documented export or download instruction).

10.4 No Use of Customer Data for Mindai Model Training

Mindai does not use Customer Data, Training Data, prompts, or Training Outputs to train, fine-tune, benchmark, or evaluate any model operated for Mindai's own purposes or any model made available to third parties. This commitment is also reflected in the MinT Terms of Service and the DPA.

10.5 Output-Integrity Controls

For the MinT Training Platform, outputs are model parameters, not user-facing content; accordingly, content-moderation controls that would be applicable to a generative-content service (such as output classifiers or prompt-injection defences at an end-user content level) are not features of the Training Platform. Customers who subsequently deploy Training Outputs to generate end-user content are responsible for implementing appropriate safety, moderation, and compliance controls in their downstream systems. For the MinT Model Gateway, Mindai performs safety validation on Inputs at the API gateway layer and applies output guardrails commensurate with the capabilities of the invoked model (see Section 10.7); however, ultimate responsibility for content compliance of Model Gateway Outputs remains with the Customer, who is responsible for assessing whether such Outputs satisfy the content-moderation and generative-AI compliance requirements applicable in the Customer's jurisdiction of deployment.

10.6 Deployment-Support Assistance for Downstream Generative-AI Compliance

Mindai recognizes that Customers who deploy Training Outputs into a downstream generative-AI service may be subject to filing, security-assessment, algorithm-registration, content-moderation, or similar regulatory obligations in their jurisdiction of deployment — including, by way of example, the PRC Interim Measures for the Management of Generative AI Services (AIGC 暂行办法), the PRC Provisions on Administration of Deep Synthesis Internet Information Services, the PRC Provisions on the Administration of Algorithm-Based Recommendations of Internet Information Services, and comparable regimes in Singapore, the European Union, and other jurisdictions. For the Training Platform, Mindai provides the model training infrastructure and compute resources, whose outputs are model parameters, and Mindai itself does not directly provide generative-AI content or algorithm-recommendation services to the public; accordingly, at the Training Platform level, Mindai does not constitute a generative-AI service provider under the PRC Interim Measures for the Management of Generative AI Services or an algorithmic recommendation service provider under the PRC Provisions on the Administration of Algorithm-Based Recommendations of Internet Information Services. For the Model Gateway, Mindai provides Customer with API access to the Macaron model series and to third-party open-source models, whose model capabilities are used by Customer in its own business scenarios; Mindai typically constitutes a technical support provider under the foregoing regulations rather than a service provider directly facing the public, with the specific role determination depending on the Customer's actual use case, the manner of model use, and the regulatory position (see Section 2.1 of the Terms of Service). Mindai will provide Customers with commercially reasonable deployment-support assistance to facilitate the Customer's compliance with such downstream obligations, including:

• Supplying standardised training-environment information (for example, training-infrastructure description, isolation architecture, and the security-certification evidence described in Article 4) suitable for inclusion in the Customer's security self-assessment materials;

• Providing audit-log extracts, training-job metadata, and data-lineage reports to the extent necessary to substantiate the Customer's regulatory filings;

• Responding, within the limits of applicable confidentiality and other Customers' interests, to reasonable written inquiries from competent regulators regarding the training infrastructure that underlies the Customer's deployed service;

• Making available, where released by Mindai, template security-assessment support packages (including template responses to common algorithmic registration questionnaires, model-card excerpts relating to the training environment, and the security-measures description set out in this Whitepaper).

Assistance under this Section 10.6 is limited to information relating to the MinT Training Platform infrastructure and to the Model Gateway service level operated by Mindai, including: (a) Training-Platform-side descriptions of training data processing, compute resources, and security measures; and (b) Model-Gateway-side information such as basic information about the Macaron model series, the deployment and compliance status of third-party open-source models, and API-level safety and content-moderation measures. Responsibility for substantive compliance with downstream generative-AI regulation — including content-moderation, user-protection, mandatory filings, and security self-assessments in respect of the Customer's deployed service — remains with the Customer. The allocation of costs for extraordinary deployment-support assistance (such as a requested custom audit letter or on-site regulatory meeting) will, where not addressed in the applicable order document, be agreed between the parties in good faith.

10.7 Model Gateway Architecture and Security Controls

The Model Gateway, as the API service component of MinT, incorporates the following architecture and security controls:

• API gateway and authentication — all Model Gateway API calls are authenticated via API Keys bound to Customer accounts; Mindai enforces least-privilege scope, validity management, and rotation policies for API Keys, and reserves the right to immediately revoke suspected compromised API Keys with notice to Customer;

• Rate limiting and abuse protection — the Model Gateway applies multi-dimensional rate limits based on account, API Key, and IP to prevent single-account overload of the infrastructure; automated abuse-detection identifies invocation patterns violating the AUP (including CSAM, malware generation, large-scale fraud generation);

• Input content safety — the Model Gateway performs necessary compliance checks on inputs prior to invoking the underlying model (including keyword filtering and sensitive-topic detection), and rejects inputs that manifestly violate the AUP or applicable law;

• Output safety guardrails — the Model Gateway deploys content-safety guardrails to identify and intercept manifestly unlawful or harmful outputs prior to return; Mindai retains the technical capability to apply watermarks, labels, or filtering rules to specific outputs when triggered by downstream regulatory requirements;

• Isolation of third-party open-source models — third-party open-source models deployed by Mindai (such as DeepSeek, GLM) run in containerized or dedicated inference clusters and are isolated at the deployment layer from Macaron model series and Customer training data to prevent cross-model data contamination;

• Invocation logging and audit — the Model Gateway retains necessary metadata for each API call (timestamp, API Key identifier, model identifier, token consumption) for billing, abuse detection, and compliance auditing; specific retention periods are set out in Section 3.6 of the MinT Data Processing Addendum.

Article 11 — Operational Security

11.1 Personnel Security

All Mindai personnel (including contractors) with access to Customer Data are subject to: (a) background checks to the extent permitted by applicable law; (b) written confidentiality and non-disclosure obligations; (c) onboarding and periodic security-awareness training, including training on phishing, social engineering, and secure coding; and (d) role-based access that is revoked promptly on role change or termination.

11.2 Subprocessor Management

Mindai engages a limited number of Subprocessors (including cloud-compute, storage, network, payment, communications, and support-tooling vendors). Subprocessors are subject to risk assessment prior to engagement and periodically thereafter, and are required by written contract to: (a) process Customer Data only on Mindai's documented instructions; (b) maintain confidentiality; (c) implement appropriate technical and organisational security measures; (d) assist Mindai with Customer-rights requests, security incidents, and audits; and (e) comply with any applicable cross-border-transfer requirements.

The current Subprocessor list is maintained on the Subprocessor Page and is updated in accordance with the DPA. Material changes are notified to Enterprise Customers in advance.

11.3 Change Management

Changes to production systems follow a documented change-management process, including peer review, pre-production testing, staged rollout, automated deployment controls, and rollback capability. Emergency changes are subject to expedited review and retrospective documentation.

11.4 Endpoint and Workstation Security

Mindai personnel access production systems only from managed workstations subject to disk encryption, endpoint-detection-and-response (EDR) tooling, patch management, and mobile-device management. Personal devices are not permitted to access production systems.

Article 12 — Audit Logging

MinT records audit events at the identity, API, data-access, and administrative layers. Audit logs include user identifier, tenant identifier, timestamp, source information, action, and resource.

Enterprise Customers may download audit logs relating to their own tenant, either through the MinT dashboard or through an export API. Extended retention of audit logs and integration with a Customer's own SIEM are available as a paid feature. Audit-log retention defaults and paid-tier parameters are set out in the applicable order form.

Audit logs are tamper-evident: Mindai applies appropriate storage, access control, and integrity controls to protect audit logs against unauthorised modification.

Article 13 — Business Continuity and Disaster Recovery

Mindai maintains a business-continuity and disaster-recovery programme designed to preserve the availability and integrity of the MinT Platform Layer and of Customer Data in the event of incidents affecting infrastructure, personnel, or facilities.

Production data is replicated across multiple availability zones within the deployment region, and is backed up on a regular cadence consistent with the service's recovery design objectives. The recovery-time objective and recovery-point objective (RTO / RPO) applicable to the MinT Platform Layer are set by Mindai based on service criticality and are kept under review as the Service scales; specific numerical commitments, if any, are set out in the applicable order form or enterprise agreement.

Business-continuity and disaster-recovery plans are tested periodically. Material findings from testing exercises are tracked to closure in Mindai's continuous-improvement process.

Article 14 — Incident Response

Mindai operates a documented incident-response process covering detection, triage, containment, eradication, recovery, and post-incident review. The security function monitors for security events through a combination of signal sources including endpoint-detection, network-traffic analysis, cloud-posture monitoring, application logs, and threat intelligence.

On confirmation of a security incident that affects, or is reasonably likely to affect, Customer Data, Mindai will notify affected Enterprise Customers without undue delay and in any event within seventy-two (72) hours of confirmation, consistent with the requirements under GDPR Article 33, PIPL Article 57, and comparable standards under PDPA and other applicable law.

Notifications will include, to the extent then known and subject to ongoing investigation: (a) the nature of the incident; (b) the categories and approximate volume of affected data; (c) the likely consequences; (d) the measures taken or proposed to address the incident and mitigate its effects; and (e) a point of contact for further information. Mindai will provide updates as the investigation progresses.

Post-incident, Mindai conducts a root-cause analysis and tracks remediation to closure. Lessons learned are incorporated into the security programme, including controls, playbooks, and training.

Article 15 — Privacy Compliance

Mindai's handling of Personal Data is governed primarily by the MinT Privacy Policy (for data processed in Mindai's capacity as a controller, such as account and billing data) and the DPA (for Personal Data contained within Customer Data, in respect of which Mindai is a processor).

Mindai's privacy programme is designed to comply with applicable data-protection laws, including the Singapore Personal Data Protection Act (PDPA), the People's Republic of China Personal Information Protection Law (PIPL), the EU General Data Protection Regulation (GDPR) and UK GDPR where applicable, and the California Consumer Privacy Act (CCPA/CPRA) where applicable, including as to lawful basis, data-subject rights, records of processing, data-protection impact assessments, and cross-border-transfer safeguards.

The MinT Privacy Policy (Article 9) sets out the data-residency position summarised in Article 6.3 of this Whitepaper.

Article 16 — Deployment Options

16.1 Cloud Deployment

Under the cloud-deployment model, Customer workloads run on the multi-tenant MinT Platform Layer operated by Mindai, hosted on mainland-China nodes of licensed cloud-service providers. The multi-tenant isolation controls described in Article 6.2, the data-protection controls described in Article 6, and the other controls described in this Whitepaper apply.

16.2 Private / On-Premises Deployment

The MinT Training Platform supports private deployment, including on Customer-controlled cloud accounts and on Customer on-premises infrastructure. Private deployment is a product of the MinT Training Platform and is positioned as a primary offering for Enterprise Customers with heightened data-residency, regulatory, or operational-control requirements. The MinT Model Gateway is provided as an API service and, at this v2.0 stage, does not support private deployment.

Under the private-deployment model:

• the MinT Platform Layer is deployed within the Customer's own infrastructure, with configuration, patching, and operational cadence coordinated between Mindai and the Customer under the applicable private-deployment engagement;

• Customer Data is stored and processed on infrastructure controlled by the Customer; the Customer determines data residency;

• custom integrations — including enterprise SSO (SAML 2.0, OIDC, DingTalk, Feishu, WeCom, Microsoft Entra ID, Okta, and similar), customer-managed key-management systems, customer-operated logging pipelines, and integration with existing monitoring and ticketing systems — may be configured as part of the engagement;

• the Customer is responsible for the physical security, network security, and personnel security of the deployment environment, including the host operating system, hypervisor, and surrounding infrastructure controls.

Article 17 — Customer Security Responsibilities

To maintain the security of MinT for their organisation, Customers are responsible for, among other things:

• managing user accounts, enforcing strong passwords and MFA, and promptly deprovisioning accounts on personnel changes;

• securing API keys and other programmatic credentials; scoping them to least privilege; and rotating them regularly;

• classifying Customer Data and determining appropriate handling (including whether to upload Sensitive Personal Information at all) consistent with applicable law and the Customer's own data-protection policies;

• performing desensitisation and minimisation of Training Data prior to upload, where applicable;

• implementing appropriate safety, moderation, and compliance controls in downstream systems that consume Training Outputs produced on MinT;

• complying with the AUP, the Terms of Service, and applicable law; and

• in the case of private deployment, securing the deployment environment and operating the platform in accordance with Mindai's hardening and operational guidance.

Article 18 — Roadmap

The items listed below reflect Mindai's current security and compliance roadmap. Indicative target windows, where provided, are estimates and subject to change. Customers should confirm current status at the time of engagement.

• ISO/IEC 27001:2022 certification — target window: [TBD];

• SOC 2 Type II report (security, availability, confidentiality) — target window: [TBD];

• ISO/IEC 27701:2019 certification (privacy) — target window: [TBD];

• Standardised SSO for cloud-deployment (SAML 2.0, OIDC, major enterprise IdPs) — target window: [TBD];

• Customer-managed keys (BYOK / CMEK) for cloud-deployment — target window: [TBD].

Article 19 — Contact

For security inquiries, vulnerability reports, and whitepaper-related questions:

• Service Provider: MINDAI PTE. LTD. (a private limited company incorporated in the Republic of Singapore), registered office at 152 Beach Road, #11-05, Gateway East, Singapore 189721

• Email (security inquiries, vulnerability reports, and general inquiries): contact@mindlab.ltd

Effective Date and Versioning

This Whitepaper is effective as of the effective date set out on the cover. Mindai may publish updated versions of this Whitepaper from time to time to reflect changes in Mindai's security programme, product architecture, or applicable law. Localised versions of this Whitepaper may be published; in the event of inconsistency between the English version and a localised version, the English version controls, except where applicable local law expressly requires otherwise.

— End of Whitepaper —