Legal AI Is Getting Better Context. It Still Needs Authority Before Action.

The legal technology stack is becoming more context-aware, permission-aware, and agent-ready. That is real progress. But knowing more about the work is not the same as having authority to let a particular action bind the firm.

Context is not authority

A legal system may know a great deal about an action before it happens.

It may know:

• who the user is;
• what matter they are working on;
• what role they hold;
• which document is involved;
• what permissions apply;
• what jurisdiction or workflow is relevant;
• what consent, policy, or matter context exists.

That is valuable context.

But none of those facts, by themselves, necessarily answer a different institutional question:

Is this actor authorized to take this specific action, in this matter, under this authority, before the firm is committed?

That distinction becomes important as software moves closer to action.

• Knowing that someone can access a document does not necessarily mean they may file it.
  
• Knowing that someone holds a senior title does not necessarily mean they have authority for every action available to the workflow.
  
• Knowing the matter context does not necessarily mean every required condition for execution has been satisfied.

Context describes the situation. Authority determines whether the action may bind.

Those are related problems. They are not the same problem.

The DMS can become more intelligent without becoming the final authority for every action

This is not an argument against the DMS.

Quite the opposite.

The stronger the firm's governed sources of identity, matter context, permissions, policy, consent, and structured metadata become, the better the surrounding control environment can become.

• Document systems should be good at governing documents.
  
• Identity systems should be good at establishing identity and access.
  
• Matter systems should be good at supplying matter context.
  
• GRC should be good at policy, ownership, and control posture.
  
• AI systems should be good at the work they are authorized to perform.

But there is still a downstream moment where context has to become a decision.

• Before the filing leaves the firm.
• Before the approval binds.
• Before the disclosure goes out.
• Before the institution is committed.

At that point, the question is no longer only:

What does the system know?

It is:

May this action proceed?

Seniority is not authority

We tested this distinction directly in a controlled evaluator workflow for SEAL Legal Runtime.

In one synthetic scenario, the acting role resolved to General Counsel.

The actor was known. The role was senior. The workflow context existed.

But under the configured authority conditions for that filing action, the role was not authorized to take the governed action.

The outcome was refusal.

The point is not that General Counsel should or should not have authority for a particular filing. The firm defines that.

The point is simpler:

Seniority is not authority.

A sophisticated legal stack can know exactly who someone is and still need a separate answer to whether that person — or an AI agent, service account, workflow, or other actor — is authorized to take the specific action about to become external.

That is a runtime governance question.

Agentic legal work makes this distinction more important

When AI primarily summarized documents or drafted text for review, many governance concerns could remain centered on data access, output quality, confidentiality, model behavior, and human review.

Those controls still matter.

But agents change the shape of the problem.

The closer software moves toward multi-step workflows, background activity, approvals, submissions, disclosures, filings, and other consequential actions, the more important it becomes to distinguish capability from authority.

A system being capable of doing something is not the same as the institution authorizing that action to occur.

A permission to retrieve information is not automatically authority to bind.

A policy written somewhere upstream is not automatically a decision at the moment of execution.



And an audit record created afterward is not the same thing as having owned the decision before the action happened.

This is the Action Governance problem

At Thinking OS™, we call the discipline Action Governance.

Action Governance asks what may actually execute in the real world — by this actor, in this context, under this authority — before the consequential act occurs.

The missing control point is the Commit Layer: the pre-execution authority gate before an institution becomes committed.

Refusal Infrastructure is the architecture category for making that control operational.

SEAL Legal Runtime applies it to designated high-risk legal actions.

That hierarchy matters because this is not a claim to replace the systems around it.

• The DMS remains the DMS.
• IAM remains IAM.
• GRC remains GRC.
• Matter systems remain the source of matter context.
• Lawyers retain legal judgment and professional supervision.
• Upstream governance decides whether a system belongs in the workflow.

Runtime control decides whether a particular action is allowed to bind.

Better metadata is a tailwind, not a substitute

As legal platforms become better at producing structured, governed, permission-aware context, that should make downstream governance more legible.

But richer metadata does not remove the authority question.

It makes the inputs to that question potentially better.

And the distinction matters even more when some of that context is machine-extracted.

A governance runtime cannot make inaccurate source data accurate. Bad identity data, stale roles, missing authority, or incorrect matter context remain upstream problems that have to be addressed upstream.

The stronger model is separation of responsibility:

Your systems provide the governance facts.
The authority control decides whether the particular action may proceed before it binds.

That is a narrower claim than saying one platform should govern everything.



It is also a more testable one.

From policy to an actual decision

Legal organizations already have substantial governance around their work.

The emerging question is whether those controls reach the moment where a consequential action can still be refused.

• Not after the filing.
• Not after the disclosure.
• Not after someone reconstructs what happened from logs.
• Before it binds.

That is the control point we think deserves considerably more attention as legal AI becomes more contextual, more embedded, and more capable of acting.

We have published a public, redacted SEAL Legal Runtime External Proof Packet for readers who want to inspect the narrow control behavior rather than accept a broad governance claim.

It shows controlled evaluator scenarios for approval, wrong-authority refusal, role-based refusal, missing-consent refusal, authorized supervision, decision evidence, and scoped downstream alignment.

The packet does not claim customer production deployment, legal correctness, or universal coverage.

It tests something narrower:

Can a governed authority decision occur before the scoped filing path proceeds — and can the resulting evidence be reviewed?



As the rest of the legal stack becomes better at understanding the work, that question is going to matter more, not less.

Market references

iManage, Next Evolution of Platform at ConnectLive 2026 — governed institutional knowledge and its “context fabric” for agentic work.

NetDocuments, Context Graph for Legal Work and What’s a Legal Context Graph, and Why Do Legal AI Agents Need One? — connected, permission-aware firm context and AI Profiling that extracts structured legal data and metadata from unstructured documents.

Harvey, Introducing Agent Builder — reusable multi-step legal agents, background scheduling, greater autonomy, and human-in-the-loop checkpoints.