What does the inspection layer do when the copilot retrieves privileged email into the prompt?

The classifier detects the privileged-indicative text in the retrieval context. The policy evaluates the user's matter-team membership at the moment of the request. A user on the matter team with attorney role passes and the record captures the privilege classification. A user without the right matter-team membership receives a block. The record carries both the classification verdict and the policy outcome.

How does the inspection layer handle matter-team membership that changes during the matter?

The application propagates the matter-team membership at the moment of the request. The case management system is the source of truth. The policy reads the current membership at decision time. A user removed from the matter team after a previous access cannot re-access through the copilot.

Does the inspection layer protect against inadvertent disclosure under FRE 502?

The layer produces the per-decision evidence the FRE 502(b) reasonable-steps analysis reads. The court considers the procedures the producing party had in place at the time of the disclosure. The inspection layer's per-decision evidence of the classifier and policy operation is the form the analysis accepts.

What about copilots that summarize privileged material into work product?

The policy classifies the derived summary with the same privilege designation as the source material. The inspection layer's output policy enforces the classification on the response surface. A derived summary that should carry the privilege designation cannot be written to a non-privileged location through the copilot.

How does the inspection layer integrate with the e-discovery vendor's review platform?

The audit records feed the existing case-handling evidence repository alongside the e-discovery vendor's review logs. The policy authoring lives in the same change-management process the firm uses for case protocols. The inspection layer's classifier signals integrate with the existing DLP and the e-discovery vendor's analytics through a shared signal bus where the firm operates one.

AI Security for Legal Discovery: The Identity, Privilege, and Audit Controls a Production Deployment Has To Run

Legal discovery copilots reach across the data surfaces a litigation team has been protecting since the matter opened. The copilot reads into the document repository the e-discovery vendor produced, the case management system the law firm or in-house team maintains, the email archive the custodians collected, and the deposition transcript store. The data inside the prompt at any given moment crosses attorney-client privilege, attorney work-product doctrine, the matter-specific protective order the court entered, and the in-camera review materials the court has not yet ruled on. A model invocation that includes privileged email text in the prompt context, routes through a vendor LLM whose training-data exclusion the firm has not verified, and writes a derived summary back into the working file is a sequence the opposing counsel will read against if a privilege challenge surfaces.

I want to walk through the identity-aware policy decisions a legal discovery deployment has to commit at the request boundary, the audit record format that survives Rule 26 disclosure and a privilege challenge, and the architectural pattern that closes the post-authentication gap most legal copilots leave open.

The data the legal discovery copilot reads at request time

The copilot reads four categories of data that map directly to evidentiary and privilege surfaces. The first is the privileged communication corpus (attorney-client emails, internal legal memoranda, settlement communications). The second is the work-product corpus (the team's analysis, trial preparation notes, expert communications, witness preparation materials). The third is the matter-specific corpus subject to a protective order (documents produced under confidentiality designations, in-camera review materials, sealed exhibits). The fourth is the general discovery corpus (the produced documents the parties have exchanged without protective designations).

Each category carries an explicit privilege and protective posture. The privileged corpus is restricted to the attorneys and the staff working under their direction. The work-product corpus is restricted to the litigation team. The protective-order corpus is restricted to the parties the order names. The general corpus is restricted by the case-handling protocols.

A copilot that reads any of these categories into the prompt at request time is making a privilege-routing decision the firm 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. An associate on the matter can read the privileged corpus for the matter. A paralegal on the matter can read the work-product corpus and the produced corpus. A summer associate cannot read the in-camera review materials. The policy reads the matter-team membership the firm maintains in the case management system and the role attribute from the directory.

The second is data-against-model. A prompt that contains privileged text cannot route to a model whose data processing terms do not exclude training-data inclusion and do not bind a confidentiality contract the firm has reviewed. A prompt that contains protective-order material cannot route to a model whose data residency or processing location falls outside the protective order's terms.

The third is action-against-disclosure. A copilot that proposes drafting a discovery response crosses the Rule 26 disclosure process. The action requires a review step the policy enforces. A copilot that proposes summarizing privileged material into a non-privileged work product crosses the privilege waiver surface. The action requires a routing step that ensures the derived summary inherits the privileged classification.

The three axes compose. A user (associate, on the matter team) asks (a question about the produced documents) against (general corpus material, routing to a model with appropriate processing terms). The combination produces a pass. A change on any axis (the user leaves the matter team, the retrieval pulls in privileged material, the model selection moves to a non-covered endpoint) produces a block or a modify.

The audit record format for Rule 26 and privilege review

The record at decision time carries the seven fields a Rule 26 disclosure exchange and a privilege challenge would each read. The identity carries the natural-person identifier and the agent identifier when the copilot acts on behalf of the user. The route carries the route identifier (which copilot function, which corpus retrieval) 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 (privileged, work-product, protective-order, general). 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 Rule 26(b)(5) privilege log production because the deployer can produce evidence that privileged material was not routed to non-privileged surfaces. The record satisfies an inadvertent-disclosure challenge under FRE 502 because the deployer can produce evidence that reasonable steps were taken to prevent the disclosure. The record satisfies the protective order's compliance audit because the deployer can produce per-decision evidence of the routing decisions for protective-order material.

The post-authentication gap legal discovery copilots leave open

Most legal discovery copilots integrate with the firm's identity system, 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 privileged material did associate X access through the copilot during the matter window" reads two log streams that were never designed to be joined. The privilege challenge that surfaces at deposition has no defensible record to rest on. The gap is the same post-authentication gap that shows up across regulated workflows; in the legal context, the gap directly threatens the firm's privilege posture.

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, the identity the application propagates, and the policy state. The layer evaluates the user-against-data, data-against-model, and action-against-disclosure 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 along with the matter context (the specific matter the user is working on, the matter-team membership at the moment, the protective-order designation if any). The application's identity and matter 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 legal discovery 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 and matter context the application propagates. The layer evaluates identity-bound policy against the privilege and protective 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 matter identifier, 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 Rule 26(b)(5) privilege log evidence, FRE 502 reasonable-steps evidence, protective-order compliance audit, and ABA Model Rule 1.6 confidentiality evidence from a single pipeline.

If you are running an AI copilot inside the litigation team and the privilege challenge or the protective-order compliance audit would read your application logs as insufficient evidence, let's talk today.