LangChain in Practice: Building a Four-Layer Security Guardrail System for Agents

From LLMs to LangChain: Why You Need an Application Framework

Understanding the essence of LLM development isn't all that complicated. A large language model is fundamentally a model trained by algorithm teams, and its core strength lies in powerful reasoning ability — you feed it a pile of unstructured information, and it organizes it into the ordered results you need; you engage it in conversation, and it accurately grasps your intent.

This reasoning ability stems from the pretraining process in which large language models (LLMs) are trained on massive text corpora. Models like the GPT series, Claude, and LLaMA leverage the self-attention mechanism within the Transformer architecture to learn how to capture long-range semantic dependencies in text. What we call "reasoning ability" isn't traditional logical deduction — it's a probability-based capacity for pattern recognition and generation. The model predicts the most likely next token based on context, enabling tasks like information synthesis, intent understanding, and knowledge-based Q&A. This capability is especially prominent under Chain-of-Thought prompting, where the model can decompose complex problems step by step and produce structured reasoning processes.

The core job of every LLM development role today can be summed up in one sentence: How do you make the model's capabilities better serve your business?

The problem is, if developers write all the low-level code for communicating with the model, handling inputs and outputs, and building conversation logic from scratch, they often fall into a trap: spending too much energy on how to communicate with the model more efficiently and reliably, while drifting away from the original goal of solving business pain points.

LangChain was built to solve exactly this problem. It's a framework for building LLM applications that encapsulates low-level capabilities like model communication, fragmented knowledge injection, conversation control, and content filtering — so developers can focus on the business itself. LangChain was originally open-sourced by Harrison Chase in late 2022 and quickly became one of the most popular frameworks in the LLM application development space. Its core value lies in providing a standardized abstraction layer: model invocation interfaces (supporting dozens of backends including OpenAI, Anthropic, and local models), prompt template management, document loading and splitting, vector database integration, Retrieval-Augmented Generation (RAG) pipelines, and an Agent execution engine. This abstraction allows developers to interface with different LLM providers through a unified API, eliminating the repetitive adaptation work caused by differences in underlying APIs.

LangChain Ecosystem: A Three-Layer Architecture

The LangChain ecosystem has a clear layered structure, and understanding it is essential for mastering Agent development.

Bottom Layer: LangGraph

The lowest-level module is LangGraph, which implements Agent execution flows in the form of "graphs." If you develop directly with LangGraph, you'll write more code than with LangChain, but in return you get ultimate flexible control over business logic and implementation details.

LangGraph uses directed graphs as the orchestration method for Agent workflows, where nodes represent specific execution steps (such as calling a model, executing a tool, or making conditional decisions) and edges define the transitions between steps. This graph structure naturally supports complex control flows like loops, branches, and parallelism, making it ideal for Agent scenarios that require multi-turn reasoning, tool invocation, and state management. LangGraph has a built-in persistent state management mechanism — the state after each node execution is recorded, supporting checkpoint recovery and human intervention. Compared to traditional chain-based execution, this provides stronger controllability and observability, but it also means developers need to explicitly define the graph's topology, which increases the amount of code.

Middle Layer: LangChain

LangChain can be seen as a layer of abstraction built on top of LangGraph. Under the hood, it's actually implemented using LangGraph's graph structure. Compared to using LangGraph directly, LangChain lets you build Agents and AI applications faster and with more flexibility.

Top Layer: DeepAgents

The topmost layer is DeepAgents, an implementation of the harness architecture that is also built on LangChain (with LangGraph underneath). DeepAgents offers the highest level of encapsulation and ease of use, with additional capabilities like file system operations and skill invocation, but the trade-off is reduced flexibility in business logic customization.

