Important Disclaimer
osModa is not SOC 2 certified and is not a HIPAA-covered entity. This guide explains how osModa's infrastructure features map to specific compliance control requirements. Achieving SOC 2 or HIPAA compliance requires organizational policies, procedures, and controls that go beyond infrastructure. Consult your compliance team and a qualified auditor for your specific situation.
When AI agents handle customer data, process health records, or make autonomous decisions in regulated industries, the infrastructure hosting those agents becomes subject to compliance scrutiny. Auditors look at how your AI systems log their actions, how data is encrypted, how changes are managed, and how availability is maintained. In 2026, the AICPA's updated Trust Services Criteria include specific expectations for AI-powered systems, and the January 2025 HHS proposal to update the HIPAA Security Rule for the first time in 20 years signals stricter enforcement of technical safeguards.
This article covers the specific SOC 2 and HIPAA requirements that apply to AI agent hosting infrastructure, maps osModa's features to those requirements, and identifies the gaps you need to fill with organizational controls. The goal is factual accuracy, not marketing claims.
SOC 2 Type II: What It Requires From AI Infrastructure
SOC 2 Type II evaluates an organization's controls against the AICPA's Trust Services Criteria over a period of time (typically 6-12 months). The five trust service categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. For AI agent infrastructure, the most relevant criteria fall under Security, Availability, and Processing Integrity.
In 2026, auditors evaluate AI-specific controls more rigorously. They look for change management evidence for AI-driven changes including documented requests, approvals, validation evidence, and rollback plans. If an AI system updates production without a ticket, test artifacts, or a documented rollback procedure, it can conflict with change management expectations. The 2026 Trust Services Criteria require tamper-evident logging with real-time integrity verification.
2026 best practices demand real-time dashboards that flag control deficiencies in under 48 hours. Continuous monitoring is no longer a nice-to-have — it is an expectation.
HIPAA Technical Safeguards for AI Agent Infrastructure
HIPAA's Security Rule defines technical safeguards that apply to any system that creates, receives, maintains, or transmits electronic protected health information (ePHI). On January 6, 2025, the HHS Office for Civil Rights proposed the first major update to the HIPAA Security Rule in 20 years, citing the rise in ransomware and the need for stronger cybersecurity.
The proposed updates reduce flexibility by setting clearer expectations for safeguards. Controls related to access management, audit logging, encryption, and system monitoring are increasingly treated as baseline requirements rather than optional addressable specifications. For AI agents processing healthcare data, this means encryption and audit logging are effectively mandatory.
The four HIPAA technical safeguard categories most relevant to AI agent hosting are:
Access Controls (164.312(a))
Implement technical policies and procedures that allow only authorized persons to access ePHI. This includes unique user identification, emergency access procedures, automatic logoff, and encryption/decryption mechanisms.
Audit Controls (164.312(b))
Implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Access logging must capture every model query, data access, and system change with immutable audit trails.
Integrity Controls (164.312(c))
Implement policies and procedures to protect ePHI from improper alteration or destruction. This includes mechanisms to authenticate ePHI and verify that data has not been altered or destroyed in an unauthorized manner.
Transmission Security (164.312(e))
Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. This includes integrity controls and encryption. Standards now include AES-256 at rest and TLS 1.2+ in transit.
Compliance Feature Mapping: osModa to SOC 2 & HIPAA Controls
The following table maps osModa infrastructure features to specific SOC 2 and HIPAA control requirements. “Supports” means the feature provides evidence or capability for the control. “Partial” means additional organizational controls are needed.
| Compliance Requirement | Framework | osModa Feature | Coverage |
|---|---|---|---|
| Tamper-evident audit logging | SOC 2 CC7.1-7.4 | SHA-256 hash-chained audit ledger | Supports |
| Audit controls for ePHI access | HIPAA 164.312(b) | SHA-256 audit ledger records all actions | Supports |
| Encryption in transit | SOC 2 CC6.1 / HIPAA 164.312(e) | Noise_XX + ML-KEM-768 P2P mesh | Supports |
| Encryption at rest | HIPAA 164.312(a)(2)(iv) | Dedicated server (configure disk encryption) | Partial |
| Change management | SOC 2 CC8.1 | NixOS declarative config + atomic rollback | Supports |
| System availability monitoring | SOC 2 A1.1-A1.2 | Watchdog daemon + auto-restart | Supports |
| Access controls for ePHI | HIPAA 164.312(a) | SSH key access + dedicated server | Partial |
| Data integrity verification | HIPAA 164.312(c) | NixOS config validation + hash-chain ledger | Supports |
| Incident response and recovery | SOC 2 CC7.3-7.5 | Watchdog recovery + audit ledger forensics | Supports |
| Reproducible system state | SOC 2 CC6.6 | NixOS reproducible builds + generations | Supports |
Audit Logging: The Foundation of Both Frameworks
Both SOC 2 and HIPAA treat audit logging as foundational. SOC 2 CC7.1 requires monitoring of system components and detection of anomalies. HIPAA 164.312(b) requires mechanisms that record and examine activity in systems containing ePHI. For AI agents, this is especially critical because agents make autonomous decisions that must be traceable.
osModa's SHA-256 hash-chained audit ledger addresses these requirements at the infrastructure level. Every action an agent takes — API calls, file operations, data access, external requests — is recorded as an immutable entry. Each entry includes a timestamp, action type, actor, resource, and outcome. Each entry's hash incorporates the previous entry's hash, creating a chain where any modification to any entry breaks the integrity of every subsequent entry.
The 2026 Trust Services Criteria specifically require tamper-evident logging with integrity verification. Hash-chained audit entries satisfy this requirement more rigorously than traditional append-only logs, because tampering with any entry is cryptographically detectable. For AI agents where autonomous actions need to be traced back to specific decisions, this level of auditability is essential. Learn more about the audit architecture on the tamper-evident audit log page.
Encryption: Beyond TLS
SOC 2 CC6.1 requires protection of information during transmission. HIPAA 164.312(e) requires technical security measures against unauthorized access to ePHI in transit. Most platforms satisfy these with standard TLS. osModa goes further.
The P2P mesh uses Noise_XX for the handshake protocol and ML-KEM-768 for post-quantum key encapsulation. Noise_XX provides mutual authentication and forward secrecy. ML-KEM-768 (formerly CRYSTALS-Kyber) is a NIST post-quantum cryptography standard that protects against harvest-now-decrypt-later attacks from future quantum computers. This is relevant for organizations handling data with long-term sensitivity — healthcare records, financial data, and government information.
For encryption at rest, osModa provides dedicated servers where you control disk-level encryption configuration. The current HIPAA standards reference AES-256 for data at rest and TLS 1.2+ for data in transit. osModa's Noise_XX + ML-KEM-768 exceeds the transit encryption requirement. Disk encryption is your responsibility to configure based on your HIPAA implementation plan. See the security hardening page for more details.
Change Management: NixOS as Compliance Evidence
SOC 2 CC8.1 requires documented change management procedures. Auditors want evidence that every change was requested, approved, validated, and has a rollback plan. For AI agent infrastructure, this is challenging because agents can modify system behavior autonomously.
NixOS declarative configuration provides built-in change management evidence. The entire system state is defined in version-controlled files. Every change produces a new system generation with a complete diff from the previous state. Rollback to any generation is atomic and takes seconds. This gives auditors exactly what they need: a complete, verifiable history of every system change with the ability to demonstrate rollback capability.
The combination of NixOS generations and the audit ledger creates a two-layer change record: the audit ledger tracks what agents did (application-level changes), and NixOS generations track how the system was configured (infrastructure-level changes). Together, they provide the comprehensive change management evidence that SOC 2 auditors evaluate. See atomic deployments and rollbacks for the technical details.
What osModa Does Not Cover
Compliance is an organizational achievement, not an infrastructure feature. osModa provides infrastructure controls, but the following are your responsibility:
Organizational Policies
SOC 2 and HIPAA require written security policies, risk assessments, incident response procedures, and employee training programs. osModa provides the technical infrastructure; you provide the organizational framework.
Application-Level Access Controls
osModa provides server-level access control (SSH keys, dedicated hardware). Application-level access controls — who can access what data within your agent application — are your responsibility to implement.
Business Associate Agreements
HIPAA requires BAAs with any entity that handles PHI on your behalf. If your AI agent calls external LLM APIs (OpenAI, Anthropic) with PHI, you need BAAs with those providers. BAA language should address the unique risks of AI model training and the minimum necessary standard.
Disk Encryption Configuration
osModa provides dedicated hardware where you have root access to configure disk encryption. Implementing AES-256 full-disk encryption for HIPAA data-at-rest requirements is your responsibility.
Frequently Asked Questions
Is osModa SOC 2 certified?
No. osModa is not SOC 2 certified. SOC 2 certification applies to organizations, not individual tools. What osModa provides is infrastructure features that map to SOC 2 Trust Services Criteria controls: tamper-proof audit logging (CC7.1-CC7.4), encryption in transit via Noise_XX + ML-KEM-768 (CC6.1), NixOS declarative configuration for change management (CC8.1), and watchdog monitoring for availability (A1.1-A1.2). Your organization uses these features as part of your broader SOC 2 compliance program.
How does the SHA-256 audit ledger satisfy SOC 2 logging requirements?
SOC 2 Trust Services Criteria CC7.1 through CC7.4 require organizations to monitor system components, detect anomalies, and evaluate security events. The SHA-256 hash-chained audit ledger records every agent action with immutable, tamper-proof entries. Each entry links cryptographically to the previous one, so any modification breaks the chain and is immediately detectable. The 2026 Trust Services Criteria specifically require tamper-evident logging with integrity verification — which is exactly what hash-chained entries provide.
Does osModa satisfy HIPAA encryption requirements?
osModa provides encryption in transit through the P2P mesh using Noise_XX + ML-KEM-768, which includes post-quantum resistance. The January 2025 HIPAA Security Rule update proposed by HHS increasingly treats encryption as a baseline requirement rather than an addressable specification. For data at rest, your osModa server runs on dedicated hardware where you control disk encryption. osModa provides the transport-layer encryption; you are responsible for configuring application-level encryption for PHI at rest based on your specific HIPAA implementation plan.
What HIPAA technical safeguards does osModa support?
osModa supports several HIPAA technical safeguards at the infrastructure level: audit controls (the SHA-256 ledger records all system and agent activity), person or entity authentication (SSH key-based access to dedicated servers), transmission security (Noise_XX + ML-KEM-768 encryption for inter-server communication), and integrity controls (NixOS declarative configuration prevents unauthorized system modifications). You are responsible for implementing access controls within your applications and maintaining Business Associate Agreements with relevant parties.
How does NixOS help with SOC 2 change management requirements?
SOC 2 CC8.1 requires documented change management procedures. NixOS declarative configuration means the entire system state is defined in version-controlled files. Every change is a commit with a message, reviewer, and timestamp. Deployments are atomic — they succeed completely or do not apply. Auditors can verify the complete change history for any system component by reviewing the Git log. This eliminates the gap between documented procedures and actual system state that is common with imperative configuration management.
Can osModa help with SOC 2 Type II continuous monitoring?
SOC 2 Type II evaluates controls over a period (typically 6-12 months), requiring evidence of continuous monitoring. The watchdog daemon provides continuous process monitoring and automatic recovery. The audit ledger provides a continuous, immutable record of all system and agent activity over the evaluation period. NixOS configuration validation continuously verifies system state against the declared configuration. Together, these provide the kind of continuous monitoring evidence that SOC 2 Type II auditors evaluate.
What about data residency for HIPAA compliance?
osModa servers run on dedicated Hetzner hardware. You know exactly where your server is physically located. For HIPAA compliance, this means you can ensure PHI processing occurs within your required jurisdiction. Unlike shared cloud platforms where data may move between regions, your osModa server stays on the specific hardware you provisioned. This simplifies data residency documentation for compliance audits.
How long does it take to prepare for a SOC 2 audit using osModa?
SOC 2 implementation typically takes 6-12 months including gap assessment, control implementation, testing, and formal audit. osModa accelerates the infrastructure controls portion by providing pre-built audit logging, change management through NixOS, and availability monitoring through the watchdog. The infrastructure features are available from day one. Your remaining work is organizational: writing policies, implementing application-level controls, training staff, and engaging an auditor. osModa does not replace the organizational requirements of SOC 2 — it provides the infrastructure evidence that supports them.