A Local Document Assistant That Respects Client Permissions

A consultant searches a shared practice assistant for “termination notice.” She is allowed to see Client Alder’s contract and the firm’s template library. She has no access to Client Birch, where another team negotiated a similar clause last week. If the assistant retrieves broadly and filters the answer afterward, the boundary has already failed before a word appears on screen.

The opportunity is still worth pursuing. A mixed professional office can make years of client documents searchable without flattening every permission into one shared folder. The permission decision has to become part of retrieval itself.

A local document assistant can provide useful cross-document search when current authorisation determines which evidence reaches the model. File permissions need to survive OCR, chunking, indexing, citations, chat history and export.

A focused AI development project should build that permission path before tuning answer style. Document processing with AI agents covers extraction and workflow actions more broadly. This article follows the narrower permission lifecycle from source file to deletion.

---

The Permission Problem Starts Before the Question

Retrieval-augmented generation usually copies document text into an index so a search service can find relevant passages for a model. That derived copy is useful because staff can ask natural-language questions across contracts, reports, invoices and correspondence. It is also a new access surface.

The application service may hold a broad credential to read the index. If it ignores the caller’s client or matter permissions, a strong file-system ACL on the source folder offers little protection. A cached answer, citation title or chat-history preview can reveal information even when the final prose omits the sensitive passage.

Microsoft’s current RAG guidance for Foundry explicitly warns that retrieval can expose sensitive content. It recommends access control at retrieval time and treating retrieved documents as untrusted input. It also notes that grounded output can remain incomplete or inaccurate.

Those points apply to a local stack as design requirements. Running the model in the office changes one network path. It does not carry source permissions into chunks or decide what a logged-in user may retrieve.

The business case therefore depends on a permission chain. When the chain works, a lawyer can search one matter, a fiduciary can query one client and a shared services team can use an approved template library through the same interface. Each receives different evidence from the same service.

Carry Source Permissions Into Every Chunk

Begin with the document repository as the source of truth. For every file, the connector should record a stable source ID, client or matter, owner, classification, retention class and current access list or group identifiers before text becomes searchable.

A file with no owner, client ID or access metadata goes to quarantine. It should never enter a broadly readable index as a convenient default.

OCR and chunking then split the file into smaller passages. Each chunk needs to retain:

• Source ID plus page or paragraph location
• Access-list version and allowed users or groups
• Client or matter identifier and retention status
• Extraction status needed to interpret the text and citation

Preserve this metadata through embedding, reranking, cache and citation generation. A chunk without permission metadata remains unsearchable. The same rule should cover table cells or image text produced by OCR.

Microsoft documents document-level access patterns in Azure AI Search that compare caller identity with ACL or role metadata in the index and trim unauthorised documents at query time. This is a useful implementation reference. Some native mechanisms are preview features, and source permission changes depend on synchronisation. A local implementation has to provide and test equivalent behaviour rather than assume those Azure features exist in its stack.

Authorise the Caller Before Retrieval

When a user submits a question, the application authenticates the caller and resolves current client or matter membership from the office identity system. It checks a current deny record or permission version before querying the index. Only then does it apply the chunk-level filter to keyword, semantic and vector search.

The order matters. Retrieving a broad result set and trimming it after the model receives the text is too late. The model, logs or cache may already contain the unauthorised passage.

If the identity or policy service is unavailable, retrieval fails closed and the interface explains that access could not be verified. It should not fall back to the last known broad permission set. Direct search, follow-up questions, chat history, filename suggestions and citations all need the same authorisation decision.

When a permission changes, a deny or version check blocks stale chunks immediately while the index synchroniser catches up. This closes the period where source ACLs have changed but copied metadata has not. The synchroniser can then reprocess or remove affected chunks and clear associated caches according to policy.

This design can reduce recall because the assistant searches a smaller evidence set. That is the correct trade when the missing document belongs to another client. Measure answer completeness within each authorised set and show an explicit “no evidence found” response when it is empty.

Keep Untrusted Files Inside a Bounded Evidence Path

A contract, invoice or scanned email may contain text aimed at the model, such as an instruction to reveal every client or invoke a connected tool. The final NIST Generative AI Profile describes indirect prompt injection through data likely to be retrieved and notes research demonstrations involving data theft and remote code execution.

Telling the model to ignore hostile document instructions is helpful, but that prompt cannot serve as the containment boundary. The application has to enforce the boundary even when the model follows the file’s instruction.

For the first pilot:

• Authorise retrieval before any document text reaches the model
• Pass only the selected chunks in a clearly marked, bounded evidence field
• Disable tools that send mail, modify the repository or change permissions
• Sandbox parsers, reject executable attachments and cap file or page size
• Require a professional to approve any export or later write action

