CEDX Mira

Making an AI layer that a legal team will actually approve

Three vendors were turned down before this one cleared review. None of them failed on the quality of the model. They failed on being unable to say what the model had seen.

Priya Raghunathan, Chief Product OfficerPriya RaghunathanChief Product Officer · 4 min read
A presenter briefing a room from a large screen
A presenter briefing a room from a large screen.

What the review actually asks.

Legal and privacy reviews of an AI feature are, in the main, not about the model. Ours asked five questions, and every one of them is a question about records rather than about capability.

  • What data did the model see, for this specific request?
  • Where was it processed, and who else could reach it there?
  • What was the model permitted to do, as distinct from what it was asked to do?
  • How long is any of it kept, and under whose retention policy?
  • Can you answer the first four for a request made in March?

A demonstration answers none of these. Three of the vendors we assessed answered the first four with a slide and the fifth not at all, which is where each of them stopped.

Retrieval inherits the caller's permissions.

The first architectural commitment removes most of the argument: a skill running in Mira can read exactly what the person who invoked it could read, and nothing more. It runs inside the same entitlement plane as the rest of the estate rather than beside it holding a service account.

This is unglamorous, and it is the difference between a feature that clears review and one that does not. A service account with broad read access is a data-flow diagram nobody can approve, because the answer to “could this summarise a record the user is not allowed to see” is “yes, if the retrieval was wrong”. Subjecting retrieval to the same authorisation as a page request changes that answer to “no, structurally”.

The cost is real. Retrieval is slower, and some genuinely useful cross-organisation answers are simply unavailable. Those are now an explicit capability with its own approval, rather than a side effect nobody chose.

Record references, not copies.

The audit record for a request holds the prompt, the identifiers of every record retrieved, the tool calls attempted and their outcomes, the model and version that served it, and the output. It does not hold copies of the retrieved content.

That distinction earns its keep twice. It stops the audit log from becoming a second, less governed copy of the data: a breach waiting for its moment. And it means the audit record inherits the retention class of what it references: when a customer record is deleted, the reconstruction of what the model saw degrades with it, which is correct behaviour rather than a gap to be explained.

Tool calls are the actual risk surface.

Reads are comparatively easy to approve. Writes are not, and most of the review time went here.

Proposal and execution are separate steps.

Mira separates proposal from execution. A skill may propose an action; executing it requires that the invoking user holds the permission that action needs, and the resulting change is recorded as having been made by that user through Mira rather than by a system identity. An approval in Ledger performed through a skill appears in Ledger's audit trail as the same approval it would have been through the interface, with the additional fact of how it was initiated.

The single most useful artefact in the review was two pages: one row per tool, the permission it requires, and what a compromised prompt could achieve at most.

Version pinning, and admitting the limits.

Models change. A feature approved against one version and quietly served by another is not the feature that was approved. Each skill pins a model version, and changing it is a change to the skill, with a review path proportionate to what that skill can reach.

We were also explicit about what we could not promise. We cannot guarantee an output is correct. We can guarantee it is attributable, bounded by the caller's permissions, reproducible in terms of its inputs, and reversible wherever it wrote anything. Saying that plainly moved the conversation along faster than any assurance about accuracy would have. Reviewers are accustomed to being told a system is safe. They are not accustomed to being told precisely where it is not.

What it cost.

Entitlement-aware retrieval and the tool register added roughly two sprints to the build. The review that had run to eleven weeks with the previous vendor took nine working days, and left two residual conditions: a quarterly export of the tool register, and regional processing for one class of record.

The lesson is dull and worth repeating. Reviewable properties have to be in the architecture. They cannot be added as documentation afterwards, because the documentation would then be describing something that is not true.

Written by
Priya Raghunathan, Chief Product Officer

Priya Raghunathan

Chief Product Officer, CEDX Systems

These notes are written by the people accountable for the thing being described, and published unedited at cedxsystems.com. If a decision in one of them turns out to have been wrong, the follow-up says so rather than the piece quietly disappearing.

Everything else published here
Next

This is what Copilot does about it.

AI that respects permissions. There is a full trial on copilot.cedxsystems.com, and the customer stories show the same decisions with dates attached.