CMMC
The US Cybersecurity Maturity Model Certification programme requires defence contractors to protect controlled unclassified information against a defined set of security practices before they can win and keep defence work. Mickai keeps controlled unclassified information on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and the assessed boundary contracts to systems the organisation controls end to end. Because the data physically cannot leave the building, the practices that CMMC assesses, access control, audit and accountability, system and communications protection and incident response, are enforced by architecture and evidenced through a post-quantum Open Audit Record.
CMMC exists because controlled unclassified information in the defence supply chain has repeatedly leaked through systems contractors could not fully secure, and the programme now conditions defence awards on demonstrable protection of that data. It draws its practices from the NIST SP 800-171 control set, spanning access control, audit and accountability, configuration management, identification and authentication, incident response, system and communications protection and more. Every cloud AI service a contractor adds enlarges the assessed boundary, introduces an external environment the contractor cannot fully inspect, and adds transmission paths that must be protected and monitored. Meeting the higher CMMC levels across a sprawling, cloud-dependent boundary is both costly and fragile. Mickai contracts the boundary to hardware the organisation owns by keeping controlled unclassified information, the models and the audit trail fully offline, so there is no cloud AI service inside the assessed scope and no data egress path to defend. Access control and authentication are enforced locally through hardware-attested identity, every access is sealed to a tamper-evident Open Audit Record for the audit-and-accountability practices, and incidents are detected and contained within the organisation's own perimeter.
The 6 obligations this framework imposes, each met by construction on hardware you own and mapped to the subsystem that enforces it.
Assessed Boundary Contained to Owned Hardware
Because controlled unclassified information is processed on hardware you own and never transmitted to a cloud AI service, that provider is never drawn into the assessed CMMC boundary and the scope contracts to systems the organisation controls end to end. A smaller, fully controlled boundary is cheaper to secure and more robust to assess. There is no external environment the contractor cannot inspect. Scope containment is enforced by architecture rather than by network segmentation alone.
Access Control and Authentication
Mickai enforces the access-control and identification-and-authentication practices by gating every access to controlled unclassified information behind hardware-attested identity and least-privilege clearance on owned hardware. Access descends to the record level and can be scoped per role and per tenant, so no user reaches data beyond their authority. Nothing depends on a shared cloud identity layer. The control families are satisfied inside the organisation's own perimeter.
Audit and Accountability
The audit-and-accountability practices require the organisation to create, protect and retain records that let it monitor and investigate activity, and Mickai meets this by sealing every access and action to a post-quantum Open Audit Record. The trail captures the actor, the data touched and the time, and it is tamper-evident and reproducible for an assessor. There is no reliance on a vendor's logging tenancy. Audit records are generated as a by-product of the work and held on hardware you own.
System and Communications Protection
Because controlled unclassified information is processed in place on owned hardware, there is no transmission to an external AI service to protect, which satisfies the system-and-communications-protection practices by removing the exposure rather than defending it across a shared network. The data never crosses a boundary to a third party in the inference path. The communications surface an assessor reviews contracts accordingly. Protection is achieved by construction.
Configuration Management and Signed Artefacts
Mickai supports the configuration-management practices by loading only signed, verified models and binaries and sealing every configuration change to the audit record on owned hardware. An unsigned or tampered artefact fails closed, and the organisation can pin specific versions and refuse silent upgrades. There is no vendor changing the system outside the organisation's control. Configuration integrity is enforced and evidenced locally.
Incident Response and Containment
Because the system runs inside the organisation's own perimeter, security incidents are detected and contained locally rather than inside a vendor environment, which supports the CMMC incident-response practices. The sealed audit trail evidences exactly what controlled information was accessed, when and with what effect, so response and reporting are accurate and first-hand. There is no dependency on a provider's incident disclosure. Containment and evidence are both local and provable.
The advantages hold across every framework, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
Scope inference, extraction, retrieval and storage on infrastructure you control. Document and test any external connector, support channel or transfer before describing a workflow as zero-egress.
Workflows with local models, data and supporting services can continue offline. Live external email, calendars and other services need an approved connection or controlled import, with clear unavailable and pending states.
Map prompts, documents, indexes, logs and backups to their processing and storage locations. Local hosting supports control of location; access, retention and any transfers still need review.
Prepare and classify source records, preserve permissions and evaluate answers against the originals. Retrieval and model training are separate choices; agree data use and licences for each.
Compare hardware and licences alongside integration, power, administration, support, updates, evaluation and recovery. Measure cost at the required workload and quality before claiming savings.
Define who holds keys, who can administer the system and which actions need approval. Test denied requests, revoked access and audit records. Physical security, insider risk and incident response remain operational responsibilities.
Agree version selection, signed update procedures, rollback, data export and licence rights. Reassess requirements as software and obligations change; owning hardware does not remove maintenance or compliance work.
How does on-premise AI help a defence contractor meet CMMC?
Mickai keeps controlled unclassified information on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and the assessed boundary contracts to systems the organisation controls end to end. Because the data physically cannot leave the building, the practices CMMC assesses, access control, audit and accountability, system and communications protection and incident response, are enforced by architecture and evidenced through a post-quantum Open Audit Record.
Does using Mickai enlarge the CMMC assessment boundary?
No, it contracts it. Because controlled unclassified information is processed on hardware you own and never transmitted to a cloud AI service, that provider is never drawn into the assessed boundary and the scope shrinks to systems the organisation controls end to end. A smaller, fully controlled boundary is cheaper to secure and more robust to assess, with no external environment the contractor cannot inspect.
How does Mickai satisfy the audit-and-accountability practices?
Mickai seals every access and action to a post-quantum Open Audit Record with the actor, the data touched and the time, which meets the requirement to create, protect and retain records for monitoring and investigation. The trail is tamper-evident and reproducible for an assessor and held on hardware you own, generated as a by-product of the work with no reliance on a vendor's logging tenancy.
How are access control and authentication enforced?
Mickai gates every access to controlled unclassified information behind hardware-attested identity and least-privilege clearance on owned hardware, with access descending to the record level and scoped per role and per tenant. Nothing depends on a shared cloud identity layer, so the access-control and identification-and-authentication practices are satisfied inside the organisation's own perimeter.
How does Mickai support CMMC configuration management?
Mickai loads only signed, verified models and binaries and seals every configuration change to the audit record on owned hardware. An unsigned or tampered artefact fails closed, and the organisation can pin specific versions and refuse silent upgrades, so there is no vendor changing the system outside its control. Configuration integrity is enforced and evidenced locally.
Is Mickai a cloud service that would need its own CMMC assessment in our boundary?
No. Mickai is a Sovereign Intelligence Operating System acquired as an owned asset that runs on your own hardware, not a cloud service holding your controlled information. Because there is no external provider in the data path, it does not add an external environment to your assessed boundary. The public cloud remains useful for non-controlled work; Mickai is the answer for the controlled-information boundary.
Bring CMMC in-house.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and we will walk the obligations, the regulatory crosswalk and the deployment that fits.