SELinux enforcing
Mandatory access controls remain active, with policy changes documented rather than broadly disabling enforcement.
Secure by baseline, explicit by evidence
A RHEL foundation built for customer-specific hardening.
Mimir’s reference appliance is designed for a Red Hat Enterprise Linux 9 operating-system baseline, with SELinux enforcing, least-privileged container patterns where practical, system-wide cryptographic policy, controlled services, and a documented path to customer-specific hardening and STIG tailoring.
Precise claims over broad labels
A hardened host is a foundation—not an automatic authorization.
STIG status, FIPS requirements, cryptographic validation, CUI controls, and an authorization to operate apply to defined versions, configurations, components, and boundaries. The deployment plan identifies the evidence and tailoring work without claiming that one operating-system setting makes the entire system compliant.
01 / RHEL baseline
Choose a baseline security teams already understand.
RHEL 9 provides the supported operating-system foundation for the Mimir appliance pattern. A customer-specific baseline can use SELinux enforcing, system-wide crypto policies, signed package and container sources, host firewall controls, least functionality, audit configuration, time synchronization, account policy, and documented service exposure.
Application, vector database, relational database, and local-model services are packaged as a controlled Podman stack. Exact privileges, network bindings, storage paths, secrets, and service accounts are reviewed against the final architecture instead of assuming that containerization alone provides isolation.
Least functionality
Installed packages, enabled services, listening ports, and administrative tools are limited to the delivered mission need.
Controlled supply chain
Operating-system, container, model, and application artifacts are inventoried and transferred from approved sources.
Supportable operations
The baseline preserves a documented patch, backup, recovery, logging, and troubleshooting approach for disconnected sites.
02 / STIG alignment
Hardening is mapped to the actual deployment boundary.
DISA publishes separate security technical implementation guides for operating systems, container platforms, applications, databases, network devices, and other technologies. A RHEL scan cannot establish the compliance of an entire AI system. Mimir therefore describes its baseline as STIG-aligned and identifies which guides, versions, automated checks, manual checks, exceptions, and customer decisions apply.
Delivery evidence can include an OpenSCAP report, configuration record, software and image inventory, exposed-interface list, remediation notes, accepted exceptions, and manual validation checklist. The customer and authorizing stakeholders determine the final control implementation and acceptance posture.
Named benchmark
The hardening record identifies the exact guide and version used rather than relying on a generic 'STIG-ready' label.
Automated evidence
Where a reliable machine check exists, scan output and remediation status are retained with the delivery record.
Manual validation
Requirements that depend on mission context, external systems, or human procedure are explicitly identified for review.
Boundary tailoring
Authentication, audit retention, network controls, backup, removable media, and support paths are tailored to the site.
Mimir does not claim blanket DoD approval, an automatic ATO, or whole-system STIG compliance. Those determinations belong to a defined implementation and authorization process.
03 / Post-quantum path
PQC-capable where RHEL and the protocol path support it.
NIST finalized its first post-quantum cryptography standards in 2024. RHEL 9 has since introduced an optional post-quantum cryptographic policy subpolicy and expanded algorithm support in selected libraries and applications. Mimir can use a compatible RHEL release and configured policy as the operating-system foundation for supported paths.
That capability is deliberately scoped. Both ends of a connection, the library, protocol, application, key and certificate lifecycle, and site policy must support the selected algorithm. Enabling a system policy does not make every application post-quantum, does not replace an algorithm inventory and migration plan, and does not by itself establish FIPS validation.
Inventory first
Identify cryptographic use across data in transit, data at rest, signing, identity, updates, backups, and external integrations.
Supported paths
Record which RHEL version, library, protocol, peer, and application combination is configured and tested for PQC.
Crypto agility
Preserve the ability to update policies, keys, certificates, libraries, and dependent applications as standards mature.
Evidence, not implication
Report the tested path and limitations rather than applying a whole-product 'PQC compliant' label.
Continue the mission thread
See how the pieces work together.
Related capability
System architecture
Trace the source-to-answer flow, service boundary, identity path, logs, storage, and disconnected release chain.
Related capability
Air-gapped AI
See how operational independence, sovereign data, support, and updates are planned across the boundary.
Related capability
STIG terminology guide
Read the practical difference between STIG-aligned, hardened, assessed, and compliant language.
Plan the deployment
Bring the mission and the constraints. We’ll map the system to both.
A Mimir briefing covers the operating boundary, approved knowledge, deployment pattern, security evidence, and the people the system is intended to support.