Frameworks

Security testing for LangChain and LangGraph agents

LangChain and LangGraph agents act through tools, which are ordinary functions the model can call with arguments it chooses. LangChain's own security policy says to assume any credential an agent holds can be used in any way its permissions allow. We test exactly that: what each tool can do when the model is steered.

LangChain is named here as a surface we test. Names and logos belong to their owners; no customer relationship, partnership or endorsement is implied.

What can a LangChain agent do?

The LangChain tools documentation describes tools as callable functions with defined inputs that a model can invoke, and LangChain's ecosystem includes integrations for file systems, APIs and databases. LangGraph builds stateful agent graphs, and its interrupts feature pauses a graph by calling interrupt() inside a node, surfacing a JSON-serializable payload to the caller so a person can review before execution continues.

Interrupts are the framework's human-in-the-loop primitive. Whether a given high-impact tool actually sits behind one is a fact about your graph, not about LangGraph.

What does LangChain say about security?

The LangChain security policy gives three practices: limit permissions, anticipate potential misuse and use defense in depth. It is direct about the threat model: always assume that any system access or credentials may be used in any way allowed by the permissions they are assigned, so if database credentials allow deleting data, assume an LLM using them may delete data.

Its examples match what we look for in tests: a file system agent asked to delete or read files it should not, an agent with write access to an external API asked to write malicious data, and a database agent asked to drop a table. The recommended fixes are read-only credentials, directory and table scoping, and sandboxing in a container.

Which risks apply and why?

• Prompt injection: the model picks tools and arguments from text an attacker can influence.
• Indirect prompt injection: retriever and loader output enters the context with the same weight as instructions.
• Excessive agency: generic toolkits, such as SQL or shell tools, expose far more than the task.
• Sensitive information disclosure: one tool's output reused as another tool's argument.

How do you pentest a LangChain or LangGraph agent?

1. Enumerate every tool and toolkit bound to each agent or graph node, and the credential each uses.
2. Check each credential against the security policy advice: read-only where possible, scoped to tables, directories and endpoints.
3. Map which nodes call high-impact tools and whether an interrupt sits before them.
4. Inject through every loader and retriever the agent reads, and record which tool calls follow.
5. Push arguments outside the task, such as other tenants' IDs, wildcard filters and destructive SQL.
6. Look for outbound paths that carry data out.

Each step is mapped to the four classes in our Agent Action Pentest report.

What access do we need?

A running staging graph or agent with its real tool bindings, test credentials scoped the way you would scope production, and a short note on what each tool is for. If you use LangSmith tracing, read access to traces for the test project speeds up reproduction, but is optional.

Last reviewed: 2026-10-14