Security by sovereignty. Sealed, attested, offline.
8 control domains, 44 specific controls, enforced by architecture inside the Mickai Sovereign Intelligence Operating System. It runs air-gapped on hardware you own with zero data egress. Every action is signed before it executes and sealed to a post-quantum Open Audit Record under FIPS 204 ML-DSA-65, verifiable offline in any browser with the operator public key alone. The keys that sign each decision are held by the operator in TPM 2.0, a secure enclave or an HSM, never escrowed to a vendor. The largest attack surface in conventional AI, the path to a vendor, is removed.
What is the Mickai security model?
Mickai's security model is sovereignty by architecture. The Sovereign Intelligence Operating System runs on hardware the customer owns, air-gapped by default with zero data egress, so the largest attack surface in conventional AI, the network path to a vendor, is removed by construction. Every action is signed before it executes and sealed to a tamper-evident, post-quantum Open Audit Record under FIPS 204 ML-DSA-65, hardware identity is attested through TPM 2.0 and measured boot, and a dedicated agent-safety layer quarantines prompt injection and intercepts destructive actions. The operator holds the keys.
How does Mickai defend against prompt injection and unsafe agent actions?
Sentinel, the perimeter subsystem, inspects every input and tool call, quarantines injection attempts, and intercepts destructive commands such as rm -rf, --force and --accept-data-loss before they commit. High-impact actions pass a deterministic dry-run simulation and, where governance requires, a voice-biometric quorum, while every tool call passes a per-skill clearance gate in MickaiClaw. Because the system runs behind the firewall with a gated egress perimeter, an injected instruction has nowhere to exfiltrate to, and every decision is sealed to the audit record for review.
Who holds the encryption keys and the audit trail?
The operator does. Keys are generated and held on the customer's own hardware in a TPM 2.0 device, secure enclave or HSM, encrypted at rest, and never escrowed to Mickai or any cloud. The Open Audit Record ledger is the customer's own, verifiable offline with the operator public key alone in the browser verifier, so security and accountability sit with the organisation that bears the liability, not a vendor.
Can a reader verify a Mickai decision without trusting Mickai?
Yes. The offline audit verifier at /audit-verifier checks hash linkage and FIPS 204 ML-DSA-65 signatures entirely in the browser. Once the operator public key has loaded, it never touches the network, so a regulator, an auditor or a counterparty can independently confirm that a decision was genuine with no Mickai server in the loop. This is what turns an internal log into evidence.
Found something? Tell us directly.
Mickai welcomes good-faith security research. Report suspected vulnerabilities to micky@mickai.co.uk with enough detail to reproduce the issue. We acknowledge reports within two working days, keep you informed while we investigate, and credit researchers who wish to be named once a fix ships. Please act in good faith: no data exfiltration, no service disruption, and no disclosure before we have had a reasonable window to remediate. A machine-readable policy is published at /.well-known/security.txt (RFC 9116).
This is the security a serious buyer signs off on.
Every claim on this page is enforced by architecture, not policy, and provable offline. When you want to see it running and read the numbers behind it, request a briefing or read the investor case.