docs/additional-documents/COMPLIANCE.md

Compliance & Standards Readiness

mona-agent is the open-source client for the mona.expert cloud. This document summarizes how the architecture maps to common compliance frameworks. Detailed mappings live in the sibling documents of this folder.

Architecture in one paragraph: a lightweight device daemon holds no secrets and no model weights; it authenticates to the cloud over TLS with a single device key, polls for work, receives reasoning decisions from the cloud brain, executes tools locally behind an allowlist, and streams results back. All LLM provider keys are stored AES-256-GCM encrypted on the server, never on the device. Every run is audit-logged with per-step usage, tokens, cost and timing.

Framework alignment at a glance

Framework	Scope	How mona-agent aligns
EU CRA (Cyber Resilience Act)	Products with digital elements	SBOM-ready, signed releases, documented vulnerability handling, secure-by-default device, free security updates for the support window — see CRA-READINESS.md
ISO/IEC 27001	Information security management	Documented controls mapping (Annex A), crypto, access control, logging, incident handling — see ISO-27001-MAPPING.md
IEC 62443	OT / industrial automation security	The daemon as an embedded device component: least privilege, no default credentials, integrity checks, patch path — see IEC-62443.md
NIS2 / KRITIS	Critical infrastructure operators	Operator-side documentation: inventory, incident reporting hooks, supply-chain data
GDPR	Personal data	Data minimization (device metrics only), user-scoped data isolation, export & deletion endpoints, encryption at rest for secrets
SOC 2 (Type II readiness)	Trust services criteria	Audit trail completeness, access controls, change management evidence, availability monitoring

Security properties that matter for auditors

1. No inbound ports on devices. The daemon polls HTTPS every 2 s. Nothing can reach the device from the internet.
2. One key, one brain. The device key proves device identity; LLM provider keys live encrypted on the server and are never shipped to devices.
3. TLS everywhere. All control and data traffic is HTTPS with certificate verification (no TLS bypass, no insecure fallback).
4. Tool sandboxing. Shell execution runs against an explicit command allowlist (blocked by default); file access is confined to a workspace root with path-traversal rejection; web access validates URL schemes.
5. Complete audit trail. Every chat message, brain step, tool call, tool result, token count, cost and latency is stored and exportable (JSONL) — including per-step reasoning for incident reconstruction.
6. Self-healing operation. Transient failures retry with backoff, malformed brain replies trigger corrective nudges, stranded tasks expire with a closing message instead of replaying days later.
7. Rate limiting & plan separation. Free and Pro plans enforce request limits per user and per device.

Useful reading

• THREAT-MODEL.md — STRIDE analysis of the cloud-brain architecture
• DATA-FLOW.md — where data lives, moves, and is minimized
• SECURITY-AUDIT.md — self-assessment checklist for adopters
• DEPLOYMENT-GUIDE.md — enterprise rollout (launchd/systemd, proxies, updates)
• ENTERPRISE-FAQ.md — procurement questions and answers