Q&A: CMMC Domain Architecture — Mapping AI Agents to All 14 Practice Domains

[AGI-Corporation]

Overview

This Q&A maps the CMMC 2.0 framework's 14 practice domains to our AI agent architecture, clarifying how each compliance area is automated, monitored, and reported using the AGI-Corporation/CMMC agent stack.

---

Q1: How are the 14 CMMC domains organized across agent responsibilities?

A1: Each CMMC domain is handled by a specialized sub-agent that owns validation, evidence collection, and gap reporting for that domain:

Domain	Agent Role
AC – Access Control	AccessControlAgent — enforces least-privilege, monitors user/device auth
AT – Awareness & Training	TrainingAgent — tracks completion, flags overdue certifications
AU – Audit & Accountability	AuditAgent — streams logs to tamper-evident store, generates reports
CA – Assessment & Authorization	AssessmentAgent — runs periodic scoring against NIST SP 800-171
CM – Configuration Management	ConfigAgent — diffs baseline configs, flags unauthorized changes
IA – Identification & Authentication	IdentityAgent — validates MFA, PKI, and credential hygiene
IR – Incident Response	IRAgent — triggers playbooks on threat detection
MA – Maintenance	MaintenanceAgent — schedules and audits system maintenance windows
MP – Media Protection	MediaAgent — tracks removable media, enforces encryption policies
PE – Physical Protection	PhysicalAgent — interfaces with badge/sensor APIs (stub for on-prem)
PS – Personnel Security	PersonnelAgent — monitors onboarding/offboarding, access revocation
RA – Risk Assessment	RiskAgent — runs continuous threat modeling, scores residual risk
SA – System & Comm. Protection	NetworkAgent — monitors traffic, enforces segmentation rules
SI – System & Information Integrity	IntegrityAgent — runs hash checks, AV sweeps, patch status monitoring

---

Q2: How does the orchestrator coordinate all 14 domain agents in a single assessment run?

A2: The CMMCOrchestrator maintains a shared state graph (similar to Route.X's dynamic world-state). On assessment trigger:

1. All domain agents are invoked in parallel via async task queue
2. Each agent writes findings to the shared compliance_state.json
3. The AssessmentAgent aggregates scores into a single SPRS (Supplier Performance Risk Score)
4. The AuditAgent seals the run into an immutable evidence package

---

Q3: What does the MCP integration look like for CMMC evidence collection?

A3: Each domain agent exposes its capabilities as an MCP tool via Route.X. This means:

• Compliance checks can be triggered remotely from any LLM with MCP access
• Evidence bundles can be requested on-demand via natural language: "Run an AC domain audit and return the gap report"
• Results pipe back into the Sapient.x spatial dashboard as geo-tagged compliance overlays per parcel/facility

---

Q4: How do we handle the gap between Level 1 (17 practices) and Level 2 (110 practices)?

A4: The framework uses a tiered activation model:

• CMMC_LEVEL=1 activates only the 17 foundational practices across AC, IA, MP, PE, SI
• CMMC_LEVEL=2 activates all 110 practices across all 14 domains
• Agents are conditionally loaded at startup based on the env config, keeping Level 1 deployments lightweight

---

Q5: How does the CMMC stack integrate with the guardrails- framework?

A5: The guardrails- repo provides a safety wrapper layer deployed as a sidecar to all CMMC agents. Any LLM-generated compliance recommendation passes through the guardrail engine before being written to compliance_state.json. This prevents:

• Hallucinated compliance scores being stored as authoritative
• PII exfiltration via audit log outputs
• Prompt injection in natural-language assessment requests

See: AGI-Corporation/guardrails- → Governance and Threat Model wiki page for the full policy YAML definitions.