--- title: "NIST 800-53 AI Deployment: A Control-by-Control Architecture Walkthrough" slug: "nist-800-53-ai-deployment" author: "ibl.ai Engineering" date: "2026-06-01 20:15:00" category: "Premium" topics: "NIST 800-53 AI deployment, NIST AI controls, NIST 800-53 r5 AI, federal AI NIST compliance, NIST AI security controls, NIST 800-53 AI architecture, NIST control AI alignment, FISMA AI deployment" summary: "NIST 800-53 (Rev. 5) governs federal information systems. AI workloads inherit the security controls of the systems they sit inside. ibl.ai's self-hosted architecture maps directly to specific 800-53 control families — Access Control, Audit, Configuration Management, System Communications, System Integrity." banner: "" thumbnail: "" --- ## The Short Answer **NIST 800-53 compliant AI deployment requires the AI runtime, the model, and the data inside the agency's existing authorization boundary — where the 800-53 control set already applies.** ibl.ai's self-hosted architecture maps directly to specific 800-53 control families: AC (Access Control), AU (Audit), CM (Configuration Management), SC (System Communications), SI (System Integrity). Managed AI vendors add a new boundary the agency has to re-authorize. ## Why NIST 800-53 Demands a Specific AI Architecture NIST SP 800-53 (Rev. 5) is the security and privacy control catalog for federal information systems (and many state systems via StateRAMP). For AI workloads, the relevant controls cluster into five families: **1. Access Control (AC)** — who can interact with the AI; how authentication works; what data each user can see. **2. Audit (AU)** — what events are logged; where logs are stored; how long they're retained; how completeness is verified. **3. Configuration Management (CM)** — what versions of software / models / prompts are in production; how changes are reviewed and approved; how baselines are maintained. **4. System Communications (SC)** — how data is encrypted in transit; how trust boundaries are defined; how external connections are controlled. **5. System Integrity (SI)** — how monitoring is performed; how anomalies are detected; how the system is verified to operate as intended. A managed AI vendor partially satisfies each family — typically through SOC 2 / FedRAMP attestations. **They don't satisfy the requirement that the controls operate within the agency's own authorization boundary.** Self-hosted on the agency's infrastructure keeps the controls inside the agency's existing 800-53 scope. ## Control-by-Control: How ibl.ai's Architecture Maps to 800-53 ### Access Control (AC) - **AC-3 / AC-6 (Access Enforcement / Least Privilege)** — PIV/CAC authentication for human users; role-based access for service accounts; no vendor admin accounts in the runtime path - **AC-17 / AC-18 (Remote Access / Wireless)** — runtime accessed only through agency-controlled networks; no vendor remote-management connection ### Audit and Accountability (AU) - **AU-2 (Audit Events)** — every AI call (prompt, model version, input hash, output, decision flag, accessing user) logs as a configurable audit event - **AU-3 / AU-12 (Content of Audit Records / Audit Generation)** — logs include all 800-53 r5 required fields (timestamp, source, user ID, event type, outcome, resource accessed) - **AU-6 (Audit Review, Analysis, and Reporting)** — logs feed into the agency's existing SIEM; same review process as every other agency log source - **AU-9 (Protection of Audit Information)** — agency-controlled retention, encryption, integrity verification ### Configuration Management (CM) - **CM-2 (Baseline Configuration)** — agency pins runtime version, model version, prompt-template version; baseline is documented in agency's CM tooling - **CM-3 (Configuration Change Control)** — model swap or prompt-template change goes through agency's CCB; no vendor-pushed changes - **CM-8 (System Component Inventory)** — runtime, model artifacts, agent configurations all in agency's CMDB ### System and Communications Protection (SC) - **SC-7 (Boundary Protection)** — single audited boundary between the agency's runtime and the ibl.ai control plane (Ed25519-signed WebSocket); orchestration metadata transits, CUI/FOUO/classified payloads don't - **SC-8 (Transmission Confidentiality and Integrity)** — TLS 1.3 + Ed25519 signing; agency controls cert lifecycle - **SC-12 / SC-13 (Cryptographic Key Establishment / Cryptographic Protection)** — agency KMS / HSM; FIPS 140-2/3 validated ### System and Information Integrity (SI) - **SI-4 (Information System Monitoring)** — runtime monitoring inside agency's existing monitoring stack; no vendor monitoring required - **SI-7 (Software, Firmware, and Information Integrity)** — runtime binaries hashed + signed; model artifacts version-pinned; agent configurations version-controlled ## Deployment Tiers Mapped to System Classification | Authorization tier | Workload examples | ibl.ai deployment | |---|---|---| | **FedRAMP-Moderate** | Most administrative AI (FOIA, case management, citizen service) | Inside agency's existing FedRAMP-Mod GovCloud | | **FedRAMP-High** | Sensitive administrative + CUI | Inside agency's FedRAMP-High environment | | **CUI (NIST 800-171)** | Controlled Unclassified Information workloads | On-prem CUI environment; dedicated GPU | | **IL4** | DoD CUI | Air-gapped enclave; locally-hosted open-weight models only | | **IL5** | DoD higher-sensitivity | Fully air-gapped; no internet egress | For the staged-deployment recipe: **[Government AI Blueprint: GovCloud Pilot to IL4/IL5](/blog/government-ai-blueprint-govcloud-to-il4-il5)**. ## Why Managed AI Vendors Struggle With 800-53 at Sensitivity A managed AI vendor's FedRAMP authorization is *for the vendor's environment*. The agency still needs to authorize the *system* in *its* boundary. Three structural problems: **1. The vendor's release cycle isn't the agency's CCB.** CM-3 requires change control. The vendor pushes a model update on the vendor's schedule; the agency's CCB wasn't consulted. Either the agency pauses the workload or accepts uncontrolled change. **2. Sub-processors expand the boundary.** SC-7 requires defined boundary. The vendor's sub-processor list changes; the boundary changes. The agency may not be aware. **3. Audit logs live in the vendor's cloud.** AU-9 requires protection of audit information by the agency. Logs in a vendor cloud are protected by the vendor's controls, not the agency's. ## Run the Numbers - **[Air-Gapped AI for Federal Agencies](/blog/air-gapped-ai-for-federal-agencies)** — air-gapped deployment deep-dive - **[FedRAMP-High AI Alternative](/blog/fedramp-high-ai-alternative)** — broader gov-cloud-alternative argument - **[ChatGPT Gov Alternative](/blog/chatgpt-gov-alternative)** — direct alternative to OpenAI's Gov line - **[AI Cost Math for Government Agencies](/blog/ai-cost-math-for-government-per-seat-vs-usage)** — segment cost math - **[What AI FOIA Drafting Actually Costs in 2026](/blog/what-ai-foia-drafting-actually-costs-2026)** — per-request math - **[Government AI Reference Architecture on ibl.ai](/blog/government-ai-reference-architecture)** — full architecture with NIST mapping - **[Government AI Blueprint: GovCloud Pilot to IL4/IL5](/blog/government-ai-blueprint-govcloud-to-il4-il5)** — staged deployment recipe - **[Self-Hosted AI vs ChatGPT Enterprise for Government](/resources/comparisons/self-hosted-ai-vs-chatgpt-enterprise-for-government)** — deployment comparison ## Why Family-Owned and New York Matters Here For U.S. federal procurement, the structure of the AI vendor matters at the same level as the architecture. ibl.ai is **family-owned and operated from New York, NY** — a U.S.-headquartered, domestically-owned, long-term partner with a perpetual platform license. The runtime is open source. The 800-53 controls operate inside the agency's existing authorization boundary. The math works at a 500-employee municipal agency or a 50,000-employee federal department. NIST 800-53 compliant AI isn't a control-mapping spreadsheet. It's an architecture that keeps the controls where 800-53 requires them — inside the agency's own boundary.