Integration6 min read

Govern your LangChain agents

Wrap your LangChain and LangGraph tools in a governed adapter — same name, same schema, plus a grant check, segregation of duties, and an audit entry per call.

Your team built a working LangChain agent. It reads a case, calls four or five tools, and drafts a decision faster than the analyst it was meant to help. Then compliance asked a simple question: who said this agent was allowed to call the "close_alert" tool, and where is the proof it didn't quietly approve its own work? And the project stopped — not because the agent was wrong, but because nobody could answer.

LangChain and LangGraph are how a great many regulated teams actually build agents today. (LangChain is the framework that wires a model to a set of tools; LangGraph is its companion for orchestrating multi-step agent workflows.) The problem is never the framework. The problem is that a tool, in LangChain, is just a function the model is free to call. Nothing between the model's intent and your real systems checks whether this actor was authorized to do this thing right now — and nothing leaves a record.

A tool call is an authorization decision in disguise

When a LangChain agent calls transfer_funds or release_batch, the framework faithfully runs the function. It does not ask whether the agent's role permits that capability today. It does not check whether the same agent already prepared the item it is now about to approve. It does not write a tamper-evident line to a ledger an examiner could later verify.

Those three checks — is this actor authorized, is this a self-approval, and is there proof — are exactly the controls a regulator expects around a human in the same seat. They are 21 CFR §211.22's quality-unit separation in pharma and the Wolfsberg Group's four-eye standard in finance. The framework was never designed to enforce them. It was designed to make the call.

So the gap is not a LangChain flaw. It is a missing layer. The question is whether closing it forces you to re-platform.

The governed adapter: same tool, new gatekeeper

It does not. A control plane closes the gap by wrapping each tool you already have in a governed adapter — a thin layer that presents the identical name, description, and argument schema the model already knows, and is a drop-in for any LangChain or LangGraph ToolNode.

To the model, nothing changed. It still sees a tool called close_alert with the same parameters and the same docstring, so the model's behaviour, its prompts, and its reasoning are untouched. To your systems, a great deal changed. Before the underlying function runs, the adapter does three things:

  1. Grant check. The call is allowed only if the agent's current role holds an explicit, versioned grant for that skill. Everything not granted is denied by default. Because grants are versioned, you can reconstruct exactly what the agent was permitted to do on any past date — and who approved it.
  2. Segregation of duties. If the run crosses a maker-checker boundary, the adapter enforces it structurally: the same agent that prepared a piece of work provably cannot be the one that approves it. Not "should not" — cannot.
  3. Audit entry. The call, its arguments, the decision, and the outcome land in an append-only, hash-chained, cryptographically signed ledger. Change one record and the chain visibly breaks.

The substitution is mechanical. You import the governed tool in place of the raw one, point your graph at it, and the agent runs as before — except now every call passes through policy, and every call is on the record.

What a denied call looks like

The point is not that the agent gets more freedom. It is that the dangerous calls get stopped before they touch a real system, and the stop is itself evidence.

Suppose your LangGraph workflow has an analyst agent that triages an AML alert and a separate step that closes it. (AML: anti-money-laundering — the program a bank runs to detect and report suspicious transactions.) Under regimes like NYDFS Part 504, the bank must run a documented transaction-monitoring program and a senior officer must certify it — so how an alert gets closed, and by whom, is the kind of decision that has to be defensible. With the governed adapter in place:

The agent tries to… What the control plane does
Call a tool its role was never granted Denies the call, logs the attempt with the missing grant named
Approve an alert it triaged itself Refuses — same actor cannot be maker and checker — and records the refusal
Close an alert that needs a human sign-off Parks the run at an approval gate and waits for a named person to sign

That last row matters. For one-way doors — releasing a batch, filing a suspicious-activity report, closing an alert — the adapter does not just deny; it routes the run to an n-of-m approval gate where a named human signs, the requester is barred from approving their own request, and the signer's reason is captured verbatim. Those are the signature manifestations of 21 CFR §11.50, applied to a machine's work.

Why this beats re-platforming

The instinct, when governance is missing, is to move everything onto a new "governed AI platform." That is a migration project: re-writing tools, re-testing agents, re-earning the trust of the people who finally got the pilot working. It is also the surest way to stall.

The adapter approach inverts that. You keep LangChain, you keep LangGraph, you keep the tools and graphs your team already debugged. The governance arrives as a substitution at the tool boundary, not a rewrite of the agent. There is more on this pattern in wrap existing AI agents without migrating, and on how the same boundary works when your tools speak the Model Context Protocol in MCP-native agent governance.

It is worth being precise about what this layer does and does not do. A governed adapter answers is this actor authorized to do this? It does not inspect whether the content the model produced is toxic, hallucinated, or unsafe — that is the job of a guardrail product, and a good one belongs in the stack too. The two are complementary. One asks whether the output is dangerous; the adapter asks whether the actor was allowed.

Getting from pilot to production

The reason agents stall in pilot is rarely capability. It is that no one can sign off on letting an unaccountable actor touch production systems. That sign-off is a question of evidence, not enthusiasm — and a governed adapter is what produces the evidence. The agent your team already built does not need to be rebuilt. It needs a gatekeeper at the door, one that speaks LangChain's own language. We walk through the full path in from pilot to production.

And do not wait for a rulebook that names this case. US model-risk guidance was rewritten in April 2026 to scope agentic AI out, so there is no supervisory template telling you exactly how to govern an agent. But no template is not the same as no obligation: the predicate rules governing what a human in the seat must do never moved, and discovery does not wait for new guidance to arrive.


See how it works, or book a demo to watch a LangChain agent get blocked from approving its own work — live.

Where this goes to work

How MakerChecker works — the six primitives

Agents as employees, versioned grants, structural segregation of duties, approval gates, role limits, and a signed audit a regulator verifies offline.

See it for yourself

See an agent get stopped.

One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.

Designed against the rules your auditors already enforce.