Request access
Solutions The customer brief, intactOne connected threadThe learning ledgerCross-discipline checksLive change tracingEvidence on demandThe deterministic enginePhysics with receipts
Users Customer FacingMission Owner / Project ManagerEngineering LeadEngineering SpecialistsComplianceExecutive
Products OverviewExploreBlueprintValidateAutomate
PricingCompany Request access

Legal

Security

A public overview of security, deployment assurance, and engineering trust at Mitoma Systems.

This page distinguishes current public-site posture, product security architecture, customer-specific deployment options, and engineering assurance.

It is not a certification, audit report, or substitute for a deployment-specific security schedule.

Scope of this page

This page is a public overview of how Mitoma Systems approaches cybersecurity, deployment assurance, and engineering trust. It distinguishes the current marketing-site posture, product security architecture, customer-specific deployment options, and engineering-assurance capabilities.

It is not a certification, audit report, penetration-test result, customer security questionnaire, or deployment-specific security schedule. Program-specific controls, service levels, evidence, and commitments must be recorded in the applicable Customer Agreement, DPA, or security schedule.

Security controls

The public marketing site is a static Astro site hosted on Vercel. It is separated from the product environment and does not hold product customer or mission data.

  • Authenticated workspace and mission routes use server-trusted identity, organisation scope, roles, and mission membership to make authorisation decisions. Client-supplied role or tenant assertions are not treated as authority for an authenticated user.
  • The product supports multi-factor authentication. Enterprise OIDC-based single sign-on and SCIM user lifecycle integration may be configured where agreed for a deployment.
  • Security-sensitive routes are covered by route classification, authentication, authorisation, cross-organisation access, and response-flow tests in the product repository.
  • The application includes security-event recording, alerting, audit, session-revocation, incident, and evidence-hold mechanisms. Notification channels, retention, and operating procedures are configured for the applicable environment.
  • We do not use customer content to train shared or public foundation models, and we do not permit a contracted model provider to do so unless the customer expressly agrees in writing.
  • No security architecture or control eliminates all risk. Customers remain responsible for their users, devices, identity policies, access reviews, and offboarding unless a Customer Agreement allocates those responsibilities differently.

Deployment options

Hosting region, deployment topology, provider set, data residency, support model, and service levels are determined for each approved deployment. This page does not promise that a particular topology, country, provider, or assurance state is immediately available.

  • Managed cloud, private-cloud, sovereign, on-premises, isolated, or air-gapped configurations may be provided only where technically approved and agreed in writing.
  • Product deployments are designed to use transport protection, managed secrets and storage controls, access restrictions, logging, and network policy appropriate to the configured environment.
  • Customer-managed keys, enterprise identity federation, controlled egress, single-tenant isolation, and customer-selected residency apply only where documented for the deployment.
  • Backup scope, retention, restore testing, recovery procedures, and any recovery-point or recovery-time objective must be specified for the deployment or Customer Agreement. No universal RPO, RTO, or availability commitment is made on this page.
  • The enabled providers and processing locations are confirmed in the applicable Customer Agreement, DPA, security schedule, or deployment record before customer-confidential or regulated data is submitted.

Regulated and allied deployments

Mitoma Systems is operated by Leva Nu Pty Ltd, an Australian-owned and operated company. The platform is intended for commercial, industrial, critical-infrastructure, and allied autonomous-machine programs across air, ground, and water.

"AUKUS-aligned" describes the intended suitability of the product and deployment approach for allied programs. It is not a government endorsement, security classification, procurement approval, or claim that Mitoma Systems holds a particular accreditation.

  • Data classification, export-control, defence-trade, sovereignty, residency, support-access, and provider restrictions must be identified before regulated data is submitted.
  • In-country hosting, isolated deployment, customer-controlled infrastructure, or formally accredited environments may be provided only where agreed in writing and supported by current technical and assurance evidence.
  • Regulated-program requirements are documented and addressed through the applicable Customer Agreement, DPA, security schedule, deployment plan, and customer approval process.

Engineering assurance

Engineering assurance complements cybersecurity but is not the same thing. Mitoma Systems is designed to preserve the evidence, provenance, review history, and decision context needed to understand how an engineering result was produced.

  • Product records may include inputs, versions, rules, source metadata, generated artifacts, reviewer actions, overrides, and decision history.
  • Customer-specific standards, rules, components, and policy overlays may be configured for an approved workspace. Their precedence and enforcement depend on the enabled workflow and are recorded where supported.
  • Sourcing policies may prefer approved supplier classes, exclude suppliers inconsistent with the customer's policy, and surface unresolved sourcing gaps instead of silently treating them as compliant.
  • AI may assist with interpretation and review, but it is not the final authority for safety, certification, procurement, deployment, or operational decisions.
  • These capabilities do not replace qualified engineering judgement, independent verification, testing, certification, regulatory approval, or customer acceptance.

Incident response and disclosure

If we become aware of a security incident affecting customer information or service integrity, we will investigate, contain, remediate, recover, preserve relevant evidence, and notify affected customers or regulators where required by law or contract.

Any customer-specific notification deadline, communication channel, cooperation duty, or incident definition is governed by the applicable Customer Agreement, DPA, or security schedule.

Please report suspected vulnerabilities to info@mitoma.systems, marked for the attention of Security. Include enough detail for us to reproduce the issue. Do not access, modify, delete, or exfiltrate data that is not yours, and do not run testing that disrupts the service or exceeds our published guidance.

Assurance status

This page does not claim ISO 27001, SOC 2, IRAP, DISP, CMMC, FedRAMP, or another formal certification or accreditation unless a current certificate or written assurance document is provided.

Where a program requires formal assurance or accreditation, the applicable requirements are documented and addressed under signed terms. We do not promise to obtain a particular certification or accreditation unless that commitment is expressly agreed in writing.

A customer security questionnaire, CAIQ, control matrix, deployment architecture, audit report, penetration-test report, or other evidence pack is a separate assurance artifact and is not supplied by this public overview.