Security.

Last updated: 2026-04-28

Customer data is held in dedicated single-tenant environments, with inference run on AI models we operate ourselves rather than on third-party hosted AI services. Tenant isolation is absolute, no customer data is used to train or improve any model served to other customers, and on-premises and air-gapped deployments are available for customers whose data must remain inside their own infrastructure.

Our control environment maps to NIST SP 800-171 Revision 3 and CMMC 2.0 Level 2 for US defence and Controlled Unclassified Information work, the CCCS Medium Cloud Security Profile (PBMM / Protected B) for Canadian federal engagements, and SOC 2 Type II and ISO/IEC 27001 for general enterprise security and information security management.

Our security principles

Four principles govern how we design, deploy, and operate the product. Everything else on this page is a consequence of these.

Your data stays in your boundary if you require it. On-premises, air-gapped, and private-cloud deployments keep customer data, model activity, and inference traffic inside the customer's network and cloud accounts. No outbound dependency on atlantiq AI infrastructure is required for those modes. Any movement across a tenant, region, or integration boundary is documented, scoped, and explicitly authorized in advance.

No third-party AI service ever receives customer content. We run our own AI models on infrastructure we operate, or on infrastructure you operate. Third-party AI model providers do not receive customer data in any deployment mode.

Tenant isolation is absolute. Each customer gets a dedicated tenant. No data, context, or model artifacts are shared across customers.

No training on customer data. Customer drawings, models, specifications, conversations, and documents are never used to train or fine-tune base models, public models, or cross-tenant models. Tenant-scoped fine-tunes, where explicitly contracted, stay tenant-scoped.

Tenant isolation

Each customer gets a dedicated tenant. Application state, identity scope, and the data plane are isolated per tenant. Inside a tenant, project-level isolation is the default: data and context from one project do not surface in another without explicit user action.

• Per-tenant encryption keys, with optional per-project keys on request.
• VPC-level isolation per tenant; private endpoints for managed cloud.

Self-hosted AI inference

Customer project data does not transit a third-party AI model provider in any deployment mode. We run our own AI models on infrastructure we operate, or on infrastructure you operate. For on-premises and private-cloud deployments, AI inference runs entirely on customer-controlled compute.

Where customer-specific model tuning is used, the result stays scoped to that customer. It is not served to other customers and never propagates back into shared models.

Deployment options

Because our customers span managed-cloud enterprises, on-prem classification authorities, and air-gapped defence programs, we support five deployment modes. The mode is scoped and documented per engagement.

Managed cloud

A dedicated, single-tenant environment that we operate in the customer’s preferred region, including Canadian, UK, EU, and US regions. We run the infrastructure; you retain full data ownership and exit rights. Appropriate for enterprise deployments without export-control obligations.

Sovereign cloud hosting

A dedicated, single-tenant environment hosted on sovereign cloud infrastructure that meets the sovereignty requirements of the customer’s jurisdiction, including Canada, the United Kingdom, the European Union, and the United States. The deployment satisfies data residency, operator residency, and protection from foreign legal process, with regional alignment to the relevant national security profile (for example, the CCCS Medium Cloud Security Profile / PBMM / Protected B for Government of Canada engagements, and analogous regimes for UK, EU, and US public-sector and regulated-industry engagements). Appropriate for government engagements, defence and public-sector customers, and commercial customers with sovereignty obligations under their own national law.

Private cloud

Deployment into your own hyperscale cloud tenancy, under your compliance boundary and your security controls. We deploy and help operate; your cloud account holds the data. Common for customers that already enforce private networking, identity controls, encryption, logging, and data-residency rules in their cloud account.

On-premises

Installation inside your data centre. No inbound or outbound dependency on atlantiq AI infrastructure is required for operation. Updates ship as signed packages on a negotiated cadence. This is the default for Controlled Goods environments and for customers whose data-access gates require all project data to sit on infrastructure they own.

