StateRAMP AI Controls Mapping: Revision 5 Coverage at the LLM Boundary

An authenticated application sends an HTTPS request to an LLM. At that boundary, a StateRAMP AI controls mapping has to identify the NIST control objective, the component that implements it, the owner who operates it, the test that proves it, and the artifact the assessor receives. The program now publishes as GovRAMP, and the GovRAMP Security Program is based on NIST SP 800-53 Revision 5.

I will map the controls that materially touch the AI request path. Painting an entire Revision 5 workbook green because a gateway exists would be indefensible, and a Principal Engineer would spot the trick before the second row.

Mapping method

The current GovRAMP System Security Plan uses a Control Responsibility Matrix to distinguish inherited controls, service-provider implementation, and customer responsibility. Apply the same discipline to AI. Each row needs seven fields: control, objective, owner, implementation point, test, evidence, and coverage.

Coverage has three values in this map. Full means the mapped component can implement and evidence the selected objective for HTTP AI traffic routed through it. Partial means it contributes an artifact or enforcement step while another owner completes the objective. Outside means the objective sits beyond that component's technical boundary.

The scope here is the authenticated HTTP path between the calling application and the LLM endpoint. Application login, identity proofing, endpoint security, local agent execution, model training, vulnerability remediation, workforce policy, and legal notification remain adjacent work. The authorization-boundary diagram should make that separation visible with labeled boxes and arrows before the mapping table is reviewed.

Identity and access controls

NIST SP 800-53 Revision 5 places identification and authentication under IA-2, access enforcement under AC-3, least privilege under AC-6, and information-flow enforcement under AC-4. These controls meet at the outbound model call.

IA-2 begins with the upstream identity provider. The application or identity provider authenticates the person, while the AI request layer can validate and consume the resulting assertion. That makes gateway coverage partial. Full AC-3 coverage is possible for the routed AI transaction when the decision evaluates the originating principal, role, model route, operation, and policy state before forwarding. AC-6 remains partial because least privilege spans the application, cloud roles, model account, and administrative plane. Information-flow enforcement under AC-4 can be full for prompt flows the boundary inspects and partial for paths that bypass it.

The test should use an allowed principal, a disallowed role, and a request missing identity context. Evidence includes the identity assertion, validation result, policy version, route, and decision.

Audit and accountability controls

AI decisions create the strongest gateway contribution. AU-2 selects logged events, AU-3 defines record content, AU-6 covers review and analysis, AU-9 protects audit information, AU-11 governs retention, and AU-12 covers record generation.

For routed AI traffic, AU-2, AU-3, and AU-12 can receive full coverage when every relevant request and response produces a record containing the originating principal, relay application, model route, prompt classification, policy version, decision, timestamp, and response disposition. AU-9 can receive full coverage for the request-layer store when the calling application lacks custody over the write path and integrity verification detects modification.

AU-6 and AU-11 remain partial under this mapping. Security operations owns review, escalation, and follow-up. Records management and the system owner set the approved retention schedule. A gateway can provide searchable, protected events and enforce configured retention, while the organizational process completes those objectives.

Test one permit, one redaction, one denial, one tamper attempt, and one historical retrieval. The five linked artifacts should fit on a single evidence index page.

System and communications protection

SC-7 covers boundary protection and SC-8 covers transmission confidentiality and integrity. The AI request layer is one boundary inside the assessed service, especially when prompts leave for an external model API documented in the SSP interconnections worksheet.

SC-7 coverage remains partial at the HTTP AI boundary. An inline policy point can restrict approved LLM routes, reject unregistered destinations, and inspect requests at its own HTTP boundary. Network architecture, ingress controls, egress routing, segmentation, and bypass prevention belong to cloud and network owners. SC-8 is also partial because TLS configuration spans the client, proxy, provider endpoint, certificate validation, and supporting key management controls.

The evidence set should include the data-flow diagram, approved destination policy, denied unapproved route, TLS configuration, and network evidence showing that assessed workloads use the controlled path. A red arrow that quietly bypasses the policy box turns a full claim into partial coverage immediately.

Data protection and system monitoring

SI-4 covers system monitoring across assessed components. AC-4 information-flow enforcement and AU-3 event content carry much of the prompt-level evidence. GovRAMP's July 2026 AI Self-Reporting Addendum also asks providers to identify processed data classes, protections, redaction mechanisms, audit visibility, external models, and known limitations.

For HTTP requests routed through the control point, prompt and response inspection can provide full coverage for the selected monitoring mechanism and flow rule. Broader SI-4 coverage remains partial because host telemetry, container events, databases, queues, endpoint signals, and control-plane activity sit elsewhere. Data-governance obligations around collection, legal basis, deletion, records schedules, and training use also retain separate owners.

