StateRAMP AI Audit Evidence: Build a Package an Assessor Can Replay

A 3PAO selects one AI transaction and follows it through the authorization boundary. The StateRAMP AI audit evidence succeeds when that sample resolves to an authenticated caller, an approved model route, a prompt classification, the policy applied at that moment, the enforcement outcome, and a protected record. The program originally branded StateRAMP now publishes its requirements as GovRAMP, and its July 2026 Security Assessment Framework.pdf) uses NIST SP 800-53 Revision 5 for the assessment path.

I would build the evidence package around replay rather than document volume. A folder with polished policies and a broken event chain leaves the assessor doing archaeology across five consoles.

Start with the assessed AI boundary

The July 2026 GovRAMP System Security Plan asks providers to document the system description, boundary diagram, network diagram, data-flow diagram, ports, protocols, services, interconnections, inventory, and control responsibility matrix. For an AI-enabled SaaS product, the data-flow diagram should show the authenticated application, the HTTP policy point, the external or hosted LLM endpoint, and the audit store. Draw each trust crossing as a labeled arrow. A pale blue box around the assessed service and a red arrow leaving it for an external model gives the assessor an immediate visual test.

The boundary statement also fixes ownership. Application IAM supplies the originating identity. The AI request layer evaluates that identity against the model route and prompt content. The model provider handles inference. A separate record store preserves the decision. Local agent execution, endpoint compromise, stolen credentials, and direct traffic that bypasses the assessed route belong to adjacent controls and separate evidence.

This boundary artifact supports the GovRAMP SSP and frames every later sample. If a model endpoint appears in runtime records but sits outside the diagram and interconnections worksheet, the package has exposed a scope defect before the 3PAO has to find it.

Select a sample population the assessor can reproduce

NIST SP 800-53 Revision 5 places event logging under AU-2, content under AU-3, review under AU-6, protection under AU-9, and generation under AU-12. The sample population should therefore begin with all authenticated AI requests inside a defined assessment window, rather than a hand-picked set of successful calls.

Create a manifest with the window, source system, route, model endpoint, policy version, outcome, and record identifier. Include permitted, redacted, and denied events. Then let the 3PAO select identifiers from that manifest and retrieve the corresponding records. The selection method belongs in the package because a population fixed before sampling exposes any later omission of an inconvenient denial or malformed request.

My view is blunt: screenshots chosen by the control owner are demonstrations, not audit samples. The stronger pattern gives the assessor a population file and lets the assessor choose the rows.

Bind each event to identity and authorization

GovRAMP's current Revision 5 control matrix includes IA-2 for identification and authentication, AC-3 for access enforcement, and AC-6 for least privilege. For HTTP AI traffic, a useful event record names the originating person or agent, the application or relay, the assigned role, the requested model route, the policy version, and the permit or deny result.

The common failure occurs one layer after login. A government employee authenticates to a case-management application, and the application calls the LLM using one shared service credential. The model transaction now identifies infrastructure while the person who initiated it disappears. More SIEM retention preserves the substitution rather than repairing it.

A 3PAO sample should join the application authentication event to the outbound AI decision through a stable request identifier. The package should include the identity assertion format, validation rule, role-to-policy mapping, and one worked join. Upstream IAM remains responsible for proving the identity. The request-layer evidence proves what that authenticated identity was allowed to do with a specific prompt and endpoint.

Preserve the content and policy state needed for replay

AU-3 asks for event-record content sufficient to establish what occurred, when, where, the source, the outcome, and the identities involved. An AI transaction adds fields that generic web logs rarely carry: prompt classification, model destination, response disposition, and policy state at decision time.

The retained record should expose enough information to replay the decision without creating a second sensitive-data problem. Depending on the approved evidence design, that can mean protected prompt and response content, deterministic fingerprints with controlled source retrieval, or redacted content plus classification findings. The method has to match the control narrative and retention policy. A bare line reading POST /chat 200 proves connectivity.

Use one known test case in the package. For example, send a staged prompt containing a synthetic employee identifier through the assessed route, record the classification, and show the resulting redaction or denial. Include the exact UTC timestamp, model route, policy version, and linked response record. The 3PAO can then repeat the test against the same documented rule.

Prove custody and integrity

AU-9 protects audit information and audit tools against unauthorized access, modification, and deletion. This is where application-written AI logs become weak evidence. The application under assessment can select which paths it logs, alter records in its own trust domain, or crash after the model responds and before the audit write commits.

The package should document the writer, write path, signing or integrity mechanism, access roles, deletion permissions, retention configuration, and verification procedure. Include a tamper test. Change one copied field in a staged record and show the integrity check failing. Also include an access test demonstrating that an application administrator lacks permission to rewrite the audit store.

The strongest artifact is write-path independence: the enforcement point commits the decision record outside the calling application's custody. NIST supplies the protection objective through AU-9. The external write path is an implementation pattern, and the SSP should label it that way rather than presenting it as language copied from the control.

Demonstrate retrieval during continuous monitoring

CA-7 covers continuous monitoring, while AU-6 covers review, analysis, and reporting. GovRAMP's official document library publishes a Continuous Monitoring Guide, a matrix completion guide, and the monthly monitoring template alongside the Revision 5 packages. AI evidence should feed that operating process rather than appear only during the initial assessment.

Run a retrieval drill against a past UTC window. Ask for every AI request made by one principal, every call to one unapproved model route, and every denial under one policy version. Record the query, execution date, result count, reviewer, and disposition. The evidence is the completed review with follow-up, rather than a dashboard screenshot showing that logs exist.

Tie findings to the Plan of Action and Milestones process when remediation remains open. A newly observed endpoint can trigger inventory correction under CM-8, an interconnection update in the SSP, and a policy change on the request path. That chain shows the assessor that continuous monitoring changes system state.

Assemble the 3PAO package

I would give the 3PAO a package with a small, stable index:

The crosswalk should point each NIST control to the exact file and test result. AU-2 maps to event selection, AU-3 to record fields, AU-6 to review evidence, AU-9 to custody and integrity, AU-12 to record generation, IA-2 and AC-3 to identity-bound enforcement, CA-7 to recurring retrieval, and CM-8 to observed model inventory.

On 24 July 2026, GovRAMP published an AI Self-Reporting Addendum covering architecture, external models and APIs, data use, protections, administrative controls, audit visibility, model updates, risks, and limitations. Include the completed addendum as context. GovRAMP describes it as an initial due-diligence touchpoint, so the tested control evidence still carries the assessment.

DeepInspect

DeepInspect contributes the request-layer evidence inside this package. It sits between authenticated users or agents and HTTP-based LLM endpoints, evaluates application-supplied identity, role, prompt classification, model route, and policy state, then records the permit, redact, or deny decision. Each request and response can be tied to a signed, tamper-evident per-decision record written outside the calling application's write path.

That coverage supports the event, content, protection, access-enforcement, and monitoring evidence described above. IAM still establishes the principal, the service provider still owns the SSP and continuous-monitoring process, and the 3PAO still tests the complete GovRAMP boundary. Book a technical deep dive at deepinspect.ai.