Air-gapped

Fully isolated networks, offline inference only, periodic signed-update cadence on a schedule scoped to the deployment, delivered on removable media or through one-way diode transfer. Appropriate for classified programs and the strictest export-controlled environments.

The matrix below summarizes the controls each mode supports.

Encryption and key management

• In transit: TLS 1.3 is the default. Internal service-to-service traffic uses mutual TLS inside the tenant boundary.
• At rest: AES-256 via the underlying cloud KMS, aligned to the deployment region and customer choice. Customer-managed keys (CMK) and bring-your-own-key (BYOK) are supported. On-premises and air-gapped deployments use the customer’s own KMS.
• Envelope encryption is used for customer-uploaded data.
• Key rotation is documented per deployment and per key type. Rotation can be customer-triggered on demand.
• Secrets are managed through a dedicated KMS or secrets manager and are never shipped with the product.

Identity and access

• SSO via SAML 2.0 and OIDC. Tested integrations with leading SAML 2.0 and OIDC identity providers; specific integrations available on request.
• MFA can be enforced for all user roles and is mandatory for administrative roles. Hardware tokens via WebAuthn / FIDO2 are supported.
• RBAC with least-privilege defaults. Tenant- and project-scoped roles. Custom roles supported.
• Audit logging streamed to the customer’s SIEM. Any SIEM supporting standard syslog or webhook delivery is supported.
• SCIM provisioning for user lifecycle management.
• Just-in-time elevation for break-glass administrative access, with logged approval and time-boxed expiration.
• Session recording available for privileged activities, stored in the customer’s environment.

Network isolation

• Cloud-native private networking (VPC equivalents) for managed-cloud environments.
• Private endpoints and PrivateLink-style routing for private connectivity to customer networks, without public internet exposure.
• Egress allow-lists for on-prem deployments; no outbound calls outside the permitted list.
• IP allow-listing for administrative consoles and for API access on request.
• Cloud-native DDoS protection on managed-cloud deployments. In private-cloud deployments, DDoS protection is inherited from the customer’s posture.
• Web Application Firewall (WAF) on internet-facing surfaces.

Supply chain and subprocessors

We run a minimal subprocessor footprint, scoped per region. In managed-cloud deployments it currently covers cloud infrastructure and supporting services. Each subprocessor is bound by data processing terms aligned to GDPR Article 28 and PIPEDA principles.

In on-premises and air-gapped deployments, no subprocessor has access to customer data. The software runs inside the customer’s boundary and does not call home.

The full subprocessor list is available on request.

Secure software development

Our engineering practice requires code review, security testing, dependency and secret scanning, signed production commits, SBOMs, image scanning, patch deadlines, and penetration testing. Our control environment, audit preparation, and compliance program are managed in partnership with an external cybersecurity firm.

• Mandatory code review on every change. Two-person review for security-sensitive paths.
• Static application security testing (SAST) on every code change.
• Dependency-vulnerability scanning with automated remediation.
• Secret scanning with build-blocking enforcement.
• Signed commits enforced on production code paths.
• Software Bill of Materials (SBOM) published for every release in CycloneDX format, available on request.
• Container images are built from pinned bases and scanned before deployment.
• Vulnerability patching SLAs, measured from disclosure: Critical within 24 hours, High within 7 days, Medium within 30 days. Urgent zero-days ship out-of-cycle.
• Third-party penetration testing on a documented cadence.

CMMC 2.0 and NIST alignment

Our control environment maps to NIST SP 800-171 Revision 3 for US Department of Defense Controlled Unclassified Information work, and to the CCCS Medium Cloud Security Profile (PBMM / Protected B) for Canadian federal engagements. NIST SP 800-171 R3 is the technical basis for CMMC 2.0 Level 2. PBMM is the operational baseline for any cloud service handling Government of Canada Protected B information. Formal CMMC and PBMM assessments are undertaken when an engagement requires them; the controls operate today.

