A matter summary can be useful to the right team and inappropriate for another team in the same firm. Broad file search followed by a polite instruction to mention only the selected matter does not enforce that boundary. Unrelated material may already have entered the model context, a cache or the stored response.
The proposed design below checks authorised matter membership before retrieval and keeps derived outputs within the approved scope. It addresses operational access and minimisation. It does not decide whether a document is privileged, whether disclosure is permitted or whether any particular provider arrangement meets the firm's professional requirements.
Resolve identity and matter scope before retrieval
Use the firm's trusted identity and membership records. A matter number supplied in a chat message is a requested target, not proof of access. The application checks whether the authenticated actor may retrieve the relevant matter and source category before returning content to the model.
Keep permission sources outside document text. A retrieved note claiming that all staff may see the file cannot expand access. Role and membership changes should come through the firm's approved administrative process, and a revoked membership must affect subsequent requests according to the implemented access rule.
Define the permitted field and document scope as well as the matter. A user may be authorised to view some operational records without receiving every sensitive attachment. The firm determines those categories and any additional restrictions; the assistant should not infer them from job titles or perceived relevance.
Treat retrieval technology as one component of the boundary
OpenAI's file-search guide describes retrieval from uploaded files using semantic and keyword search with citations. It does not establish the firm's matter-access policy or guarantee that every uploaded file is available only to the intended team. The application must enforce the approved source scope. Source: OpenAI file search
Organising files by matter and using metadata can help implement a design, but tags alone are not an authenticated permission check. Test how the actual request chooses its store or permitted records, what happens when a tag is wrong and whether a broadly privileged integration can retrieve unrelated content.
A citation also needs a separate access path. The model may return a source reference, but the recipient should open it through an authorised system that rechecks access. Do not replace a restricted file with a broadly shared download link to make citations convenient.
Matter-specific retrieval design
Use this complete proposed design for fictional matters TEST-MATTER-A and TEST-MATTER-B. The firm must approve the actual roles, categories and processing arrangement before a real pilot.
| Boundary | Proposed enforcement | Acceptance test | Failure disposition |
|---|---|---|---|
| Identity | Resolve authenticated actor from trusted session, not prompt text | Fixture request supplies a different staff name in its text | Ignore claimed identity; enforce authenticated actor |
| Matter membership | Check current authorised membership before query | Team A actor requests TEST-MATTER-B | Deny without returning B content or private source labels |
| Document scope | Permit only approved source categories within the matter | Authorised actor requests an excluded attachment type | Hold or deny through the defined role rule |
| Model context | Build context only from permitted records | Similar filenames exist in A and B | No B excerpt enters A request payload |
| Source links | Recheck access when the recipient opens a citation | Lower-access recipient follows a shared summary link | No expanded source access; record permitted explanation of denial |
| Stored outputs and cache | Bind summary access and reuse to approved scope and current actor rules | A summary is requested after membership changes | Revalidate access; do not serve unrelated cached context |
| Export and notification | Share only approved minimal content with authorised audience | Export preview or notification includes a private source title | Hold release and repair the exposure |
| Provider processing | Review actual endpoint, features and stored states with the responsible owner | Configuration includes an unreviewed storage feature | Hold live processing until the required decision is recorded |
The retrieval record stores actor reference, matter reference, trusted membership decision, permitted categories, source versions, context inventory, output reference, access class, processing configuration and unresolved limitations. Keep credentials and unnecessary full source content out of broad logs. The summary states the authorised sources and coverage rather than claiming to represent every file in the matter.
Fixture plan: normal Team A summary; missing membership; denied Team B query; duplicate file titles across matters; a wrongly tagged fixture file; a revoked membership; and an attempted unrestricted source export. Use entirely fictitious documents and stubbed destinations. Inspect retrieved content and application decisions as well as the final answer.
Release criteria: the team can retrieve its permitted material; denied scopes return no protected content; sources open only through authorised access; cached and stored outputs respect the approved rule; and the responsible professional has approved the intended processing and sharing arrangements. Technical access tests do not determine legal privilege.
The design is complete when every boundary has an owner, an implemented check and evidence for its exception behaviour. A sentence instructing the model to protect confidential material does not complete an unimplemented row.
Test database roles where they are used
PostgreSQL documents row-security policies for restricting rows in normal queries and modifications, with important exceptions including table owners typically bypassing those policies. If the implementation uses PostgreSQL, test the actual integration role and policy behaviour rather than assuming a staff role carries through automatically. Source: PostgreSQL row security policies
Row policies do not by themselves protect every derived summary, uploaded file store or downloadable citation. Document which boundary they enforce and which require application or storage checks. Other systems need their own verified access design; this is not a claim that PostgreSQL controls are native to the retrieval provider.
Inspect administrative and service accounts separately. A successful test using an owner-level account may show useful retrieval while concealing a policy bypass. The relevant evidence is what the ordinary effective role can obtain under the deployed configuration.
Review provider handling separately from matter access
OpenAI's data-controls guide distinguishes abuse-monitoring logs and application state, with endpoint-specific conditions and feature limitations. Restricting matter membership in your application does not establish that source content is absent from provider processing or storage. Source: OpenAI data controls
Provide the responsible owner with the actual endpoint, input types, storage features, local copies and deletion behaviour. Do not treat a general statement about training as a complete confidentiality or retention assessment. The firm determines its requirements and whether the proposed arrangement is acceptable.
Work through normal, missing and duplicate access cases
In a hypothetical normal case, the authenticated Team A member requests a summary of approved TEST-MATTER-A sources. The application checks membership, assembles only permitted context and stores the summary under the approved access rule. The member can verify citations through the restricted source system.
In a missing-membership case, the request names a matter but the trusted membership service provides no authorised match. The workflow holds or denies retrieval. It does not infer membership from a familiar party name or search broadly to be helpful.
In a duplicate-file case, both matters contain a file called correspondence.pdf. The application uses verified matter and source references, not filename similarity. If the source mapping is uncertain, it holds the retrieval rather than mixing excerpts into a combined narrative.
FAQ about matter-scoped AI summaries
Does a source-linked summary preserve legal privilege automatically?
No. This design controls operational access. The firm's responsible professionals must assess privilege, confidentiality and the permitted processing or disclosure arrangements for the actual material.
Can one broad file collection serve the whole firm safely?
Only if the actual implementation enforces the approved boundaries and tests them. Do not assume that a matter tag or model instruction is equivalent to authentication, access enforcement and restricted derived outputs.
What should happen after someone leaves the matter team?
Apply the firm's approved current-access rule to retrieval, stored summaries, caches and source links. Test the actual behaviour. A historical authorisation should not silently grant future access outside that rule.
If your business needs help defining this process, explore AI agents for law firms, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.