OPEN REFERENCE

LangChain

Let a LangChain agent cross an MCP boundary while the receiver verifies who authorized the exact action.

This is a reference, not a hosted lab. The source and instructions are open and it runs on your machine in minutes. Nothing on this page executes here, and no integration is hosted for you.

Ratify Protocol is an open protocol for proving delegated authority: a principal signs a bounded delegation naming what an agent may do, and any receiver can verify that proof offline, before acting, without calling the issuer. This page is one open reference implementation of it.What Ratify Protocol is ↗

An independent draft reference implementation. Not a LangChain partnership, LangChain-approved integration, or LangChain reference architecture.

Why would a developer or enterprise need this?

LangChain and LangSmith already provide real controls: which agents run, which tools they may select, which credentials they carry, and who may reach the Agent Server. Ratify is complementary. It gives the system that carries the consequence evidence of the narrower mandate behind one action.

Question	LangChain / LangSmith controls	Ratify authority
Can this agent select this tool?	Yes	Not its purpose
Does the agent hold a usable credential?	Yes	Not its purpose
Did a recognized principal authorize this exact action?	Not expressed by tool access alone	Yes
Is the authority limited to this region, size, and count?	Application logic may check	Signed into the delegation and checked by the receiver
Can a different organization verify the mandate?	Depends on shared platform and credentials	Yes, from portable proof and configured trust roots
Was the proof changed, revoked, expired, or replayed?	Separate concern	Verified before the handler runs

This matters when a LangChain agent holds credentials broader than the current task, when an MCP or SaaS provider receives calls from agents it did not issue, when agents cross an organizational boundary, or when an audit has to answer who authorized what, for which agent, resource, and time window.

Diagram loading…

Who implements what

Four roles. LangChain implements nothing: the reference uses the public MultiServerMCPClient tool-interceptor API and the standard create_agent loop, so no change to LangChain, LangGraph, or LangSmith is required.

Role	Who this usually is	What they do	What they build
Principal	The organization accountable for the resource	Signs a bounded delegation naming scope, region, count, and expiry	No code. Issues a delegation with the SDK or Ratify Verify, and decides the bounds
Agent operator	The team running the LangChain agent	Adds the interceptor and points it at the receiver	No protocol code, but real configuration: receiver address, trusted principal, and which tools are protected
Receiver operator	Whoever owns the consequence: the provisioning API, the MCP server	Issues challenges, verifies the proof, guards the handler	The verification path. Here `authority_reference/receiver.py` plus the HTTP boundary in `mcp_server.py`: the verify call is a small part, and the rest is challenge issuance, header bounds, trust-root comparison, and keeping the handler unreachable except through the allow branch
LangChain / LangGraph	The agent framework	Selects and calls the tool as it already does	Nothing

The asymmetry is the point. The party carrying the risk is the party that checks, and it can check without trusting the agent, the model, the prompt, or the framework that routed the call.

ALLOW -> protected tool invoked once
DENY  -> protected tool invocation count does not change

Identity answers which workload connected. LangChain answers which tool the agent selected. Ratify answers a different question: which principal authorized this agent to perform this exact operation, on this resource, within these signed limits? The receiving organization can verify that evidence without sharing the sender's API key or calling the sender during the decision.

Diagram loading…

Run the published-package gate from the repository root:

./scripts/langchain-reference-check.sh

The gate creates a clean environment and uses the real create_agent LangGraph loop with a deterministic model double, the public MultiServerMCPClient tool-interceptor API, and an independently started Streamable HTTP MCP receiver. It needs no model API key or paid service. It requires exactly 24 passing tests and fails on a skipped, xfail, missing, or additional test. See evidence/reference-evidence.md.

What the reference proves

Boundary case	Expected effect
Valid two-hop delegation, one node, allowed region	Receiver invokes the protected handler once
Excess count or wrong region	Signed constraint denies before execution
Expired or revoked delegation	Denied before execution
Replayed proof or changed operation	Denied; prior execution count is unchanged
Wrong presenting agent or untrusted root	Denied despite a cryptographically valid hostile proof
Malformed proof or invalid business input	Denied without consuming honest work or reaching the tool
Duplicate transport/proof headers or oversized proof header	HTTP boundary rejects the request before MCP
Missing transport credential	HTTP `401`; MCP receiver is not reached
Concurrent duplicate request IDs or exhausted pending capacity	Receiver state remains bounded and unambiguous
Real `create_agent` → interceptor → HTTP MCP path	Proof stays out of the model schema and ALLOW reaches the tool

The deterministic model is deliberate: authorization must not depend on a model deciding to follow a security instruction. A live model would demonstrate tool selection, but add no authority guarantee.

The com.ratifyprotocol.langchain.max_nodes constraint is a draft Ratify integration profile in a Ratify-owned namespace. It is not a LangChain-defined constraint.

Which path should I use?

Use this open reference when you want to read every line of the decision path, run it with no account, and adapt the receiver to your own service. It is Apache-2.0 and has no runtime dependency on any hosted Ratify service.

Register interest in Ratify Verify when you would rather not operate trust distribution, revocation freshness, challenge storage, and audit retention yourself. Those are the deployment concerns listed under Limitations below, and they are the parts that turn a working reference into a production control.

Both verify the same proofs. The protocol does not change between them.

Run it yourself

Before you start: Python 3.12. No model API key or paid service.

Clone ratify-protocol, then from the repository root:

./scripts/langchain-reference-check.sh

24 tests pass, zero skipped, and the gate fails on any skip.

Read the reference, or watch verification run.

Read the full reference ↗See a hosted lab: Maritime →