Export control and classification

atlantiq AI Automation Solutions Ltd. is a Canadian-incorporated company. Our engagement structures respect the following regimes:

• US ITAR (International Traffic in Arms Regulations): defence articles and defence services on the USML. Handled on customer-controlled infrastructure only, with personnel nationality and clearance arrangements scoped per engagement.
• US EAR (Export Administration Regulations): dual-use items under the CCL, including EAR99 and controlled ECCN categories. Same infrastructure and personnel constraints apply for controlled items.
• Canadian Controlled Goods Program (CGP): Controlled Goods and Controlled Technology under the Defence Production Act. Our engagement structure for CGP-registered customers keeps all Controlled Goods content on customer-owned or Canadian-sovereign infrastructure. CGP registration is undertaken when an engagement requires it.
• EU dual-use Regulation 2021/821: covering dual-use items, cyber-surveillance items, and re-export obligations inside and out of the EU single market.

Export-controlled programs run on customer-controlled infrastructure. Personnel nationality and clearance arrangements are scoped per engagement.

We do not handle classified or export-controlled material on our managed infrastructure unless that arrangement is explicitly agreed and documented.

Data classification handling

Customer data is handled at the classification level the customer applies to it. We support engagement structures aligned to Canadian Protected A, Protected B, and (by arrangement) Protected C; UK Government Security Classifications at Official and Official-Sensitive; EU classifications including RESTREINT UE / EU RESTRICTED; US markings including For Official Use Only, Sensitive But Unclassified, and Controlled Unclassified Information; and commercial Confidential and Restricted markings. Higher classification levels may require deployment-mode constraints (typically on-premises, air-gapped, or sovereign cloud hosting in the customer’s jurisdiction), personnel scoping, and additional handling controls scoped to the engagement.

Compliance posture

Right to audit

We treat audit requests as part of doing business in regulated industries, not as adversarial. Customers have the right to audit our controls, scoped reasonably and on reasonable notice.

Business continuity and disaster recovery

• Automated backups on a tier-appropriate cadence, tested for restore integrity on a documented schedule.
• Documented Recovery Time Objective (RTO) and Recovery Point Objective (RPO) per service tier; shared with customers on request.
• Regional failover is supported in managed-cloud deployments. Multi-region active-active is available.
• Disaster recovery runbook reviewed and tabletop-exercised on a documented cadence.
• Backup encryption uses the same KMS posture as the primary data stores; backups never downgrade the encryption level.

Incident response

For confirmed security incidents affecting a customer’s data, our target initial customer notification window is 24 hours from confirmation. Notification is delivered by phone where a contact has been designated, followed by written summary within the same window. Shorter contractual windows are supported for customers that require them, including suspected-incident notification contracted separately for customers that require it.

For personal-data breaches subject to GDPR, our notification posture aligns to the 72-hour requirement under Article 33.

Our incident-response runbook is reviewed and tabletop-exercised on a documented cadence. Post-incident root cause analysis (RCA) is shared with affected customers under contract, and corrective action tracking continues until closure.

Responsible disclosure

If you believe you have discovered a security vulnerability in our website or services, please report it to security@atlantiq.ai. We ask that you:

• Do not publicly disclose the issue until we have confirmed a resolution.
• Do not test against customer environments or production data belonging to third parties.
• Limit testing to the minimum necessary to demonstrate the issue.

Safe harbor. Researchers acting in good faith and within these guidelines will not face legal action from atlantiq AI for accessing, identifying, or reporting vulnerabilities consistent with this policy. We will work with you to understand and resolve the issue promptly.

Our security.txt provides the canonical machine-readable contact record (RFC 9116).

Contact

For security vulnerability disclosures from researchers and for incident notification from customers: security@atlantiq.ai. Customer engagements include a designated incident contact and phone-routing arrangement. For all other inquiries: contact@atlantiq.ai.