The harness architecture is a highly abstract Agent runtime architecture designed to decouple an Agent's core capabilities (reasoning, tool invocation, memory management) from specific business logic, defining Agent behavior through declarative configuration rather than imperative programming. As an implementation of this architecture within the LangChain ecosystem, DeepAgents further encapsulates file system operations, Skill (module) registration and invocation, and other capabilities, allowing developers to quickly build fully functional Agents with minimal code. However, heavy encapsulation means the framework makes many assumptions about the execution flow, and when business scenarios exceed those assumptions, customization becomes significantly harder.

A key takeaway: The higher the layer, the more complete and user-friendly the framework; the lower the layer, the more flexible your control over business details. The security guardrails discussed in this article apply to all three layers — LangGraph, LangChain, and DeepAgents.

It's worth noting that among all AI Agent frameworks, the LangChain ecosystem offers the most comprehensive LLM support, the most refined internal implementation details, and the broadest coverage of the latest technologies on the market.

Security Guardrails: The Agent's Safety Gatekeeper

Security Guardrails — literally "railings" or "fences" — play the role of a "safety gatekeeper" in the Agent conversation flow.

They primarily handle three types of tasks:

1. Input Filtering: When user input contains prohibited content (such as predefined banned words), the message is intercepted before it reaches the Agent.
2. Intermediate Data Masking: During Agent execution, business data retrieved through MCP tools may contain sensitive user information. Guardrails can apply data masking to this information.
3. Output Detection: The model's output is inspected — whether for logical inconsistencies caused by insufficient reasoning ability or potentially harmful content — and handled appropriately.

Typical Use Cases

• Preventing sensitive information leakage
• Blocking Prompt Injection attacks
• Intercepting harmful content before it reaches the model
• Business compliance checks and output content moderation

Prompt Injection is one of the most prominent security threats facing LLM applications. Attackers craft input text designed to override or bypass the system's preset System Prompt, causing the model to execute unintended instructions. Common attack forms include: direct injection (embedding commands like "ignore all previous instructions" in user input), indirect injection (planting malicious instructions in external data sources like web pages or documents that get read by the model during RAG retrieval), and jailbreak attacks (bypassing the model's safety alignment through role-playing techniques). OWASP has listed Prompt Injection as the number one security risk for LLM applications. Defense measures beyond input filtering guardrails include semantic isolation of inputs and outputs, the principle of least privilege, and multi-layer verification mechanisms.

How Guardrails Work: A Middleware-Based Architecture

The underlying implementation of security guardrails relies on a series of middleware within the LangChain Agent execution flow.

Middleware can be understood as: a piece of executable code logic that can be inserted at any point during your conversation with the Agent. Whether before or after Agent invocation, or before or after model invocation, different processing logic can be injected.

The middleware pattern originates from web development, first widely adopted in Node.js's Express framework and Python's Django/ASGI frameworks. Its core idea is to decompose the request processing flow into a series of composable, pluggable processing units, each focusing on a specific cross-cutting concern such as authentication, logging, rate limiting, or data transformation. In LangChain's Agent execution chain, this pattern is elegantly transplanted: hook functions like beforeAgent, beforeModel, and afterModel form a Chain of Responsibility, allowing developers to flexibly inject security checks, monitoring instrumentation, and data masking without modifying the core Agent logic. This design significantly improves system maintainability and extensibility.

The Complete Middleware Execution Chain

From the user's initial request to the final result, the entire Agent conversation passes through the following middleware nodes:

Middleware Node	Execution Timing	Purpose
beforeAgent	Before Agent execution	Pre-processing business logic, input validation
beforeModel	Before model invocation	Information preprocessing, sensitive word filtering
wrapModelCall	During model invocation	Fine-grained processing closer to the model call
wrapToolCall	During tool invocation	Tool permission validation, parameter masking
afterModel	After model invocation completes	Output content moderation and correction
afterAgent	Before results are returned to the user	Final security check and formatting

It's precisely by inserting logic at these different nodes that security guardrails achieve full-chain control from input to output.

Two Major Categories of Security Protection Strategies

Security guardrails are essentially about processing information — especially sensitive and erroneous information — and can be divided into two major categories.