If tools are added after the pilot, use narrow allowlists and separate approval for each action with side effects. The model should never receive a universal repository credential or unrestricted shell path.

Test hostile instructions in ordinary file text, OCR output and metadata. A passing result contains no unauthorised document, invokes no tool and records an event for review. That test proves the behaviour of the chosen configuration; it does not establish that prompt injection has been solved universally.

Broader application threats are covered in AI agent security risks.

Make Citations and Exports Part of the Control

The assistant should show the source ID and page beside each material statement. A citation helps the professional verify the answer and exposes a retrieval mistake quickly. It does not prove that the user was authorised. That decision must already have happened before retrieval.

The answer or draft lives in a temporary workspace until a named professional reviews it. An export should carry the client or matter ID, reviewer, timestamp and retention class where appropriate. Log the export event alongside the caller identity, authorisation decision, chunk IDs, model and embedding version, prompt template and citations.

Downloads, email attachments, clipboard copies and printed pages create new data flows. Search revocation cannot generally recall them. If the office needs continuing control after export, it must adopt a specific mechanism such as a managed viewer or rights-managed document and test what that mechanism actually covers.

This is also a product decision. A workflow that permits unrestricted copying may be unsuitable for especially sensitive matter classes even if search isolation works perfectly. The pilot should state which export paths are enabled and why.

Separate Revocation From Derived-Data Deletion

Revocation and deletion happen on different clocks. Removing a user’s client access should block the next query immediately through current authorisation. Re-indexing, cache clearing and deletion of stale chunks follow as lifecycle work. One cannot substitute for the other.

Deleting or correcting a source creates a separate workflow. Identify every derived store: staged files, extracted text, embeddings, reranker caches, chat history, drafts, logs and backups. Each needs a purpose, owner, retention rule and deletion procedure. The authoritative repository remains governed by its own mandate and retention requirements.

The FDPIC’s guidance on outsourced data processing requires appropriate controller and processor arrangements, including support for correction or deletion, security, confidentiality and cross-border disclosure. The exact roles depend on the mandate and data flow. A local appliance still needs named administrators and documented data stores; a managed service also needs enforceable provider duties.

After deleting derived data for a synthetic client, search for it, inspect caches and restore a test backup. Then run the deletion procedure again. Backups may follow a documented expiry schedule rather than immediate erasure. Files previously exported outside the controlled system require their own process.

Embeddings deserve explicit treatment as derived sensitive data. Their contents are not conveniently readable by staff, but that does not make them harmless or remove the need for access and deletion controls.

Prove the Permission Lifecycle With a Small Pilot

Use two synthetic clients and two staff identities. Give each person access to one restricted client and both access to one shared template. Include duplicate names, a closed matter and files in the languages the office actually handles.

The pilot should test:

1. Positive access: Each identity finds its authorised files with correct page citations.
2. Negative access: Direct, semantic, follow-up and cross-client questions reveal no unauthorised text, filename, metadata or citation.
3. Immediate revocation: Removing access blocks the next query while index and cache cleanup continue.
4. Synchronisation failure: Stopping the permission synchroniser causes stale material to fail closed after a source ACL change.
5. Existing copies: A synthetic export remains subject to the separate copy-handling policy after search access is revoked.
6. Injection: Hostile instructions in document text and metadata produce no unauthorised retrieval or tool action.
7. Deletion: Derived chunks, embeddings, caches and chat records follow the documented process after a test backup restore.

Record every authorisation decision and source ID. Observe outbound traffic during inference, indexing, model updates, telemetry, backup and support. A local user interface alone cannot prove that every processing step remains on the device.

Quality belongs in the same release decision. Score citation correctness, abstention and reviewer acceptability within each client’s evidence set. Permission filters that leak are a release blocker. Filters that withhold too much require retrieval tuning before staff can rely on the assistant.

Choose the Operating Model That Can Maintain the Boundary

Local inference can reduce routine transfer of prompts and retrieved text to a hosted endpoint while placing identity integration, patching, monitoring, backup restoration and permission synchronisation on the office or its administrator.

A managed private service may offer stronger identity and monitoring controls, subject to acceptable contracts, processing locations, support access and provider diligence, and should be compared with the local option using the same synthetic clients and tests. The relevant evidence is the permission behaviour in the delivered configuration.

Begin with a narrow task, perhaps finding a clause or preparing a cited checklist. Keep mail, source-repository changes and client-facing decisions outside the first release. Expand only after the permission lifecycle and professional review work consistently.

A mixed practice can then search a broad office knowledge base while each person receives only currently authorised sources. The acceptance test follows that boundary from the original file through retrieval, review, export and deletion.