Security

Overview

Anomaly AI is an AI-powered data analytics platform that enables organisations to query, visualise, and derive insights from their data using natural language. It is operated by Mindlake Ltd (Company No. 14894347), registered in England and Wales.

Security is foundational to how we build and operate the platform. No customer data is used for AI model training — ever. All LLM vendor agreements explicitly prohibit this. Customer data is isolated at every level: per-customer storage containers, project-level access control, and network segmentation between services.

This page summarises our security architecture, controls, and compliance posture. For a comprehensive treatment — including detailed architecture diagrams, data flow diagrams, incident response procedures, and complete vendor security assessments — we maintain a Security Whitepaper available on request.

Request the full Security Whitepaper →

Infrastructure & Encryption

All infrastructure runs on Microsoft Azure (East US region), leveraging Azure’s security certifications including SOC 1/2/3 Type II, ISO 27001/27017/27018, PCI DSS, HIPAA BAA, and FedRAMP. Infrastructure is provisioned and managed through version-controlled configurations.

Compute

Azure Virtual Machines with managed disk encryption, running Ubuntu with automatic security patches. Microsoft Defender for Endpoint provides host-level malware prevention and real-time protection.

Database

Azure Database for PostgreSQL (managed service) with automated backups, point-in-time recovery, SSL/TLS enforced on all connections, and AES-256 encryption at rest with Azure-managed maintenance and patching.

Storage

Azure Data Lake Storage with AES-256 encryption at rest using Microsoft-managed keys. File access is authenticated and time-limited. Each customer has a dedicated storage container.

Encryption in Transit

All data in transit is encrypted with TLS 1.2 or higher. This covers client-to-Cloudflare, Cloudflare-to-origin (Full Strict SSL — certificate validated), application-to-database (SSL required), application-to-storage (HTTPS), and application-to-LLM APIs (HTTPS). All HTTP traffic is automatically redirected to HTTPS.

Encryption at Rest

All data at rest is encrypted using AES-256 — Azure Data Lake Storage, Azure PostgreSQL, and Azure Key Vault. Data source connection strings stored in the database receive an additional layer of application-level encryption before storage.

Secrets Management

Azure Key Vault is the centralised secrets store for all sensitive configuration: database connection strings, API keys, OAuth client secrets, session secrets, JWT signing keys, and storage connection strings. Secrets are fetched at deploy time and are never committed to source code.

Network Security

All production traffic is proxied through Cloudflare Enterprise before reaching our infrastructure. Origin server IP addresses are hidden behind Cloudflare’s proxy network and are not publicly discoverable.

Web Application Firewall

Cloudflare WAF runs the Cloudflare Managed Ruleset and the OWASP Core Ruleset, providing protection against SQL injection, XSS, remote code execution, file inclusion, and other OWASP Top 10 threats. Both rulesets are applied to all incoming requests across all subdomains and are actively updated for new CVEs.

DDoS Protection

Enterprise-tier DDoS protection covering SSL/TLS, network-layer, and HTTP DDoS attacks. Automatic mitigation at Cloudflare’s edge network. Bot management detects and blocks malicious bots while allowing verified bots. Backed by Cloudflare’s 100% uptime SLA.

Network Segmentation

The production environment uses a multi-tier network architecture that isolates public-facing services, backend application services, and data stores into separate networks. Data stores have no internet access. Services can only communicate across network boundaries where explicitly configured.

External Attack Surface

The production environment exposes only HTTPS (443) and an HTTP-to-HTTPS redirect (80). All internal services communicate exclusively over private networks and are not reachable from the internet. Access is further restricted by Azure Network Security Groups.

Data Isolation

Per-customer storage isolation is enforced at the infrastructure level. There is no shared storage between customers and no mechanism to query another customer’s data.

Storage Isolation

Each customer’s files are stored in a dedicated Azure Data Lake Storage container. Access is resolved from the authenticated user’s session — there is no code path that can access another user’s data. Database queries for application metadata are always filtered by user ID and project ownership.

Project-Level Access Control

Within an account, data is further segmented by project. Role-based access control (owner, editor, read-only) governs who can view, modify, or delete data. Permissions are enforced at the API layer. Data connections are scoped per project, not per user.

Data Ownership & Lifecycle

Customers retain full ownership of all data uploaded to or processed by Anomaly AI. We do not claim any rights to customer data. Files, projects, and accounts can be deleted at any time — deletion is immediate and permanent with no hidden copies retained.

AI & LLM Security

Anomaly AI uses large language models to generate SQL queries and data analysis from natural language. We do not develop or host our own foundational AI models. All providers are used through enterprise-grade API agreements that contractually prohibit using API-submitted data for model training.

Minimal Data Exposure

The system is designed to minimise the amount of customer data shared with LLMs. For SQL generation, only table schemas (column names and types) and a small sample of 3–5 rows are sent for context. Full datasets are never sent to any LLM. After the model generates a SQL query, it is executed locally — query results are returned directly to the user and are not sent back to the LLM.

Query Execution

AI-generated SQL is executed locally within the customer’s isolated storage environment using a read-only analytical engine. The engine cannot modify customer data. Queries run in sandboxed contexts scoped to the authenticated user’s project — there is no mechanism to access another customer’s data.

Prompt Security

System prompts define model behaviour and are not modifiable by end users. Model responses are parsed and validated against expected schemas before rendering. The models cannot execute arbitrary code on the server — they generate structured queries which are processed by dedicated, sandboxed services.

Authentication & Access Control

User Authentication

User authentication is managed through Auth0, a SOC-2 Type II certified identity platform. Users authenticate via Google OAuth 2.0 with secure session management and configurable token expiration.

