Privilege AIMKC2 results

One matter
at a time.

Legal AI security is mostly about isolation: between matters, between clients, and between a system that reads client documents and a system that can act on them.

READ THE DEFINITION ↓ISOLATION · INJECTION · AUTHORITY

01 / DEFINITION

The short answer first.

What is legal AI security?

Legal AI security is the protection of an AI deployment inside a legal practice: keeping client and matter material isolated, enforcing ethical walls in retrieval, treating client-supplied documents as untrusted input, and bounding what any system may do to a live matter.

The general AI security surface applies unchanged. What is specific to a practice is that the isolation requirements are formal rather than administrative, that a large share of incoming documents originate outside the firm, and that the consequence of a wrong action lands on a client rather than on an internal process.

02 / ISOLATION

The requirement that shapes the architecture.
Isolation requirements in a practice and where each is enforced. The right-hand column is where a prototype usually falls short.
BoundaryRequirementEnforcement point
Between clientsNo cross-client retrieval or cachingQuery-time filtering, partitioned indexes, identity-keyed caches
Between mattersAccess limited to matters a person is engaged onMatter-level metadata on every chunk, filtered before scoring
Ethical wallsSpecific people excluded from specific mattersAuthoritative source checked at query time; ideally separate indexes
Between firm and client materialClient-supplied documents treated as untrusted contentTrust level in provenance metadata; no path to privileged actions
Between systemsA model that reads cannot also actSeparate components with a validated schema between them

Ethical walls are the hardest of these to implement correctly, because they are exceptions rather than rules and they take effect immediately. A permission model built on inclusion — you may see matters you are assigned to — handles them only if the exclusion propagates to the index within seconds. Where that cannot be guaranteed, partitioning is the safer construction. See RAG access control.

03 / CLIENT DOCUMENTS ARE UNTRUSTED INPUT

The injection channel a practice cannot close.

Anyone can send
a document.

A practice receives documents from clients, counterparties, courts and third parties continuously, and any of them can contain text intended for a machine reader. This is not a hypothetical concern about adversarial clients; content in disclosure bundles, filings and correspondence passes through many hands, and hidden text in document metadata or invisible layers is fully visible to a model while being invisible to a reviewer.

The consequence is that document intake is an untrusted input channel, and the controls are architectural: the component that reads incoming material should hold no privileged capability, and anything that can act should consume validated structured output rather than free text. See AI agent prompt injection.

Provenance and trust level belong on every indexed passage for the same reason. A pipeline that indexes firm precedent alongside counterparty attachments in one undifferentiated pool has combined sources with entirely different trustworthiness, and downstream handling cannot distinguish them. See RAG security.

04 / AUTHORITY ON LIVE MATTERS

What a system should be allowed to do.
↳ 01

Nothing irreversible.

No filing, no sending, no committing to a system of record without a named person confirming it. The asymmetry between a wrong flag and a wrong action is the whole argument.

↳ 02

Review-only as the default ceiling.

A system that reports and flags has a worst case of wasted review time. MKC2 operates this way by design.

↳ 03

Attribution to a person.

Every action and every retrieval attributable to the individual who requested it, not to a shared service account.

The records worth keeping follow from that: what was asked, which passages were retrieved, which model version produced the output, what the system flagged, and what the reviewer decided. That set answers the questions an incident or a professional enquiry will ask, and it is also the disposition record that eventually measures the system on live work. See AI agent monitoring and human-in-the-loop AI.

05 / QUESTIONS

Asked by risk functions in legal practices.

How do you stop an AI system crossing an ethical wall?

+

Filter retrieval at query time against the authoritative source of the wall, and prefer partitioned indexes where the separation is absolute. Post-filtering an answer is too late, and a nightly permission synchronisation enforces yesterday's walls.

Are client-supplied documents a security risk?

+

They are untrusted input. Text intended for a machine reader can be present in metadata or invisible layers, fully visible to a model and not to a reviewer. The control is architectural: the component that reads such material should hold no privileged capability.

Should a legal AI agent be able to file or send anything?

+

Not without a named person confirming the specific action. The cost asymmetry is the reason: a wrong flag costs review time, a wrong filing or disclosure may not be recoverable at all.

What should be logged in a legal AI deployment?

+

The request, the identity, the passages retrieved, the model version, the output and the reviewer's decision. Those logs contain privileged material, so they need the strictest access control in the environment and an explicit retention period.

Does an offline deployment satisfy confidentiality obligations?

+

It removes external transmission, which is frequently the decisive question, and leaves internal access control, retention and supervision exactly as they were. Whether obligations are satisfied is a judgement for the practice.

Isolation
by construction.

Privilege AI designs retrieval boundaries, permissions and private inference together, for material that is confidential by default.