Connecting AI to Your DMS and Docket Without Losing Privilege

Connecting AI to your document management system, contract repository and docket means the model reads from the live record through a governed interface, rather than a folder somebody exported to a laptop. The connection preserves the matter context, the entitlements, the current version and the audit trail an export destroys. If your information barriers survive right up until somebody clicks "download all", you do not have barriers. You have a habit.

Almost every legal AI pilot starts the same way. Somebody exports a folder from the DMS, uploads it, and gets a good answer, so it passes. What was tested was the model. What was not tested was everything the export destroyed: the matter the documents belonged to, the ethical wall that governed who could open them, the version that was current, and the disclosure restriction attached to half of them. A folder on a laptop cannot be recalled, has no owner after the first forward, and will happily show a trainee the whole matter.

What a live connection preserves

A connector keeps the properties your systems already have and the export throws away:

• Matter context. The document is still attached to the matter it belongs to, rather than sitting in a folder called final_v3.
• Entitlement. The wall the DMS already enforces still applies, rather than being reapplied by whoever built the export.
• Currency. The version is the version now, not the one exported before the amendment.
• Attribution. Every read is a logged access with a user and a timestamp.
• Revocability. Access ends when you end it.

None of these are AI properties. They are governance properties your systems already have, and the export throws them away.

What MCP actually is

The Model Context Protocol is a way of exposing tools to a model over a defined interface. An MCP server sits in front of a system and publishes a set of tools, each with a typed input schema and a defined output. Claude, as the client, discovers those tools and calls them when a task requires it. The part worth internalising: the server decides what exists. If there is no tool for deleting a document, no clever prompting produces one. Treat the tool list as the perimeter, because it is.

The protocol has three primitives, differing in who is in control:

• Tools are controlled by the model: actions it may invoke, such as searching a case law database. The model decides when; your server decides whether the tool exists at all.
• Resources are controlled by the application: data the host attaches to context, such as this matter's file. The host decides what to include, not the model.
• Prompts are controlled by the user: templated workflows the server offers as something to pick.

The control axis matters more in a practice than anywhere else. If a DMS connector is exposed as a tool, the model may fetch any matter it can name, and your ethical wall becomes a function of whether the model happened to ask. Exposed as a resource, the application decides which matter file is attached, using entitlements the DMS already enforces. That is the difference between an agent that could reach the whole firm and one given a single matter.

What makes a good legal connector

The published contribution guide sets five criteria worth holding your own internal connectors to:

• Read-heavy tools. Write tools that create, send or file need explicit confirmation on the client side. The asymmetry is stark: a bad read is an inconvenience, a bad write is a filed document.
• Provenance in results. Every result carries its source, the date retrieved and a citation-ready identifier. A result without provenance cannot appear in work product. The prompting techniques that produce a checkable answer depend on the connector making that possible.
• No instruction-like content. Retrieved content is data, not commands. This is the injection boundary, stated as a connector obligation rather than left to the prompt.
• Errors that degrade gracefully. A failed lookup must be distinguishable from a genuine nil. "No filings found" and "the docket was unreachable" mean very different things to a litigator.
• Documented auth and coverage. A connector silently covering only part of a jurisdiction is worse than one that says so, because the gap looks like an absence of authority.

Privilege at the connector layer

Three questions decide whether a connection protects privilege or quietly collapses it:

• Who is asking? A connector authenticating as a service account with firm-wide rights collapses your entitlement model into one identity, and every user then holds the union of everyone's access. The calling lawyer's identity should reach the DMS. Where that is hard, the interim position is a deliberately narrow service identity scoped to one matter or practice group.
• What can it do? Start read-only, and treat that as the default state that requires an argument to leave. When you do add a write, make it a staging write: the agent proposes, a person approves, the system records both.
• What is it reading? A connector to a document store is a connector to documents written by people outside your firm. Documents are data to extract from, never instructions to follow. A prompt asking a model to ignore embedded instructions is a request; a capability the agent does not hold is a guarantee.

Sequence it, and do not skip a stage

Connect in four stages, each earning the next. Start with public, read-only sources such as a case law database or a legislation feed, where nothing confidential leaves the perimeter and your team learns how agents behave. Then move to internal, read-only, one matter, small enough that a mistake is a conversation rather than a notifiable incident. Then widen to the DMS with the calling lawyer's identity flowing through and the connector appearing in access reviews. Only then consider staged writes, where the agent prepares and a named lawyer commits.

The temptation after a good first stage is to jump straight to the DMS. Resist it. Your practice has not yet built the review habit, the incident path or the access review the later stage requires, and the first time something goes wrong you want it to have gone wrong on the precedent bank.

The trail you get, and the one you design

Once the model reads through a connector rather than an export, your DMS access logs cover the AI too: which document, from which identity, at what time, on which matter. That alone puts you ahead of most practices. But access logs tell you a document was opened. They do not tell you that this document produced that conclusion in that client deliverable. The link between a retrieved passage and the advice it ended up in is what an insurer or a regulator actually asks for, and nothing produces it by accident. It has to be designed in.

Connections are one layer in a stack. Skills sit on top of them, and packaging both together is covered in our guide on plugins and agents. For the whole argument, read the AI guide for legal practice.

Want it on your desk? Download the five-part legal series, or send us a workflow and we will tell you plainly whether it is worth building.