GLBA AI Audit Evidence for the Safeguards Rule Monitoring Element

An examiner picks a Tuesday afternoon and asks which employees sent customer information to an external model that day, what the policy allowed, and how the institution would have known if one of them had exfiltrated a client list through a prompt. Paragraph 314.4(c)(8) of the FTC Safeguards Rule requires controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information by those users. GLBA AI audit evidence either answers from a saved query, or the institution answers with an architecture diagram and hope.

I build the package so that someone who has never met the application developer can reproduce the population and the sample.

TL;DR

• Freeze a population of in-scope AI requests for a named window before sampling, and include permitted, redacted, denied and failed events in it.
• Tie the package to the specific elements the examiner will name: monitoring and logging at 314.4(c)(8), access limits at 314.4(c)(1), the written risk assessment at 314.4(b), and testing at 314.4(d).
• Show that customer information leaving toward a model endpoint is detectable, not merely encrypted in transit under 314.4(c)(3).
• Keep disposal under 314.4(c)(6) and the 30 day FTC notice under 314.4(j)(1) attached to the same record set, because both depend on knowing what the records contain.

Freeze the population first

Start with every in-scope HTTP AI request during a named window in a stated time zone. The population includes successful model calls, redactions, denials, policy failures, missing-identity errors and blocked responses. Building it from successful calls only removes exactly the events that prove the control ran.

The manifest carries a stable event identifier, timestamp, originating principal, calling application, model destination, policy version, action taken, data classification, and record location. Freeze it before sample selection, then let the examiner pick rows or document a repeatable selection method. Screenshots chosen by the control owner demonstrate a product. A frozen manifest with examiner-selected rows is evidence.

Section 314.4(b)(1) requires the risk assessment to be written and to include criteria for evaluating and categorizing risks, criteria for assessing confidentiality, integrity and availability including the adequacy of existing controls, and requirements describing how risks will be mitigated or accepted. Attach the population definition to that document so the scope of the evidence matches the scope of the assessed risk.

Bind each sample to a decision

Every selected event needs the identity assertion and its validation result, the model destination and route, the policy rule and version, the enforcement outcome, and what happened to the response. Section 314.4(c)(1) limits authorized users' access only to the customer information needed to perform their duties, so the evidence has to show the limit applied to a specific request by a specific person.

Watch the originating identity closely. A common pattern authenticates a loan officer in the application, then calls the provider through one shared service account, and the provider record shows only the relay. Joining the authentication event to the outbound request by correlation identifier is what makes the human recoverable eleven months later. The AI agent identity guide covers the design.

Where the record stores a fingerprint instead of prompt content, document the controlled retrieval path for the source and who may authorize it. A hash settles integrity questions and leaves content questions open.

Prove detection, not just transport encryption

Section 314.4(c)(3) requires encryption of customer information in transit over external networks and at rest. TLS on the outbound leg satisfies transport, and it tells an examiner nothing about whether the institution can see a social security number heading into a prompt. The evidence for (c)(8) is a detection rule, a triggering event, an alert, and a disposition.

Assemble four artifacts: the classification rules in force with their version, a staged test showing a customer-information pattern being detected and blocked or redacted, the resulting alert record, and the investigation note that closed it. Then show a second case that was allowed by policy, so the examiner can see that the control discriminates rather than blocking everything.

Run a tamper test as well. Alter one decision field on a copied event, execute the documented integrity check, record the failure output and the reviewer. Then attempt a modification as an application administrator against the protected store and record the rejection. The tamper-evident AI audit logs guide describes the write path those tests exercise.

Retention, disposal, and the 30 day clock

Section 314.4(c)(6)(i) requires secure disposal procedures for customer information in any format no later than two years after the last date it was used in connection with providing a product or service, unless it is necessary for business operations or other legitimate purposes, otherwise required to be retained, or targeted disposal is not reasonably feasible given how the information is maintained. Paragraph (c)(6)(ii) requires periodic review of the retention policy.

Prompt and response records containing customer information inherit that rule. The package should show the retention schedule for those records, the disposal job output, the exception reasoning where records are held longer for examination purposes, and evidence that the policy was reviewed. Test retrieval against the oldest available period rather than reading the configuration screen, and compare the returned record with its integrity value. The LLM audit log retention guide covers the design tradeoff.

Section 314.4(j)(1) requires notice to the FTC as soon as possible and no later than 30 days after discovering a notification event involving the information of at least 500 consumers, filed electronically on the form on the FTC's website. Paragraph (j)(2) treats an event as discovered on the first day it is known to any employee, officer or agent other than the person who committed the breach. Under 314.5, paragraph (j) has been effective since 13 May 2024. The evidence that matters here is a timed drill: how long it took to determine the affected consumer count from AI request records, and who signed the determination.

What the package cannot cover

Name the exclusions in the boundary section. Direct provider traffic from an unmanaged device, local model execution, browser sessions outside the enforced route, compromised endpoints, and inference embedded inside a vendor product where the call is invisible all sit outside a routed record set. So do the annual penetration test and semi-annual vulnerability assessments required by 314.4(d)(2) absent effective continuous monitoring, the service provider assessments under (f), and the annual written report to the board under (i).

Marking those edges makes the covered part more credible. An examiner who finds an unmarked gap starts questioning the parts you did document, which is a worse outcome than declaring the gap yourself.

DeepInspect

DeepInspect intercepts HTTP AI traffic between authenticated users or agents and LLM endpoints. On routed traffic it evaluates the identity and policy context the application supplies, classifies the request, applies a permit, redact or deny decision, inspects the response, and writes a signed per-decision record. For a Safeguards Rule file that produces a population export, examiner-selectable samples, integrity checks, saved queries, and historical retrieval against the monitoring element at 314.4(c)(8).

Identity proofing, enforced routing, endpoint controls, encryption key management, service provider due diligence, penetration testing, and the annual report to the board remain with their existing owners. The AI gateway for regulated industries guide covers where the enforcement point fits. Book a demo today.