Built for the operations
your auditor will read.
MAIA writes decisions back into systems your team is accountable for. The audit, isolation, and explainability work isn’t optional, it’s the core of how the platform is engineered.
Decision lineage is the audit trail. Every action carries its parents.
Every signal, detection, decision, and action MAIA emits is linked through parent_id. Your auditor can replay any production decision back to the originating sensor, ledger row, or message, along with the rule that fired, the confidence score, and the identities involved. The audit isn’t bolted on. It’s the backbone.
What we engineer for by default.
Tenancy isolation
Every customer runs in a strictly scoped tenant. No shared connection pools, no shared cache keys, no cross-tenant query paths. Tenant ID is enforced at the runtime layer.
Sandbox-default integrations
Every connector boots in synthetic mode unless real credentials are explicitly set. Pilots run end-to-end against a fixture-shaped tenant before any prod credential leaves your environment.
Audit-grade lineage
parent_id chains every signal → detection → decision → action. Exportable to your SIEM as a structured event stream. No silent state changes.
Action gating + cure windows
Every agent ships at recommend-only. Write-back permissions are earned through measured pilot performance. Legally significant actions (e.g. RTA notices) always require human approval.
Encrypted in transit and at rest
TLS 1.3 everywhere. AES-256 at rest. Per-tenant keys. Secrets in a managed KMS, never in app config.
Least-privilege auth
OAuth 2.0 client-credentials, password grant, and SAML-bearer for connector auth. Internal RBAC scoped per tenant role.
Reduced model exposure
Operational data is processed inside our runtime. Model providers see only the prompts required for the decision, never raw ledgers, calendar contents, or PII at scale.
Reversibility & dry-run
Every non-trivial action supports dry-run. Reversible actions are tagged at decision time. The ledger records both intent and effect.
For ISR, C2, and sustainment. Built so the policy enforces in software.
Defence and intelligence operations span classification levels, allied partners, and sustainment cycles. MAIA models classification as a runtime property and enforces policy on every read, not in documentation. Live demo at demo.maiaintelligence.io/fusion. Methodology paper at /research/multi-domain-fusion-2026.
ALIGNED = architecture follows the framework’s principles in code. BOUND = lens binding active in the runtime. MAPPED = control crosswalk available on procurement. TRACKED = monitored for legislative status. ENFORCED = runtime property checked on every read.
For procurement, an inspector general, or an ATO authority package: the live demo, the methodology papers, and the architecture brief at docs/IDEAS_CHALLENGE_BRIEF.md are all evidence. We’d rather you click than read another datasheet.
Where we are. Honestly.
We update this page when status changes. If you need our latest SOC 2 status, sub-processor list, or pen-test summary, contact security@maiaintelligence.io.
Procurement evaluating MAIA?
We’ll send our DPA, sub-processor list, and current SOC 2 status under NDA within one business day.
Request the security packet →