Trust Centre

Security Overview

Infrastructure security, tenant isolation, encryption, audit logging, and incident response.

Read alongside the full document library →

Myntriq Security Overview

Last Updated: 28 September 2026

Contact: security-office@myntriq.io

Company: Myntriq Pte Ltd (UEN 202537571M), Singapore


Our Approach

Security at Myntriq is not an afterthought. It is a constraint that shapes every architecture decision — from how we isolate customer data to how we manage AI model access to how we deploy code.

This document describes the technical and organisational controls Myntriq has in place. We write it for the buyers, security reviewers, and procurement teams who need an honest account of how we operate — not a marketing document.


Infrastructure Security

Cloud Provider

MyntriqOS platform infrastructure — application compute and the primary data store — is hosted on cloud infrastructure certified to ISO/IEC 27001 and SOC 2. As a matter of security policy, Myntriq does not name its infrastructure provider, cloud services, or region topology in public-facing documents. The Subprocessor List is the authoritative, named register of the subprocessors that deliver the service.

AI model inference is a separate data path. Inference requests leave the platform and are processed by the third-party model providers named in the Subprocessor List, in the jurisdictions disclosed there — which include the United States and, for one transitional route, mainland China. The Data Locations and Jurisdictions section below explains this split, and the Subprocessor List is the authoritative annex for it.

We do not operate physical servers. All infrastructure is managed cloud-native.

Compute

Application workloads run on serverless, fully containerised cloud compute. There are no persistent virtual machines. Each request is handled by an ephemeral container instance that is created on demand and destroyed when idle. This architecture eliminates entire categories of infrastructure vulnerability (unpatched VMs, stale base images left running, persistent SSH access).

Container images are stored in a private container registry. No image is publicly accessible.

Database

Customer data is stored in a managed cloud database, hosted in Singapore. All data is encrypted at rest using AES-256 and encrypted in transit using TLS 1.2 minimum.

The database layer is hosted on infrastructure certified to SOC 2 Type II.

Secrets Management

All application secrets — database credentials, API keys, service-role keys — are stored in a managed cloud secrets service. They are never committed to source code, never logged, and never passed as plaintext environment variables in container build arguments.

Secrets are mounted to application services at runtime and are not visible in build artefacts.

Transport Security

All connections to MyntriqOS — from users' browsers to the application, from the application to the database, from the application to AI model providers — are encrypted in transit using TLS. The minimum supported TLS version is 1.2.


Application Security

Tenant Isolation

MyntriqOS is a multi-tenant platform. Each customer (tenant) is assigned a unique organisation identifier at onboarding. Row-level security (RLS) policies are enforced at the database layer, ensuring that all queries — including those issued by the application server — are scoped to the authenticated user's organisation.

A tenant cannot access another tenant's data, even if they share the same database instance. This is enforced by the database engine, not just the application layer — removing the risk that an application bug could accidentally expose cross-tenant data.

Authentication

User authentication is provided by the platform's managed cloud authentication service, which supports:

  • Single sign-on via Google OAuth 2.0, Microsoft Entra ID, or SAML 2.0 — the sign-in methods for production environments
  • Email and password — available for environments where SSO is not configured

Session tokens are stored as httpOnly cookies — they are not accessible to JavaScript and are therefore not vulnerable to XSS-based session theft. Sessions expire on sign-out and have a configurable idle timeout.

Role-Based Access Control (RBAC)

Within each organisation, users are assigned one of three roles:

RolePermissions
AdminFull access to all features, settings, user management, and governance controls
MemberAccess to assigned modules and conversations; cannot manage users or settings
ViewerRead-only access to dashboards and reports; cannot interact with agents or access sensitive data

Role assignments are managed by organisation administrators. Role changes take effect immediately.

Audit Logging

Every action taken in MyntriqOS is recorded in an immutable audit log:

  • User authentication events (sign-in, sign-out, failed attempts)
  • Agent actions (model invocations, outputs, approvals, rejections)
  • Administrative actions (user management, settings changes, agent configuration)
  • AI usage metrics (model used, token count, estimated cost, outcome)

Audit logs are available to organisation administrators through the Governance Dashboard. They are retained for a minimum of 24 months in accordance with the Data Retention Policy.

Input Validation and Output Handling

All user-facing inputs are validated server-side. The API layer validates type, length, and format before processing. Inputs are never interpolated into SQL queries without parameterisation.

AI model outputs are treated as untrusted content and are rendered in controlled UI contexts that prevent execution of injected scripts.


AI Model Security

Model Routing

All AI inference in MyntriqOS is routed through Myntriq's managed model routing service — a proxy layer that sits between the MyntriqOS application and the third-party model providers named in the Subprocessor List (Anthropic, OpenAI, Google, Alibaba Cloud, Moonshot AI, and OpenRouter). One model — the bge-m3 embedding model — runs on Myntriq's own infrastructure and involves no third-party processing.

Customers do not interact directly with model provider APIs. Model provider API keys are held exclusively by Myntriq and are stored in the managed cloud secrets service. They are never exposed to customers or users.

