What does the inspection layer do when the copilot retrieves pre-announcement earnings text into the prompt?

The classifier detects the MNPI-indicative text in the retrieval context. The policy evaluates the user's disclosure-committee working-list membership at the moment of the request. A user on the list passes and the record captures the MNPI classification. A user not on the list receives a block. The record carries both the classification verdict and the policy outcome.

How does the inspection layer handle the disclosure committee's working list?

The application supplies the working-list membership as a request attribute the inspection layer reads. The list is maintained by the corporate secretary or the general counsel's office through the directory or a custom attribute store. The policy reads the membership at request time and applies the rules accordingly.

Does the inspection layer change the user experience of the copilot?

The layer adds under 50 ms to the request path. The LLM inference takes 500 ms to 5 seconds, so the overhead is invisible. The user experience changes when the policy blocks or modifies. A block surfaces as a structured error the copilot UI handles. A modify surfaces as a redaction the user sees with an indicator that redaction happened.

How does the inspection layer integrate with the existing financial reporting controls?

The audit records feed the existing SOX 404 evidence repository alongside the IT general controls evidence. The policy authoring lives in the same change-management process as the other financial reporting controls. The inspection layer's classifier signals integrate with the existing DLP and SIEM through a shared signal bus.

What about copilots that read the executive compensation detail?

The policy treats executive compensation as a separate data class with its own access-control rule. The classifier detects the compensation-indicative text in the retrieval context. The policy evaluates the user's compensation committee membership or the user's specific role authorization. A user without the authorization receives a block. The record carries the classification and the policy outcome.

AI Security for Finance Back Office: The Identity, Data, and Audit Controls a Production Deployment Has To Run

Finance back-office copilots reach across the data surfaces the CFO's organization has been protecting from external disclosure since the company went public. The copilot reads the general ledger, the close calendar, the vendor master file with pricing terms, the pre-announcement earnings draft, and the executive compensation ledger. The data inside the prompt at any given moment crosses material non-public information thresholds, vendor confidentiality contracts, and the SOX 302 attestation territory the CEO and CFO sign every quarter. A model invocation that includes the draft 10-Q text in the prompt context, routes through a vendor LLM whose training-data exclusion the legal team has not verified, and writes a derived analysis back into the analyst's working file is a sequence the SOX auditor will read against and the SEC will read against if the disclosure timing produces an inquiry.

I want to walk through the identity-aware policy decisions a finance back-office deployment has to commit at the request boundary, the audit record format that survives SOX and SEC review, and the architectural pattern that closes the post-authentication gap most back-office copilots leave open.

The data the finance back-office copilot reads at request time

The copilot reads four categories of data that map directly to securities-law surfaces. The first is the general ledger detail (revenue, expenses, accruals, intercompany eliminations) the close team handles. The second is the pre-announcement earnings detail (the draft 10-Q, the draft press release, the analyst-day deck, the segment reporting that has not been reviewed by disclosure committee). The third is the vendor and contract detail (pricing terms, MSA confidentiality clauses, vendor concentration data). The fourth is the executive compensation detail (the working compensation committee materials, the 10b5-1 plan calendars, the insider list).

Each category carries an explicit confidentiality and access-control posture. The general ledger detail is restricted to the finance organization with role-based access through the ERP. The pre-announcement earnings detail is on a need-to-know basis under the company's insider trading policy. The vendor detail is restricted under the MSA terms with the counterparty. The executive compensation detail is restricted to the compensation committee, the general counsel's office, and the specific HR leads.

A copilot that reads any of these categories into the prompt at request time is making a data-routing decision the security team has to be able to reconstruct after the fact. The reconstruction has to include the user identity that issued the request, the data class that entered the prompt, the model endpoint that received the request, and the policy state at the moment of the decision.

The identity-aware policy decisions

The decisions the deployment commits at the request boundary cover three orthogonal axes. The first is user-against-data. A revenue accounting analyst can read GL detail. A FP&A analyst can read GL detail and segment reporting. A treasury analyst can read cash positions and intercompany. The same analyst cannot read pre-announcement earnings drafts unless the analyst is on the disclosure committee's working list for the quarter. The policy reads the directory roles the IAM provider holds and the per-quarter working-list attribute the disclosure committee maintains.