Deterministic Protection

This targets content with fixed formats that can be precisely identified, such as national ID numbers, phone numbers, bank account numbers, credit card numbers, and email addresses. These types of information have deterministic patterns and can be masked, truncated, or otherwise processed through rule-based methods like regex matching.

Its limitations are obvious: it cannot handle "subtle" risky content. For example, when an LLM uses seemingly normal natural language to guide users toward incorrect actions — rule-based matching is powerless against such non-fixed content.

Model-Driven Protection

For non-fixed content that requires semantic understanding, another model is used to analyze the response and determine whether the content is compliant or poses risks. This type of protection fills the blind spots of deterministic protection and can address more complex, more covert security threats.

In practice, model-driven protection typically uses purpose-fine-tuned small classification models (such as BERT-based toxicity detection models or OpenAI's Moderation API) rather than general-purpose LLMs, balancing inference speed with detection accuracy. These small models, trained on targeted tasks, often match or even exceed the performance of large models on specific security detection tasks, while offering lower latency and lower cost — making them suitable for real-time detection within middleware pipelines.

Only by combining both approaches can you build a complete security defense.

LangChain's Two Built-in Security Protection Capabilities

LangChain provides two categories of out-of-the-box security protection capabilities, so developers don't need to build from scratch.

PII Detection (Personally Identifiable Information Protection)

PII (Personally Identifiable Information) detection specifically targets deterministic sensitive information such as national ID numbers, phone numbers, bank account numbers, credit card numbers, and email addresses. It can truncate sensitive information in inputs and apply data masking to model outputs.

Technically, PII detection typically combines multiple approaches: regex-based pattern matching (such as 11-digit phone number patterns, 18-digit ID number validation rules, and Luhn algorithm validation for credit card numbers), machine learning methods based on Named Entity Recognition (NER) using libraries like spaCy and Microsoft Presidio to identify unstructured sensitive information like names and addresses, and context-based semantic judgment (distinguishing between "my phone number is 138..." and "product ID 138..."). LangChain's integrated PII detection capability is primarily based on the Microsoft Presidio framework, supporting identification of multiple languages and entity types, and offering various masking strategies including replacement (substituting with placeholders), hashing, and encryption. In production environments, PII detection requires balancing precision and recall — overly aggressive detection leads to false positives on legitimate content, while overly lenient detection may miss actual sensitive information.

Human-in-the-Loop (HITL)

HITL is a human intervention mechanism. When users are conversing with an Agent and certain high-risk tools need to be invoked, different users may have different operational permissions. Through HITL, a human approval step can be introduced at critical operation nodes, ensuring that sensitive operations are confirmed by a human. This is essentially another important layer of security protection.

In enterprise AI applications, HITL is not just a security mechanism but also a compliance requirement. In high-risk industries like finance, healthcare, and law, regulators often require that critical decisions include a human review step. In LangGraph, HITL implementation relies on the built-in Interrupt mechanism: when the Agent reaches a predefined approval node, the workflow pauses and persists its current state to a database (such as PostgreSQL or Redis), while notifying the approver via webhooks, message queues, or UI interfaces. After the approver reviews, the workflow is resumed via API. This asynchronous approval pattern requires consideration of engineering concerns such as timeout handling, fallback strategies when approvers are unavailable, and traceability of approval records.

Summary

From the reasoning capabilities of LLMs, to LangChain's three-layer ecosystem architecture, to middleware-based security guardrails and HITL human approval systems — the security framework for enterprise-grade Agent development is built layer by layer through this modular, pluggable mechanism.

Whether you're using the flexible LangGraph, the balanced LangChain, or the highly encapsulated DeepAgents, the design philosophy of Guardrails is universally applicable. Mastering the combination of deterministic protection and model-driven protection, along with PII detection and human-in-the-loop mechanisms, is what it truly takes to build enterprise AI applications that are both user-friendly and reliable.