The model routing service enforces authentication: only authenticated MyntriqOS application services can submit inference requests.

The full model slate, per-provider routing details, and the controls over which models are available to each organisation are described in the Model Governance Policy.

Training Data

Myntriq does not use customer conversation data, prompts, or uploaded documents to train its own AI models.

With one transitional exception, the third-party model providers named in the Subprocessor List do not use data submitted through MyntriqOS to train their models, under the terms of their commercial API agreements as reviewed on 27 September 2026. The exception is the Moonshot AI route (kimi-k3): the platform terms under which this route operates today permit customer content to be used for model improvement, with no opt-out. Myntriq is transitioning this route to Moonshot AI's international platform (Moonshot AI PTE. LTD., Singapore) under a written agreement restricting content use; this qualifier will be removed when that written restriction is in force. While it is in effect, Myntriq limits this route to lower-sensitivity workloads.

Per-provider training postures and dated retention snapshots are recorded in the Subprocessor List. Customers may select specific models for specific agents where that option is available. The choice of model affects which third-party provider's infrastructure processes the associated prompts.


Data Protection

Data at Rest

All customer data stored in the platform database is encrypted at rest using AES-256.

Data in Transit

All data in transit is encrypted using TLS. This applies to all connections: user browser to application, application to database, application to AI model providers, and all internal service-to-service calls.

Data Locations and Jurisdictions

Platform application compute and the primary data store are hosted in Singapore.

AI model inference is processed by the third-party providers named in the Subprocessor List, in the jurisdictions disclosed there. Those jurisdictions include the United States and, for one transitional route (Moonshot AI, kimi-k3), mainland China; some providers do not commit to a processing location at all. The Subprocessor List records, for each provider, the processing location, the contracting entity and governing law, whether customer content may be used for training, and a retention snapshot as reviewed on 27 September 2026.

Myntriq does not claim that customer data never leaves any particular country. Customers submitting personal data of Singapore residents or EU/EEA individuals as part of AI prompts should review the Subprocessor List and can restrict which models are available to their organisation through the model permissions described in the Model Governance Policy.


Vulnerability Management

Myntriq follows a structured approach to identifying and addressing security vulnerabilities:

  • Dependency updates: Application dependencies are monitored for known vulnerabilities. Critical vulnerabilities are patched within 48 hours. High-severity vulnerabilities are addressed within 7 days.
  • Container base images: Production container images are rebuilt regularly to pick up base image security patches.
  • Code review: All changes to production systems go through peer review before deployment. Security-relevant changes (authentication, data access, API routes) receive additional scrutiny.
  • Access controls: Access to production infrastructure is restricted to authorised personnel. Production access is audited.

Myntriq does not currently operate a public bug bounty programme. To report a suspected security vulnerability, email security-office@myntriq.io with the subject line "Security Vulnerability Report". We will acknowledge receipt within 24 hours and aim to respond with an initial assessment within 72 hours.


Backup and Recovery

Database Backups

Automated database backups are performed by the managed database service. Backup frequency and retention are determined by the service plan tier. Point-in-time recovery (PITR) is available.

Recovery Objective

Myntriq targets the following recovery objectives, subject to infrastructure provider capabilities:

  • Recovery Point Objective (RPO): 24 hours (last successful backup)
  • Recovery Time Objective (RTO): 4 hours for critical platform services

These are targets, not guaranteed SLAs, and are subject to the nature and severity of any incident.


Incident Response

Myntriq maintains an incident response process for security incidents including data breaches, service disruptions, and unauthorised access.

Breach notification timeline:

In the event of a personal data breach affecting customer data, Myntriq will:

  • Notify affected customers within 72 hours of becoming aware that a breach has occurred, where it is feasible to do so
  • Notify the Personal Data Protection Commission (PDPC) within the timeframe required under Singapore's mandatory breach notification rules — 3 calendar days for significant breaches (defined as those that affect 500 or more individuals, or that involve sensitive personal data)
  • Provide a written incident report describing the nature of the breach, the data categories and approximate volume affected, the likely consequences, and the measures taken or proposed to address it

To report a suspected incident or security concern, contact security-office@myntriq.io.


Certifications and Compliance

Current status (28 September 2026):

Myntriq is an early-stage company. We do not currently hold third-party security certifications such as SOC 2 Type II or ISO/IEC 27001 in our own name. We rely on the certifications of our infrastructure providers — cloud infrastructure certified to ISO/IEC 27001 and SOC 2, with the database layer certified to SOC 2 Type II — for the underlying infrastructure layer. Customers in regulated sectors who require a SOC 2 report before procurement should contact security-office@myntriq.io to discuss their requirements.

Singapore PDPA:

Myntriq's data handling practices are designed to be consistent with Singapore's Personal Data Protection Act 2012 (PDPA) and its associated guidelines. Our Privacy Policy, Data Processing Addendum, and Data Retention Policy describe how we collect, use, and protect personal data.


Contact

For security enquiries, vulnerability reports, or questions about Myntriq's security posture, contact security-office@myntriq.io.

For data protection enquiries, contact our Data Protection Officer at info@myntriq.io, marked "Attn: Data Protection".