IRS Publication 1075 AI Compliance Checklist for Authenticated LLM Traffic

The evidence folder contains a red FTI cover sheet beside a UTC export, plus a denied prompt showing a nine-digit taxpayer identifier replaced before transmission. That single screen determines if an agency or contractor, including a consolidated data center, receiving or processing federal tax information has a usable control record. The IRS Publication 1075 sets the programme obligation, while IRS Safeguards Program supplies the control or assessment method. A irs publication 1075 AI compliance checklist should connect those requirements to the authenticated HTTP request before the payload reaches an LLM.

I would rather show an IRS reviewer a denied test with its rule version than another policy page saying employees should be careful.

TL;DR

• Scope every AI route that can touch regulated data or a financially relevant workflow. Include the calling application, supplied identity, model destination, and bypass paths.
• Test authorization and information-flow policy with real requests rather than configuration screenshots. Use the same method for event content, record integrity, historical retrieval, and exception handling.
• Keep the boundary explicit. A gateway contributes to authenticated HTTP model traffic. Legal authority to receive FTI and disclosure accounting remain with their existing owners. So do employee awareness, physical storage, incident notification, and the safeguard review.
• 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, and the provider account and network route; the control owner and known bypass complete the row. The scope decision cites IRS Publication 1075 and records the rationale for inclusion or exclusion.

Evidence: approved inventory and route diagram, supported by a sample request and endpoint list. Include the provider contract reference and a dated sign-off. The diagram should show the application and inspection point as separate boxes, with the model endpoint and audit store also appearing 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; an unauthorized role is denied, while a request with missing or expired identity context fails closed. The event must preserve the originating person or workload rather than only the shared provider credential. NIST SP 800-53 Revision 5 provides the wider risk and control context for that test.

Evidence: identity schema and role mapping beside the policy version. Include three staged request results with 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.

Evidence: classification rule and route allowlist beside the permit event. Include the denial or redaction event, then identify the reviewer and exception ticket. Publication 1075 places access enforcement and information flow in the AC family; it places event content and review in AU, identity in IA, and boundary protection in SC. 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, along with every deny event and processing error. Each row carries the supplied identity and timestamp, the calling application and model destination, and the data classification and policy version; the action, response disposition, and stable event identifier complete the row.

Evidence: population manifest and record schema, supported by the protected-store permissions and integrity-test output. Include 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, linked policy, and exception disposition. A second exercise traces an unapproved destination attempt through triage and closure.

Evidence: timed retrieval result and the archive restoration step if one exists. Include the exception register and investigation notes, followed by 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, plus vendor-embedded inference that never crosses the governed route. Each excluded path has a named compensating control and owner.

Evidence: boundary register with endpoint and network control references. Include vendor assurance evidence and a residual-risk approval. Legal authority to receive fti and disclosure accounting remain outside the request gateway's control, as do employee awareness and physical storage; incident notification and the safeguard review itself also remain outside its control. 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, permits, redacts or denies it, then inspects the response and writes a per-decision record.

That record supports the checklist's authorization and information-flow tests, along with the population, integrity, and retrieval tests. It cannot govern calls that bypass the route or create upstream identity. It also cannot perform legal authority to receive FTI or disclosure accounting. Employee awareness and physical storage remain outside its role, as do incident notification and the safeguard review itself. Book a technical deep dive at deepinspect.ai.