Use synthetic public, confidential, and regulated markers in staged prompts. The test should show classification, handling action, destination, response inspection, and the linked record. A source-file label alone leaves retrieval fragments and user-added text outside the test.

Inventory, assessment, and continuous monitoring

CM-8 covers system component inventory, CA-2 covers control assessments, CA-5 covers Plans of Action and Milestones, and CA-7 covers continuous monitoring. An AI gateway can observe model endpoints and agents that traverse it, producing a runtime inventory to reconcile with the SSP and approved interconnections.

That contribution is partial for CM-8 because hardware, software, databases, cloud services, and unobserved integrations remain in the system inventory. Control assessment under CA-2 belongs to the assessor and control owners. The system owner and remediation owners carry CA-5. Continuous-monitoring coverage under CA-7 remains partial because request-layer events form one monitoring source inside the broader GovRAMP program.

The official GovRAMP document library publishes the Revision 5 SSP, assessment packages, Continuous Monitoring Guide, matrix completion guide, and monthly reporting template. Evidence should show a dated destination reconciliation, an executed monitoring query, a finding, an assigned remediation item, and the later retest.

Incident response controls

IR-4 covers incident handling, IR-5 covers incident monitoring, and IR-6 covers incident reporting. Request-layer records help reconstruct which principal sent which classified content to which model under which policy. They can also show that a changed rule affected the next relevant call.

Coverage stays partial across this family. The incident-response team correlates gateway records with IAM, application, endpoint, cloud, provider, and network evidence. Legal and communications owners decide reporting. Forensic acquisition of a compromised workstation and investigation of stolen credentials sit outside the HTTP AI boundary.

Run a tabletop around a staged regulated-data request to an unapproved endpoint. The gateway evidence should identify the originator, relay, prompt classification, destination, policy decision, and response disposition. The broader incident record should add account status, endpoint evidence, containment, communications decision, remediation owner, and closure approval.

The control mapping

Full* applies only to authenticated HTTP AI traffic routed through the assessed enforcement point. The asterisk should stay in the SSP crosswalk. It prevents a narrow, defensible implementation claim from becoming an enterprise-wide claim during package review.

Controls outside the gateway contribution

The July 2026 GovRAMP framework still expects the complete selected baseline and package. AT controls for training, PL controls for plans, PS controls for personnel, PE controls for physical protection, MA controls for maintenance, CP controls for contingency planning, and most SA and SR activities keep their existing owners. RA-5 vulnerability monitoring and scanning reaches hosts, containers, libraries, and cloud services beyond prompt traffic.

Model governance also needs separate treatment. The AI Self-Reporting Addendum asks about model updates, rollback, training or tuning use, user notice, risks, and limitations. A request gateway can record the route and configured model version when the endpoint exposes it. Model evaluation, bias analysis, training-data provenance, contractual rights, and approval of model changes belong to product, legal, risk, and model owners.

My opinion is that the outside-scope column is the most valuable column in the mapping. It prevents one purchase from becoming a substitute for the work the GovRAMP assessment will still test.

Implementation sequence

Start with the GovRAMP verification boundary and responsibility matrix. Then carry originating identity to the outbound AI call, inventory observed model routes, classify prompt and response content, express approved use as per-request policy, and generate protected decision records. Continuous-monitoring queries and incident drills come after those dependencies are producing reliable fields.

On 24 July 2026, GovRAMP added the AI Self-Reporting Addendum to its official package resources. Use it as a disclosure cross-check. If the addendum names an external model API, that endpoint should appear in the interconnections worksheet, runtime inventory, route policy, audit records, monitoring queries, and incident scenario. One disclosed integration should resolve through all six artifacts without changing names halfway through.

The resulting mapping is operational. Each row points to a component, named owner, repeatable test, retained artifact, and explicit gap.

DeepInspect

DeepInspect supplies the narrow gateway contribution marked in this mapping. It sits between authenticated users or agents and HTTP-based LLM endpoints, validates application-supplied identity context, evaluates role, prompt classification, destination, operation, and policy version, and applies the permit, redact, or deny decision inline. It also inspects the response and writes a signed, tamper-evident per-decision record outside the calling application's write path.

That mechanism supports selected AC, AU, SC, SI, CM, CA, and IR evidence for traffic routed through it. IAM, network architecture, system inventory, vulnerability management, workforce controls, model governance, legal reporting, and the complete GovRAMP authorization package remain with their named owners. Book a technical deep dive at deepinspect.ai.