IRS Publication 1075 AI Controls Mapping for the Authenticated LLM Path

The evidence folder contains a red FTI cover sheet and a UTC export beside 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 controls mapping 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 screenshots of configuration pages. Do the same 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, as do employee awareness, physical storage, incident notification, and the safeguard review itself.
• Retain the policy version and decision beside the event so a reviewer can reproduce what happened at that point in time.

Use six fields for every mapping row

Each row needs a requirement and control point. It also needs an owner and repeatable test, plus retained evidence and a boundary statement. IRS Publication 1075 supplies the programme requirement. IRS Safeguards Program provides the related control language, and NIST SP 800-53 Revision 5 supports the assessment or risk method.

The useful rows point to mechanisms rather than products. They say where the decision occurs and identify the input needed. They also give the expected result and artifact retained. The zero trust for AI guide takes the same approach across identity and policy controls with audit evidence.

Identity and access enforcement

Requirement: identify the originating user or workload and restrict each transaction to authorized roles and purposes.

Control point: the identity provider and calling application supply identity context; the inline request point validates it and evaluates policy.

Owner: IAM with the application owner.

Test: run authorized and unauthorized roles against the same model route, then repeat with an expired assertion. Confirm the expected result before the payload leaves the enterprise boundary.

Evidence: retain the authentication event and assertion schema, along with the role mapping and policy version. Keep the correlation identifier plus permit and denial events.

Boundary: proofing and account lifecycle stay upstream, as do session compromise and role design. The enforcement point evaluates what the application supplies.

Information flow toward the model

Requirement: govern in-scope information moving to external services and prevent unapproved destinations or data classes.

Control point: request classification and the route allowlist feed the policy engine before the LLM endpoint.

Owner: the data owner with security engineering.

Test: send synthetic regulated content toward approved and unapproved destinations. Confirm the expected permit or denial, including redaction where required, and capture each event.

Evidence: retain the classifier version and route policy, including the allowlist. Keep the test payload description and event identifiers. Record the reviewer and result.

Boundary: local models and unmanaged devices need endpoint or network controls, as do direct provider sessions. A request gateway sees only traffic that traverses it.

Audit record content and review

Requirement: record events with enough content to support monitoring and assessment, as well as investigation and accountability. Publication 1075 groups the applicable controls across access enforcement and information flow, event selection and review, user identification, and boundary protection.

Control point: the per-decision record writer and protected store.

Owner: security operations with the audit owner.

Test: freeze a population for a named UTC window and select a denial. Trace it to the originating principal and policy, then reproduce the query. Alter a copied row and confirm the integrity check fails.

Evidence: retain the manifest and sample row with the query and policy snapshot. Keep the integrity output and storage permissions beside the review sign-off.

Boundary: business outcomes and downstream application actions require correlated application records. The tamper-evident audit log guide describes the separate write path.

Change and exception control

Requirement: approve policy changes and limit emergency access while preserving evidence of exceptions.

Control point: the policy repository and deployment pipeline preserve the runtime rule version attached to each event.

Owner: AI platform engineering with the control owner.

Test: trace one rule from ticket to approval, then through deployment and staged testing. Connect it to production events and the rollback record. Repeat for a time-limited exception and confirm expiry.

Evidence: retain the ticket and review with the policy diff and deployment timestamp. Keep the test result and event sample, plus the expiry and closure sign-off.

Boundary: the gateway records its own policy state. Wider system changes and accounting judgments live in other systems, along with organizational approvals.

Incident and assessment support

Requirement: make evidence available for control assessment and incident analysis.

Control point: saved queries and exports from the protected event store, joined to identity and application records.

Owner: the incident lead or assessor with security operations.

Test: produce all events for one principal and one destination, filtered by one policy version and one sensitive classification in a named window. Time the exercise and record missing joins.

Evidence: retain the query catalogue and drill output with the elapsed time and gap register. Record the owners and retest result. The map should show the missing joins in red. Hiding them turns a useful control document into sales material.

Programme obligations outside the request path

Legal authority to receive fti and disclosure accounting sit outside the routed LLM transaction. The same applies to employee awareness and physical storage, along with incident notification and the safeguard review itself. Assign those obligations to the agency safeguard lead and tax information owner. Include the information security officer, IAM lead, and AI platform owner, then link their own procedures and evidence. Direct browser traffic and local inference also need explicit compensating controls, as do stolen credentials, unmanaged devices, and opaque vendor inference.

DeepInspect

DeepInspect operates at the authenticated HTTP boundary between users or agents and LLM endpoints. In this mapping it evaluates supplied identity and data context, enforces destination and information-flow policy, inspects responses, and writes per-decision records tied to the policy version that ran.

The organization still owns routing and identity proofing, along with endpoints and programme judgment. It also owns legal authority to receive FTI and disclosure accounting, plus employee awareness and physical storage. Incident notification and the safeguard review itself remain organizational responsibilities. Book a technical deep dive at deepinspect.ai.