This technical reference asks a narrow question: what happens when an agent needs to perform an action outside its runtime and the receiving service checks the agent's authority before doing the work?
The systems
Maritime is an isolated runtime platform for running agents in separate, managed environments. Each agent runs in its own Firecracker microVM, with its own kernel and root filesystem, network path, and lifecycle. Maritime answers where the agent runs and how that environment is operated.
Ratify Protocol answers a different question: what is this agent authorized to do when its request reaches another system? Ratify packages that authority as a signed delegation that can travel with the request and be verified by the receiver.
This reference combines the two. A LangChain agent runs inside a Maritime runtime. It requests a bounded work order from a separately deployed MCP receiver. The receiver speaks MCP, the open protocol used here to expose the work-order tool. It verifies the Ratify delegation, checks the requested work against its own policy, and only then enters the protected handler.
The live console is available at labs.ratifyprotocol.com/maritime. The source and evidence are available in the Ratify Maritime reference repository.
Why LangChain is in the reference
We used LangChain because it gives the experiment a real agent and tool-call loop rather than a one-off HTTP script. The agent has a tool it can call, carries its Ratify identity and delegation, and sends a request to the external MCP receiver. The authorization decision is made by the receiving service, at the point where the requested work would otherwise begin.
The default harness is deterministic so that every scenario can be reproduced. A production model is optional. The result under test is the authorization boundary, not the model's ability to choose an action.
What happens on a request
- A principal signs a delegation for one agent key. The delegation names the permitted operation, resource, category, amount, audience, and validity.
- The agent starts inside a Maritime runtime with that identity and authority.
- The agent sends a work-order request to the separately deployed MCP receiver.
- The Ratify proof travels with the request. The receiver verifies the delegation chain and the agent's key, then evaluates scope, resource, category, amount, expiry, revocation, freshness, replay, and its own policy.
- An allowed request enters the protected handler. A denied request stops before that handler runs.
The runtime and receiver are deliberately separate. The runtime provides Firecracker microVM isolation for the agent. The receiver retains control over the external action. Neither layer has to assume that the other layer's internal logs are an authorization decision.
What we tested
The live gate includes one permitted request and eight deliberately invalid requests: an exceeded limit, wrong resource, altered operation, expired proof, revoked proof, replay, wrong agent, and copied certificate. Each result records the decision, the layer that made it, and whether the receiver entered the handler.
We also ran the same reviewed image in two separate Maritime runtimes with different delegated bounds:
- Agent A:
warehouse-seattle-01, up to $500 - Agent B:
warehouse-portland-01, up to $200
Both agents can act within their own authority. Agent B is refused when it asks to use Agent A's resource, declares Agent A's subject, or presents Agent A's certificate with the wrong signing key. The resource case is the key multi-tenant result: B is a valid agent, but its delegation does not permit that action.
Reproduce the result locally
The repository includes a local gate that resolves the published image references, starts one receiver and two agent containers on a private Docker network, and checks all fourteen adversarial and isolation results. It does not contact the live console or require a Ratify service credential:
python3 scripts/reproduce_gate_locally.py
The live and local gates read the same scenario contracts. The deployment is therefore available for inspection, while the result remains reproducible from the source and published images.
What we measured
The pilot records timing rather than presenting an unqualified performance claim. In one permitted request, proof construction took 8 ms and receiver verification took 4 ms, within a 4,537 ms end-to-end request. Most of the time was spent on three separate agent-to-receiver round trips.
This is an observation from the pilot, not a production benchmark. Between 30 August and 3 September 2026, public runtime requests on this account occasionally stalled for 20 to 28 seconds. The same behavior was observed on the health route, so it is not attributed to Ratify verification.
What this demonstrates
This reference demonstrates an authorization boundary around an agent action. It does not claim that Maritime verifies the Ratify image digest at Firecracker launch. Maritime converts an image to a root filesystem before boot, so the image digest binds the published build to its source revision, not to a platform attestation of the running root filesystem.
The delegation and adversarial fixture are written to each runtime's
/data/ratify/ persistent volume through Maritime's file API. Expected SHA-256
digests remain in runtime environment configuration and are checked at startup.
Rotation is a file write, digest update, and restart rather than an image
rebuild.
The console is a public Ratify pilot, not a Maritime endorsement or partnership claim. The runtimes, receiver, and evidence are operated by Ratify. No Maritime attestation of the runtime identifiers or launched image references has been recorded in the evidence artifact. The observed stalls occurred in Maritime's API and proxy path; an occasional timeout is not a successful authorization decision.