Myntriq Security Overview

Last Updated: 19 June 2026

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

Contact: hello@myntriq.io

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 runs entirely on Google Cloud Platform (GCP) in the Singapore region (`asia-southeast1`). GCP is certified to ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 1, SOC 2, and SOC 3.

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

Compute

Application workloads run on Google Cloud Run — a fully containerised, serverless compute platform. 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 Google Artifact Registry with private access only. No image is publicly accessible.

Database

Customer data is stored in Supabase (PostgreSQL), hosted in Singapore (`ap-southeast-1`). All data is encrypted at rest using AES-256 and encrypted in transit using TLS 1.2 minimum.

Supabase is SOC 2 Type II certified.

Secrets Management

All application secrets — database credentials, API keys, service-role keys — are stored in Google Cloud Secret Manager. They are never committed to source code, never logged, and never passed as plaintext environment variables in Docker build arguments.

Secrets are mounted to Cloud Run 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 Supabase Auth, which supports:

• Google OAuth 2.0 — the default authentication method for production environments
• Email and password — available for environments where OAuth 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:

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 LiteLLM service — a managed proxy that sits between the MyntriqOS application and third-party model providers (OpenAI, Anthropic, OpenRouter).

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

The LiteLLM service enforces authentication: only authenticated MyntriqOS application services can submit inference requests. In Internal Production, the LiteLLM service is additionally protected by Google Cloud IAM — only authorised Cloud Run service identities can call it.

Training Data

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

Third-party model providers (OpenAI, Anthropic) do not use data submitted through the MyntriqOS enterprise API to train their models, under the terms of their commercial API agreements.

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 Supabase 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 Residency

The primary data store (Supabase) is hosted in Singapore. Application compute (Cloud Run) is hosted in Singapore.

AI model inference requests are processed by third-party providers in the United States (OpenAI, Anthropic, OpenRouter). Customers should be aware of this cross-border data flow when submitting personal data of Singapore residents or EU/EEA individuals as part of AI prompts.

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 hello@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

Supabase performs automated database backups. Backup frequency and retention are determined by the Supabase 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:

1. Notify affected customers within 72 hours of becoming aware that a breach has occurred, where it is feasible to do so

2. 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)

3. 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 hello@myntriq.io.

Certifications and Compliance

Current status (19 June 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 — Google Cloud Platform (SOC 2, ISO 27001) and Supabase (SOC 2 Type II) — for the underlying infrastructure layer.

Roadmap:

SOC 2 Type II readiness is a priority for the 12 months following our first paid customer cohort. Customers in regulated sectors who require a SOC 2 report before procurement should contact hello@myntriq.io to discuss their timeline and our roadmap.

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 hello@myntriq.io.

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