MIND

Security and compliance

Deterministic builds, tamper-evident artifacts and opt-in post-quantum signing, with documented audit controls. SOC 2 has not been audited.
View security docsReport a vulnerability
Every artefact passes a verification gate before it is trusted.
mindc verify
$ mindc dot.mind --emit-evidence dot.mic3
Wrote mic@3 evidence artifact: dot.mic3 (274 bytes, self-check ok)
$ mindc verify dot.mic3
trace_hash:       195c19973641f721b4a072aca61afbd03191a799c6b5c11d0aebbff4f53c9b5a
trace_hash_kind:  mic3-bytes
trace_hash_valid: yes
signature:        absent
note: artifact carries no signature (unsigned but attested)
$ mindc verify dot.mic3 --require-signed
error[verify]: artifact carries no valid signature (signature: absent) — --require-signed demands a signed artifact
Captured from mindc 0.10.2. Unsigned artifacts are attested; requiring a signature fails closed (exit 1).

Evidence

Evidence and signing

Every artifact built with an evidence chain carries a hash of its own canonical IR. Signing is a capability you opt into; it is off by default.

  1. Source

    .mind program

  2. Canonical IR

    mic@3 bytes

  3. trace_hash

    SHA-256 over mic@3

  4. Evidence MAP

    embedded in the artifact

  5. Signature

    opt-in, PQC hybrid

  6. mindc verify

    recompute and compare

Three artifacts pass through mindc verify: accepted, rejected on hash mismatch, and failed closed when a signature is requiredmindc verifydot.mic3attestedacceptedtrace_hash validdot.mic3IR changedrejectedtrace_hash mismatch--require-signedunsignedfails closedexit 1

  • Evidence chain

    Built in

    trace_hash is anchored on canonical mic@3 bytes (RFC 0016); mindc verify recomputes it and reports any mismatch.

  • Artifact signing

    Opt-in

    PQC hybrid signature (ML-DSA-87 + SLH-DSA), both legs required. Stripping a leg or downgrading the scheme tag fails closed. Enabled only when an operator supplies key seeds.

  • Legacy schemes

    Retired

    Ed25519 and the Ed25519 + ML-DSA-65 hybrid refuse at signing and trust verification; they remain only to read historical artifacts.

Detail and phases: roadmap, evidence chains.

Open compiler

Security posture of the open compiler

What the Apache 2.0 compiler gives you for the supported language surface.

  • Deterministic builds

    Bit-identical on x86/x64, ARM, GPU and any chip: the same inputs give the same output, so artifacts and supply-chain records can be verified.

  • Build provenance

    Manifests record SHA-256 of build outputs, lockfile-pinned dependencies and the compiler version.

  • Memory safety

    Bounds checks and checked integer overflow are on by default, following the documented compiler and runtime boundaries.

  • Pure-MIND cryptography

    AES-GCM, SHA-2/3, HKDF, X25519, RSA-PSS, ECDSA-P256, ML-KEM-768, X.509, HTTP/2 and a TLS 1.3 client, RFC and NIST known-answer verified.

  • Dependency scanning

    Part of the release workflow, with SPDX 3.0 and CycloneDX 1.5 SBOM export.

  • Compliance reporting

    Audit-ready reports for FDA, EU AI Act and ISO 26262 via mind_audit, anchored on the evidence chain.

Commercial runtime

Auditability in the commercial runtime

Runtime-side records for audit review and incident investigation, available with the commercial MIND-Runtime.

  • Audit logging

    Structured audit logs for compilation events, deployments and inference calls.

    Commercial
    • Compilation events
    • Deployments
    • Inference calls

  • Execution traces

    Structured logs of model execution: inputs, outputs, timestamps and resource usage.

    Commercial
    • Request-level tracing with correlation IDs
    • Tamper-evident log storage
    • Export to SIEM systems such as Splunk and Datadog

  • Versioning and lineage

    Lineage from training data to deployed artifacts, supporting A/B testing and rollback.

    Commercial
    • Git-based source versioning
    • Immutable artifact registry
    • Training run metadata (dataset hashes, hyperparameters)

Frameworks

Compliance framework alignment

Deterministic execution and audit logging provide artifacts for deployment-specific compliance review. No certification is claimed.

  • SOC 2 Type II

    Planned, not audited

    Planned for MIND Cloud (hosted control plane). Control mapping is in development; no audit has been completed and no report is available.

  • HIPAA

    Deployment option

    On-premises and VPC deployments can be assessed for customer programs using audit trails, provenance and redaction controls. No certification, control mapping or BAA artifact is published; any BAA needs separate technical and contractual review.

  • ISO/IEC 27001

    Planned (2026)

    Control mapping is planned for hosted offerings. No certification is claimed.

  • GDPR and data privacy

    Enterprise

    A Data Processing Agreement is available for EU customers, with support for data residency requirements and right-to-deletion workflows.

Disclosure

Report a vulnerability

Coordinated disclosure, with CVE assignment and patch releases following best practice.

  1. Email the security contact

    info@star.ga

  2. Include reproduction steps

    Description, steps to reproduce, affected versions if known, and your contact details.

  3. We acknowledge and plan

    We aim to acknowledge reports within 48 hours and give a timeline for remediation.

  4. Disclose after the patch

    Please do not disclose publicly until we have issued a patch.

A signed artifact accepted only when both post-quantum signature legs verify: an ML-DSA-87 lattice and an SLH-DSA hash tree each feed one socket before the seal appears, while a copy with one leg stripped fails closed.

Questions about security or compliance?

Talk to us about your requirements, or write to info@star.ga.

Request enterprise demoView security docs