The security boundary · stated with engineering precision

Don’t send FCI/CUI into another compliance repository.

Keep sensitive data in your controlled environment. Measurement reads configuration metadata through scoped, read-only roles in your own cloud tenants and brings back only the configuration metadata needed to establish compliance state, each API response stored with its SHA-256 hash. Evidence integrity is established cryptographically, and every authorized seat (your team, your assessor, your prime, your program office) reads from the same recorded state, limited to what that seat shows and what you granted.

Sensitive customer information remains within the customer’s controlled environment; the readiness plane receives only the authorized configuration telemetry necessary to establish compliance state. The architecture is designed so FCI/CUI does not need to enter the central readiness plane.

That sentence is generated by the platform from its own code (services/cmmc_boundary.py) and served live at /api/v1/cmmc/boundary, together with the FIPS sentence the running cryptographic module is actually entitled to. It is deliberately not an absolute. An unconditional guarantee would be a claim about every future change; this is a claim about the design as built, and the design is checked by tests that run in CI on every pull request and every push to the main branch: no scanner calls any of a named list of content-reading API calls, every free-text intake field carries a warning not to enter CUI and says what to enter instead, and the one integration that hands findings to another system excludes the raw provider responses.

Where measurement runs

In the readiness plane, hosted in United States regions, against configuration metadata read through read-only roles and permissions you grant and can revoke at any time: AWS through an inline, configuration-metadata-only policy with no s3:GetObject, Azure Reader and Security Reader, Microsoft Graph read-only application permissions (one of them, SharePointTenantSettings.Read.All, is broad enough under Microsoft’s permission model to read SharePoint content; no scanner makes a content-reading call), the Google Workspace read-only Directory scope, an Okta read-only API token, CrowdStrike read scopes. The platform runs in the readiness plane, not in your tenant; it is not an appliance you host. What it reads is the state of your controls, never the things those controls protect.

What crosses the boundary, and what never does

Crosses into the readiness plane

AWS

  • IAM user names, attached policy names and MFA devices per user; the account password policy settings
  • S3 bucket names; each bucket’s Public Access Block and default encryption settings and its bucket policy (read to check that it requires TLS)
  • CloudTrail trail configuration and logging status; GuardDuty detector state; whether Amazon Inspector, Security Hub and AWS Config recording are on
  • SSM managed-instance records (instance ID, computer name, IP address, platform) and each instance’s missing or failed patch counts; EBS encryption by default
  • Security group rules, subnets and route tables; AWS Backup plan and vault lists; KMS key IDs and key metadata (who manages the key, whether it is enabled)

Azure & Microsoft 365

  • Account names; Conditional Access policies and security defaults; role assignments; MFA registration per user; last sign-in dates
  • Storage account encryption, network security group rules, Key Vault, backup vault, Azure Policy and Defender for Cloud settings; Activity Log diagnostic settings
  • Audit-log retention settings (requested; Microsoft does not document this read, and nothing is measured from it today); SharePoint sharing settings; Intune policies; managed-device names and compliance state

Google, Okta, CrowdStrike

  • Account names; 2-Step Verification enrolment; last-login dates; super-admin assignments
  • Admin MFA enrolment; password, sign-on and session policy settings; System Log stream configuration
  • Falcon host counts; prevention-policy settings
Never crosses
  • File and object contents (S3 objects, Drive files, SharePoint and OneDrive items)
  • Mailbox and message contents (Exchange, Gmail, Teams, chat)
  • Database rows and query results
  • Secret values, parameter values, credentials
  • CloudTrail event records; no log event payload is stored (the Microsoft 365 connector reads a sample of up to 100 Entra ID directory-audit records only to count how many name the user who acted, and keeps the counts)
  • Endpoint file contents or real-time-response command output

The tests that enforce this list forbid a named list of content-reading API calls (object reads, mail, files, chat, secret and parameter values); a scanner that called one would fail those tests in CI.

Cryptography, stated exactly

Cryptography uses FIPS-approved algorithms (AES-256-GCM, SHA-256, HMAC-SHA-256, Ed25519, TLS 1.2+). The module executing them is not operating in FIPS mode and holds no CMVP certificate, so this deployment does not claim FIPS-validated cryptography. NIST SP 800-171 3.13.11 attaches to cryptography protecting CUI; this platform stores, processes and transmits no CUI.

Evidence certificates are sealed with SHA-256 over canonical content and signed with Ed25519 when a signing key is provisioned, and reported as sealed-but-unsigned otherwise, never faked. The audit log refuses UPDATE, DELETE and TRUNCATE at the database and is hash-chained, so removal or alteration is detectable, not merely forbidden.

Verify it yourself

The AWS role the scanner assumes grants exactly these read-only actions and nothing else, so AWS denies any other call it makes:

The same list is in the role template, /aws/cmmc-readonly-role.yaml (template version 1.2.0), which you can check against your own IAM configuration. A stack created from version 1.1.0 grants only the first ten, and keeps them until you update the stack with the current template; its TemplateVersion output shows which version you have. In AWS your own CloudTrail records every call the role makes. The verification public key is at /evidence/public-key, and /verify checks any certificate or point-in-time posture statement you are handed.

Who is responsible when the AI is wrong →  ·  What each seat sees →  ·  Pricing →

Enclave AI™ · ElasticD3M, LLC · Patent Pending · ai4cmmc.ai