The second is data-against-model. A prompt that contains pre-announcement earnings text cannot route to a model whose data processing terms do not exclude training-data inclusion and do not bind a BAA-equivalent confidentiality contract. A prompt that contains vendor pricing terms cannot route to a model whose data residency lies outside the jurisdiction the MSA requires.

The third is action-against-state. A copilot that proposes drafting language for the press release crosses the disclosure committee's review process. The action requires a confirmation step the policy enforces. A copilot that proposes writing the analysis into a shared drive that the broader organization can read crosses the insider-trading policy. The action requires a routing step the policy enforces.

The three axes compose. A user (FP&A analyst, on the working list for Q2) asks (a question about a margin variance) against (segment reporting that has been reviewed by the disclosure committee, routing to a model with appropriate processing terms). The combination produces a pass. A change on any axis (the user comes off the working list, the segment reporting changes, the model selection moves to a non-covered endpoint) produces a block or a modify.

The audit record format for SOX and SEC review

The record at decision time carries the seven fields a SOX 404 controls test and a SEC inquiry under the disclosure rules would each read. The identity carries the natural-person identifier (the user) and the agent identifier (the copilot session) when the copilot acts on behalf of the user. The route carries the route identifier (which copilot function, which retrieval pipeline) and the policy bundle binding active at decision time. The data classification carries the inspection layer's classifier output on the prompt and the retrieved context (MNPI, vendor confidentiality, executive comp, GL detail). The policy version carries the version of the policy bundle the policy decision point read at decision time. The decision outcome carries pass, block, or modify with the rule identifier that produced the outcome. The model and version carries the upstream LLM the request forwarded to. The integrity metadata carries the cryptographic signature and the hash chain link.

The record satisfies SOX 404 because the deployer can produce evidence that the AI-assisted financial reporting controls operated effectively during the period. The record satisfies SOX 302 because the CFO can attest to the operational state of the AI controls with reference to the per-decision evidence. The record satisfies SEC inquiry around disclosure timing because the deployer can produce the per-decision evidence of who accessed pre-announcement material when.

The post-authentication gap finance back-office copilots leave open

Most finance back-office copilots integrate with the corporate SSO, propagate the user identity into the application session, and then call the model API with the application's service account. The model provider's logs carry the application's identity. The application's logs carry the user identity but lack the model selection, the classifier output, and the policy state. The reviewer who asks "what pre-announcement material did user X access through the copilot at 14:32 the day before the earnings release" reads two log streams that were never designed to be joined.

The gap is structural. The application's logs document what the application did. The model provider's logs document what the model provider received. Neither carries the per-decision evidence the SOX auditor and the SEC reviewer expect.

The architectural pattern that closes the gap

The pattern is an inspection layer at the HTTP boundary between the copilot's application and each upstream the copilot calls. The layer reads the prompt, the retrieved context (as part of the prompt), the identity the application propagates, and the policy state. The layer evaluates the user-against-data, data-against-model, and action-against-state policies. The layer applies pass, block, or modify, and commits the per-decision audit record before the response forwards.

The layer requires the application to propagate the user's identity in the request. The standard pattern attaches the user identifier as a header or includes the user identity in the request body. The application's identity propagation is the upstream obligation. The policy evaluation and the audit record commit are the inspection layer's obligation.

DeepInspect

This is the gap DeepInspect closes for finance back-office copilots. DeepInspect sits inline between the copilot's application and any HTTP upstream the copilot calls. The inspection layer reads the prompt, the retrieved context, and the user identity the application propagates. The layer evaluates identity-bound policy against the data classification and the policy state. The layer applies pass, block, or modify and commits the per-decision audit record to durable, append-only storage with a cryptographic integrity signature before the response forwards.

The record series carries the natural-person identifier the user authenticated with, the copilot session identifier, the route, the data classification, the policy version, the decision outcome, the upstream model and version, and integrity metadata. The series satisfies SOX 404 controls testing, SOX 302 attestation evidence, SEC disclosure timing inquiry response, and EU AI Act Article 12 from a single pipeline.

If you are running an AI copilot inside the finance organization and the auditor or the SEC inquiry would read your application logs as insufficient evidence, let's talk today.