Issue Station
Sign In
Tools hereToolbox

langchain - ✅(Solved) Fix OWASP Agentic AI Security Assessment -- LangChain Experimental [2 pull requests, 38 comments, 10 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langchain-ai/langchain#35803•Fetched 2026-04-08 00:43:10
View on GitHub
Comments
38
Participants
10
Timeline
74
Reactions
0
Author
razashariffrazashariff
Participants
0xbrainkid0xbrainkidAnakintanoAnakintanobojin-clawflowbojin-clawflowfairchildadrian9-createfairchildadrian9-createJairoohJairoohmanja316manja316NeuZhouNeuZhoupawel-kotowskipawel-kotowskiraye-dengraye-dengrazashariffrazashariff
Timeline (top)
commented ×37subscribed ×17mentioned ×16cross-referenced ×2

Fix Action

Fixed

PR fix notes

PR #35828: feat(langchain): add SafePythonREPL with AST-based code validation (OWASP AA-03)

Description (problem / solution / changelog)

Overview

This PR implements OWASP Agentic AI AA-03 (Unsafe Code Execution) mitigation for LangChain's PythonREPL utilities. It is the first layer (out of 5) in a phased security hardening approach and does not close issue #35803 — remaining mitigations are scoped as future PRs.

Problem Statement

LangChain's PythonREPL executes LLM-generated code directly in the host process with full Python runtime access, exposing:

  • Prompt injection → dangerous imports (os, subprocess, socket)
  • Unsafe built-in calls (eval, exec, __import__)
  • File system access to sensitive paths (/etc, /proc, /sys)
  • Arbitrary network access and potential credential theft

This risk class is catalogued in the OWASP Agentic AI Security Framework under AA-03.

Solution

New class: SafePythonREPL

A purely additive class (SafePythonREPL) that inherits from PythonREPL and adds an AST-based pre-validation gate before any code reaches exec().

Files created:

  • libs/langchain_v1/langchain/utilities/python.py — PythonREPL + SafePythonREPL
  • libs/langchain_v1/langchain/utilities/__init__.py — exports both classes
  • libs/langchain_v1/tests/unit_tests/utilities/test_python_repl_security.py — 67 unit tests

Key features:

  1. AST validation — parses code with Python's ast module before execution, detecting:

    • Denied imports: os, subprocess, socket, urllib, requests, httpx, sys, and others
    • Denied built-in calls: eval(), exec(), __import__(), compile(), open(), globals(), locals(), vars()
    • Attribute access on denied modules: socket.connect(), urllib.request.urlopen()
    • Sensitive-path open() calls: /etc, /proc, /sys, /root, /home

  2. Dual-mode behavior

    • mode="block" (default, safe) — raises ValueError on violation; exec() is never reached
    • mode="warn" — logs the violation with timestamp and code snippet, then falls through to super().run() — development/testing only, never use in production

  3. Configurable blocklists

    • allowed_imports={"numpy", "pandas"} — opt-in allowlist for safe libraries
    • denied_imports=DEFAULT_DENIED_IMPORTS | {"my_lib"} — extend or replace defaults
    • denied_functions — same semantics for built-in call names

  4. Audit logging — every violation is logged via the standard logging module with ISO UTC timestamp, violation reason, and sanitized code snippet

  5. Backward compatible — existing PythonREPL is unchanged; SafePythonREPL is opt-in

Example

from langchain.utilities import SafePythonREPL

# Production (default, safe)
repl = SafePythonREPL()
repl.run("import os")  # raises ValueError: "Code blocked by security policy: import of denied module 'os'"

# Allow specific safe libraries
repl = SafePythonREPL(allowed_imports={"numpy", "pandas"})
repl.run("import numpy as np; print(np.pi)")  # passes

# Development only — logs but does not block
repl = SafePythonREPL(mode="warn")
repl.run("import os")  # WARNING: [SafePythonREPL] Policy violation at 2026-...

Testing

67 unit tests, 100% pass rate, 0.14s runtime.

pytest libs/langchain_v1/tests/unit_tests/utilities/test_python_repl_security.py -v
67 passed in 0.14s

Test categories:

  • Blocked imports: os, subprocess, socket, urllib, requests, nested/dotted/from-imports
  • Blocked function calls: eval(), exec(), __import__(), compile(), open(), globals(), locals(), vars(), input()
  • Sensitive-path guard independent of denied_functions configuration
  • Allowed patterns: math, json, list comprehensions, function definitions, print()
  • mode="block": ValueError raised, exec() never called (verified via mock)
  • mode="warn": warning logged with timestamp, super().run() called
  • Configurable blocklists: custom allowed_imports, denied_imports, denied_functions
  • Edge cases: dotted imports, from x.y import z, empty code, comment-only, SyntaxError input
  • Backward compatibility: PythonREPL unchanged, SafePythonREPL is a subclass

Design Decisions

Default-deny — mode="block" is the default, not mode="warn". Users must explicitly opt into the less safe mode. Follows OWASP fail-secure principle.

Inheritance over wrapping — SafePythonREPL(PythonREPL) avoids code duplication and ensures all PythonREPL behaviour is preserved as the base class evolves.

Sensitive-path guard is independent — even if open is removed from denied_functions via customisation, the sensitive-path check still fires. Defence-in-depth within the validator itself.

AST only, no regex — string matching on source code is fragile and easy to bypass. AST parsing is semantically accurate for the patterns targeted here.

Scope and Limitations

This PR does:

  • Implement defence-in-depth against direct code injection (OWASP AA-03, mitigation #2)
  • Block the most common dangerous patterns before exec() is reached
  • Provide an audit trail via structured log messages
  • Maintain full backward compatibility

This PR does not:

  • Provide process isolation (mitigation #1 — subprocess + seccomp/AppArmor/E2B)
  • Enforce permission scoping per environment (mitigation #3)
  • Add CPU/memory resource limits (mitigation #4)
  • Replace sandboxing — for adversarial/untrusted workloads, process isolation remains required

On obfuscation: Patterns like getattr(__builtins__, 'eval') are not caught by AST filtering — this is expected. Static analysis is defence-in-depth, not a sandbox. Process isolation (future PR) is the correct control for adversarial inputs.

Fixes

Fixes #35803

Changed files

  • libs/langchain_v1/langchain/utilities/__init__.py (added, +5/-0)
  • libs/langchain_v1/langchain/utilities/python.py (added, +341/-0)
  • libs/langchain_v1/tests/unit_tests/utilities/__init__.py (added, +0/-0)
  • libs/langchain_v1/tests/unit_tests/utilities/test_python_repl_security.py (added, +419/-0)

PR #2395: SEP-2395: MCPS — Cryptographic Security Layer for MCP

Description (problem / solution / changelog)

Summary

This SEP proposes MCPS (MCP Secure), a cryptographic security layer for the Model Context Protocol. MCPS adds agent identity verification, per-message signing, tool definition integrity, and replay protection — without modifying the core protocol.

The Problem

  • 41% of MCP servers have zero authentication (TapAuth research)
  • CVE-2025-6514 (CVSS 9.6) — tool poisoning leading to RCE
  • CVE-2025-49596 (CVSS 9.4) — RCE via MCP Inspector
  • 13 of 39 agent frameworks failed an independent OWASP Agentic AI assessment

What MCPS Adds

FeatureDescription
Agent PassportsCryptographic identity credentials (ECDSA P-256)
Message SigningPer-message ECDSA signatures over JSON-RPC envelopes
Tool IntegritySigned tool definitions with change detection (rug pull protection)
Replay ProtectionNonce + timestamp window (default 300s)
Trust Levels L0-L4Progressive security adoption from none to full mutual auth
RevocationCRL-style and OCSP-style revocation checking

Design Principles

  • Fully backward-compatible — envelope model wraps existing JSON-RPC, non-MCPS endpoints unaffected
  • Self-hostable Trust Authority — no external service dependency, like TLS CAs
  • Complements existing OAuth SEPs — MCPS is message-level integrity, OAuth is session-level authorization
  • FIPS 186-4 compliant — ECDSA P-256 for enterprise/government deployments

Relationship to Existing Work

MCPS operates at a different layer than the current OAuth-based authorization SEPs (SEP-1046, SEP-1299, SEP-985):

LayerAnalogyAddressed By
Session authOAuth bearer tokenExisting OAuth SEPs
Transport securityTLSMCPS
Message integrityHTTP Signatures (RFC 9421)MCPS
Artifact signingCode signingMCPS

Reference Implementations

OWASP Risk Mitigation

Addresses 8 of 10 risks from the OWASP Top 10 for Agentic Applications and the OWASP MCP Top 10.

Seeking Sponsor

This SEP relates to the Security Interest Group and Server Identity Working Group. Tagging @pcarleton @dsp-ant @nickcoai for potential sponsorship.

cc: @dend @jenn-newton (Security IG)

Author: Raza Sharif, CyberSecAI Ltd License: Apache 2.0 (code/specs), CC-BY 4.0 (docs)

Changed files

  • docs/docs.json (modified, +6/-0)
  • docs/seps/2395-mcps-cryptographic-security-layer.mdx (added, +467/-0)
  • docs/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.mdx (modified, +2/-1)
  • docs/seps/index.mdx (modified, +2/-0)
  • seps/2395-mcps-cryptographic-security-layer.md (added, +448/-0)
RAW_BUFFERClick to expand / collapse

OWASP Agentic AI Top 10 -- Security Assessment

Hi team,

We conducted an OWASP Agentic AI Top 10 (2025) assessment of 27 popular AI agent frameworks as part of ongoing agentic security research. This assessment was performed via static analysis of public source code only -- no systems were accessed or tested remotely.

Assessment Results -- LangChain (Experimental)

CheckOWASP IDSeverityDetail
Unsafe ExecutionAA-03CRITICALexec() and eval() in Python REPL tool
Injection PatternAA-02CRITICALLLM-generated code executed directly in host process
Excessive PermissionsAA-04MEDIUMHigh-risk permissions: execute
Inadequate SandboxingAA-09HIGHNo process isolation for code execution

Risk Score: 73/100 (FAIL)

Published CVEs Referenced

This is not a new disclosure. These are all previously published:

CVEDetail
CVE-2023-29374Code injection via LLM output
CVE-2023-36258Code injection in PALChain
CVE-2023-39631Arbitrary code execution
CVE-2023-44467Code injection via prompt

Why This Matters

LangChain is one of the most widely used AI agent frameworks. While the dangerous patterns are primarily in langchain-experimental, the Python REPL tool and code execution utilities use exec() and eval() to run LLM-generated code directly in the host process. For users building production AI agents, these patterns represent a significant attack surface documented in 4 published CVEs.

We recognise that langchain-experimental carries an explicit warning about its nature. This assessment is intended to help users who may be deploying these components in production understand the associated risks mapped to the OWASP Agentic AI Top 10.

Agent Security Gates

As part of this research, we have built an open agent security assessment at agentsign.dev where developers and security teams can:

  • Scan any AI agent against the OWASP Agentic AI Top 10 (free, no account required)
  • Get an identity and trust score for agents before deploying to production
  • Gate agent execution via API -- block agents that fail security checks

Out of 27 agents assessed, 17 passed and 10 failed. Full results available on the platform.

Context

We are not claiming to have discovered these vulnerabilities -- all CVEs referenced above were reported by their original researchers. This assessment maps existing known issues to the OWASP Agentic AI Top 10 framework.

Happy to discuss any of these findings.

Raza Sharif Founder, CyberSecAI Ltd agentsign.dev

extent analysis

Fix Plan

To address the security vulnerabilities in LangChain, we will focus on the following steps:

  • Replace exec() and eval() with safer alternatives
  • Implement proper input validation and sanitization
  • Use process isolation for code execution
  • Limit permissions to the minimum required

Code Changes

Here are some example code changes to demonstrate the fixes:

Replace exec() and eval()

Instead of using exec() or eval() to execute LLM-generated code, consider using a safer alternative like ast module to parse and execute the code.

import ast

# Before
exec(llm_generated_code)

# After
try:
    tree = ast.parse(llm_generated_code)
    code_obj = compile(tree, filename="<ast>", mode="exec")
    exec(code_obj)
except SyntaxError as e:
    # Handle syntax error
    print(f"Syntax error: {e}")

Input Validation and Sanitization

Implement proper input validation and sanitization to prevent code injection attacks.

import re

# Before
user_input = input("Enter code: ")
exec(user_input)

# After
user_input = input("Enter code: ")
if not re.match(r"^[a-zA-Z0-9_]+$", user_input):
    # Handle invalid input
    print("Invalid input")
else:
    # Execute validated input
    exec(user_input)

Process Isolation

Use process isolation to execute code in a separate process, preventing it from accessing the host process.

import subprocess

# Before
exec(llm_generated_code)

# After
subprocess.run(["python", "-c", llm_generated_code])

Limit Permissions

Limit the permissions of the process executing the code to the minimum required.

import os

# Before
exec(llm_generated_code)

# After
os.setuid(0)  # Set UID to 0 (root)
os.setgid(0)  # Set GID to 0 (root)
exec(llm_generated_code)

Verification

To verify that the fixes worked, run the following tests:

  • Test the exec() replacement with a sample LLM-generated code
  • Test the input validation and sanitization with a sample user input
  • Test the process isolation with a sample code execution
  • Test the permission limitation with a sample code execution

Extra Tips

  • Always use the latest version of LangChain and its dependencies
  • Regularly update the langchain-experimental component to ensure you have the latest security patches
  • Consider using a Web Application Firewall (WAF) to detect and prevent common web attacks
  • Use a secure coding practice and follow the OWASP Agentic AI Top 10 guidelines to prevent security vulnerabilities.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#agent execution#prompt issue#agent setup#task chaining

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING