Enterprise readiness plan

Status: planned. Owner direction (22 October 2026): make Maia enterprise ready to certification standard. This document owns the gap register, the order and the evidence; the roadmap owns the E1–E5 and ORG1–ORG7 slices. Nothing here is a compliance claim. Dates and requirements were researched on 22 October 2026; items marked unverified need a primary source or counsel before anyone relies on them.

Which standards apply

A self-hosted product cannot hold SOC 2 or ISO 27001. Those certify the organization (vllnt): how it builds, ships, supports and runs Maia, and any hosted service. Buyers then check the product's own controls.

Gap register

Status from a repository inventory on 22 October 2026. Evidence paths are relative to the repository root.

Already in place: a random loopback bearer compared in constant time; Session credentials stored as digests with a 24-hour life; exact Host and Origin checks; preview, confirmation and receipt for consequential changes; person-only operations; Linux containment with Landlock, seccomp and cgroups; untrusted prompt sections; restricted worker tools; a CycloneDX SBOM per executable; pinned CI actions and an exact lockfile.

Order

Items overlap: each starts once its own dependencies hold.

1. E1, now, except licensing, support period and signing, which wait for their decisions. Cheap, and every later audit reuses its evidence.
2. E5, its model after S49 and S54, then joined to S13, S47, S55 and S57 as each ships: one view and change path for configuration and policy, which change-management controls audit.
3. ORG1–ORG7 people, roles, sign-in, approvals, audit and data controls (organizations and people), with E2 alongside ORG1–ORG2, MN0–MN1 and RL4–RL5.
4. E3 with Agent definitions (S49).
5. E4. SOC 2 Type II (Security, then Confidentiality) through a compliance platform, with a yearly penetration test; then ISO 27001, then ISO 42001. CRA conformity before 11 December 2027.

Acceptance per slice

Each item is tested at the lowest useful boundary (testing policy); nothing here is a compliance claim.

• E1. security.txt names the public reporting channel; a dry run of the CRA runbook meets the 24-hour, 72-hour and 14-day steps with timestamps; code, dependency and secret scanning runs on every pull request and fails on a new high-severity finding; the threat model covers every trust boundary in SECURITY.md; branch protection requires review and green checks. After their decisions: a LICENSE and support period are published, and CI verifies each release artifact's signature and SLSA provenance.
• E2. Changing or deleting a stored audit record breaks verification at that record once a checkpoint seals it, newer records are reported as unsealed, and a database rolled back behind the latest checkpoint fails startup (D-169); secrets cannot be read from the database file without its key; a Node whose key is unavailable starts without decrypting and reports why; remote transport refuses plain HTTP; a restored backup yields the same state digest; an unsigned update is refused.
• E2a. Once set up, no managed key is readable from a file; a locked or unavailable store blocks the launches that need it with a typed state, and managed mode has no plaintext fallback.
• E3. Each release has an AI risk assessment listing every model provider with its data use and retention; each agent-authored PR or comment carries an AI disclosure; a tuned model's record names its dataset snapshot and base model.
• E4. Each SOC 2 control has evidence collected from E1, E2 and E5 artifacts; a third-party penetration test report exists with every finding triaged; the CRA conformity file maps each Annex I requirement to evidence.
• E5. A configuration change shows its diff before confirmation; a Project change that would remove or weaken a Workspace rule is refused even when a person confirms it, and the change succeeds only in the Workspace policy; drift between .maia and admitted state is reported; a rollback is previewed and receipted, and a failed rollback leaves the previous state; every allow or deny names its rule and revision.
• ORG1. An invitation works once and never after its expiry; a suspended or removed person's next request fails; nobody sees a Workspace or Project outside their roles in lists, search, counts or exports; a guest sees only their named Projects until the expiry; nobody grants a role above their own or widens their own access alone; the last owner cannot leave or be demoted, suspended, deactivated or deprovisioned, even by a sync or by two owners demoting each other at once; a role change applies from the next request; access explain names the grants behind every allow.
• ORG2. Sign-in through an unverified identity provider fails; a person of a verified domain cannot sign in locally, except the one fallback admin; a sync never grants admin or owner and stops above its confirmed change count; deprovisioning revokes sessions, devices, tokens and any standing approvals within the bound.
• ORG3. A token or service account never exceeds its person's current grants or its scopes, stops at its expiry or revocation, and its confirmation, like an agent's, gets role_denied.
• ORG4. A requester, or the accountable person of an Agent, Routine, service account or token, never confirms their own two-person request; a standing approval never satisfies it; an expired request, or a confirmation for another digest, revision or target set, changes nothing.
• ORG5. Search and export return only what the reader's role allows; every administration action appears in the audit log.
• ORG6. A held scope deletes nothing; after erasure, receipts and the audit log hold the person ID with no personal data behind it; a transfer moves only the previewed IDs and no Connection or standing approval.
• ORG7. A Session of one person cannot read another person's home, credentials, worktrees or context, checked by negative tests on a shared Node; a delegated agent acts only within the consent's scope, operations and expiry, stops at revocation and never confirms for the delegator.
• All. Each administration action previews, confirms and leaves a receipt naming its person.

Open decisions and unverified points

• CRA product class. Default class allows self-assessment; a core function matching Annex III (identity or privileged access management, container runtimes) would need a harmonised standard or a notified body. Counsel decides.
• When Maia is placed on the market. Pre-release software is not yet on the EU market; the obligations start when it is sold.
• Unverified: the harmonised CRA standards were not yet cited in the Official Journal in early October 2026; the AI Act high-risk dates moved under Regulation (EU) 2026/1744; OMB M-26-05 ended the US federal software attestation requirement; cost ranges (SOC 2 roughly $25k–150k in the first year) come from vendor estimates.

Sources

• CRA: summary, annexes, implementation guidance
• AI Act: framework, Regulation (EU) 2026/1744
• GDPR, NIST SSDF, SLSA v1.2, OWASP LLM Top 10, CSA STAR for AI, OMB M-26-05