FISMA AI Compliance Checklist for Authenticated LLM Traffic

A reviewer has a six-inch assessment binder open beside a laptop showing one model request with a missing user field. That single screen determines if a federal agency information system or an information system used or operated by a contractor on the agency's behalf has a usable control record. The 44 U.S.C. 3554 sets the programme obligation, while NIST SP 800-53 Revision 5 supplies the control or assessment method. A fisma AI compliance checklist should connect those requirements to the authenticated HTTP request before the payload reaches an LLM.

My view is blunt: an authorization package that cannot name the person behind an LLM call has documented the relay and missed the decision.

TL;DR

• Scope every AI route that can touch regulated data or a financially relevant workflow. Record the calling application, supplied identity, model destination, and bypass paths.
• Test authorization and information-flow policy with real requests. Verify event content, record integrity, historical retrieval, and exception handling instead of relying on configuration screenshots.
• Keep the boundary explicit. A gateway contributes to authenticated HTTP model traffic. Security categorization, authorization decisions, endpoint controls, contractor oversight, incident reporting, and physical protection remain with their existing owners.
• Retain the policy version and decision beside the event so a reviewer can reproduce what happened at that point in time.

Check 1: freeze scope and ownership

Owner: the programme lead with the system owner.

Pass condition: the inventory names every application and agent that can send in-scope information to an LLM. Each row identifies the business purpose and authenticated principal type; the model endpoint and data class; the provider account and network route; the control owner and known bypass. The scope decision cites 44 U.S.C. 3554 and records the rationale for inclusion or exclusion.

Evidence: approved inventory and route diagram; sample request and endpoint list; provider contract reference and a dated sign-off. The diagram should show the application and inspection point, with the model endpoint and audit store as separate boxes. This is where an opaque vendor feature gets marked as opaque rather than quietly counted as covered.

Check 2: test identity and request authorization

Owner: IAM with the AI platform owner.

Pass condition: an authorized user can reach the approved model route, while an unauthorized role is denied. A request with missing identity context fails closed, as does one with expired identity context. The event must preserve the originating person or workload rather than only the shared provider credential. NIST SP 800-37 Revision 2 provides the wider risk and control context for that test.

Evidence: identity schema and role mapping; policy version and three staged request results; timestamps and correlation identifiers joining upstream authentication to the outbound model call. The AI agent identity guide explains why a service account alone leaves a weak attribution trail.

Check 3: enforce the information boundary

Owner: the regulated data owner with security engineering.

Pass condition: the route blocks or redacts a staged sensitive field sent to a disallowed model endpoint and records a permitted equivalent on an approved route. The test uses synthetic content and names the expected outcome before execution. The selected controls come from AC-3 Access Enforcement and AC-4 Information Flow Enforcement; AU-2 Event Logging and AU-3 Content of Audit Records; AU-6 Audit Record Review and IA-2 Identification and Authentication; and SC-7 Boundary Protection.

Evidence: classification rule and route allowlist; permit event and denial or redaction event; reviewer and exception ticket. A control description without its failed test belongs in design documentation, not in a completed checklist.

Check 4: prove the record is complete and protected

Owner: security operations with internal audit or compliance testing.

Pass condition: every staged permit and redact event appears in one frozen population, together with every deny and processing error. Each row carries the supplied identity and timestamp; the calling application and model destination; the data classification and policy version; the action and response disposition; and a stable event identifier.

Evidence: population manifest and record schema; protected-store permissions and integrity-test output; and the query used to reproduce the export. The tamper-evident audit log guide covers the custody mechanics behind this check.

Check 5: test retrieval and exception handling

Owner: records management with the incident or audit lead.

Pass condition: a reviewer selects an event from the oldest available period and the team returns the original row with its integrity result, plus the linked policy and exception disposition. A second exercise traces an unapproved destination attempt through triage and closure.

Evidence: timed retrieval result and archive restoration step if one exists; exception register and investigation notes; and closure approval. The LLM audit log retention guide separates configured retention from evidence that old records can actually be recovered.

Check 6: record boundaries and compensating controls

Owner: the system owner with enterprise architecture.

Pass condition: the file lists direct browser traffic and local model execution; unmanaged devices and compromised sessions; and vendor-embedded inference that never crosses the governed route. Each excluded path has a named compensating control and owner.

Evidence: boundary register and endpoint control references; network control references and vendor assurance evidence; and a residual-risk approval. Security categorization and authorization decisions remain outside the request gateway's control. The same applies to endpoint controls and contractor oversight, as well as incident reporting and physical protection. Marking those limits makes the checklist defensible.

DeepInspect

DeepInspect operates between authenticated users or agents and HTTP-based LLM endpoints. For routed traffic it evaluates the identity and policy context supplied by the application, classifies the request, applies permit or blocking actions through redaction or denial, inspects the response, and writes a per-decision record.

That record supports the checklist's authorization and information-flow tests, plus its population, integrity, and retrieval tests. It cannot govern calls that bypass the route or create upstream identity. It also cannot perform security categorization or authorization decisions. Endpoint controls and contractor oversight remain separate, as do incident reporting and physical protection. Book a technical deep dive at deepinspect.ai.