Adaptive Multi-Factor Authentication

Adaptive risk-based MFA is enforced through Auth0. The system assesses risk signals on each login — including device fingerprint, geographic location, IP reputation, and login patterns — and requires additional verification when risk is elevated. This covers new devices, unfamiliar locations, impossible travel scenarios, and other suspicious patterns.

Enterprise SSO

Auth0 natively supports SAML 2.0 and OpenID Connect (OIDC) enterprise connections. Organisations can connect their existing identity provider (Azure AD, Okta, Google Workspace) for single sign-on with centralised user provisioning and deprovisioning.

Administrative Access

Production server access is restricted to key-based authentication only. Azure portal access uses role-based access control (RBAC) via Azure Active Directory. Database credentials are stored in Azure Key Vault, and direct database access is restricted to authorised personnel.

Audit Logging

All authentication events (logins, failed attempts, MFA verification, password resets) and data operations (project creation/deletion, data source changes) are logged to a persistent audit trail. Mutating API requests are automatically captured by middleware. Audit logs include user identity, action performed, timestamp, and contextual metadata for accountability and forensic review.

Container Security

All application services run as Docker containers with hardened security configurations applied uniformly across the production environment. Hardening measures include read-only file systems, all Linux capabilities dropped by default, privilege escalation prevention, non-root execution, enforced resource limits, and strict socket isolation.

Full details of our container hardening controls are available in the Security Whitepaper.

Monitoring & Threat Detection

Container Runtime Monitoring

All container activity is monitored in real time at the kernel level. Detections cover credential theft, malware installation, process injection, privilege escalation, and container escape attempts. Critical alerts are delivered to the security team within seconds via automated integration.

Host & Cloud Protection

Microsoft Defender for Containers provides agentless container image scanning. Defender for Virtual Machines provides VM-level threat detection. Defender for Endpoint provides real-time malware prevention on the host operating system. Alerts are automatically routed to the security team.

Application Error Monitoring

We run a self-hosted error monitoring instance, meaning all error telemetry stays within our own infrastructure — no error data is sent to third-party servers. The system captures unhandled exceptions, errors, and performance data across all services with privacy-hardened configuration. No customer PII is captured.

Alert Response

Runtime detections arrive within seconds. Cloud protection alerts arrive within minutes. Vulnerability scan failures block deployment before production exposure. Critical alerts require immediate action; warning-level alerts are investigated within hours.

Vulnerability Management

Every container image is scanned for known vulnerabilities before deployment. Critical vulnerabilities block deployment — the image cannot be pushed to production. High-severity vulnerabilities generate alerts for immediate review. Scans cover both container image vulnerabilities and application dependency vulnerabilities.

All application dependencies are version-pinned in lock files and regularly reviewed and updated. Additional agentless scanning runs on images in our private container registry.

We follow a responsible disclosure process. If you discover a security vulnerability, please report it to [email protected]. We commit to acknowledging reports within 48 hours and providing regular updates on remediation.

Deployment Security

All deployments follow a zero-downtime strategy. New container images are built, scanned for vulnerabilities, and health-checked before traffic is switched over. The previous version is retained for instant rollback if issues are detected.

Base images are sourced from official repositories. Custom images are stored in a private container registry and scanned at both build time and in the registry.

Incident Response

Incidents are detected through automated channels (runtime monitoring, cloud protection, vulnerability scanning, error monitoring) and manual channels (customer reports, internal testing). Our response process follows a structured workflow:

1. Alert received by the security team
2. Source and severity assessed (Critical = immediate, Warning = within hours)
3. Investigation and root cause analysis
4. Containment: isolate affected services if necessary, preserve evidence for forensic analysis
5. Recovery: redeploy from a clean, verified image
6. Post-incident: document findings, review and update detection rules

Customers affected by a security incident are notified promptly with the nature and scope of the incident, data potentially affected, remediation steps taken, and preventive measures implemented.

Business Continuity & Disaster Recovery

Azure PostgreSQL provides automated daily backups with point-in-time recovery to any second within the retention period. Azure Blob Storage provides 99.999999999% (11 nines) durability for stored objects with data replicated across Azure storage infrastructure.

Zero-downtime deployments enable instant rollback to the previous working version. Container images are version-tagged in a private registry. All infrastructure configuration is maintained in version control.

Data Privacy & GDPR

Mindlake Ltd is registered with the UK Information Commissioner’s Office (ICO Reference: C1890477) and is compliant with the UK General Data Protection Regulation (UK GDPR).

Cookie Consent

All our websites implement GDPR-compliant cookie consent. Non-essential cookies — including analytics, marketing, and functional cookies — are only activated after the user provides explicit, informed consent. Users can review and change their preferences at any time.

Data Subject Rights

We support the full set of data subject rights under UK GDPR: access, rectification, erasure, restriction of processing, data portability, and objection. Requests are processed within 30 days.

Data Processing & Retention

We process personal data under lawful bases including contract performance, legitimate interests, and consent. We do not sell personal data to third parties. User data files are retained for the duration of the customer’s subscription and deleted upon account termination or request. LLM API calls are stateless — no data is retained by any vendor after the response is returned.

For full details, see our Privacy Policy and Cookie Policy.

Vendor Security

All third-party vendors maintain enterprise-grade security certifications. The following table summarises our key vendors and their data policies.

Compliance Roadmap

Contact & Responsible Disclosure

For security inquiries, vulnerability reports, or to request our Security Whitepaper:

[email protected]

For general privacy and data protection inquiries:

[email protected]