CSL-Core: Adding Verifiable Security Policies to LangChain Agent Tool Calls

When AI Agents Can Move Money, Who Hits the Brakes?

As LangChain agents become increasingly common in production environments, a long-overlooked problem is starting to surface: when you equip an agent with tools like refund_order or run_sql, what exactly is stopping it from doing something it shouldn't?

A developer shared his frustration on Reddit — he kept deploying LangChain agents with tools but could never answer a fundamental question: "What mechanism ensures this tool won't go out of bounds?" Prompt rules work most of the time, but not every time, and when something goes wrong, there's no audit trail to trace back.

To address this pain point, he built an open-source CLI tool called CSL-Core. The core idea: add a formally verified policy checkpoint before every tool call — without touching any existing prompts.

Taking Control from the Outside: Three Steps to Build Safety Guardrails

CSL-Core's most important design principle is that it "works from the outside." It doesn't intrude on your prompt logic — instead, it establishes a control layer around the critical moment of tool invocation. The process has three phases.

Step 1: Scan and Discover Agents and Tools

Running cslcore venom performs a read-only scan of your codebase, identifying @tool-decorated functions, StructuredTool instances, LangGraph nodes, OpenAI / Anthropic tool schemas, MCP servers, and webhooks.

The scan clearly maps out the capability boundary each agent can reach — for example: inbound HTTP /webhooks/zendesk → support-agent → moves money. This visual "capability graph" makes hidden risk paths immediately obvious.

Step 2: Generate Policies for Each Agent

Tools are assigned different policy constraints based on their type:

• Money-touching tools: per-call ceiling and approval threshold
• Command-executing tools: allowlist mechanism
• Write operations: folder scope restriction

One important technical detail: every policy is validated with the Z3 theorem prover before it takes effect. Z3 is a well-known constraint solver developed by Microsoft Research. Using it to check policies means these rules are mathematically satisfiable and non-contradictory — not just "seemingly reasonable."

The Z3 Theorem Prover is a high-performance SMT (Satisfiability Modulo Theories) solver developed by Microsoft Research, widely used in program verification, security analysis, and formal methods. Its core capability is automatically determining whether a set of constraints has a satisfying solution (satisfiability), or whether it holds in all cases (validity). In CSL-Core's context, Z3 is used to verify that a policy's rules are internally consistent before they go live — for example, confirming that "a $100 ceiling" and "a $50 approval threshold" don't logically contradict each other, or that an allowlist rule doesn't accidentally override a deny rule. This is fundamentally different from the traditional engineering approach of "write the rule, then test if it works": formal verification can prove in mathematical terms that a rule has no loopholes, rather than relying on test case coverage. For security policies involving financial operations, this level of rigor is especially important.

Step 3: Wire into Your Code as a Diff

CSL-Core adds a second decorator just below LangChain's own @tool decorator:

@_csl_guard.tool("refund_order")
def refund_order(order_id: str, amount: int) -> str:
    ...

The clever part: the tool retains its original name, docstring, and parameter schema, so LangChain still sees the exact same tool — existing logic is left intact. Every call goes through a decision before the function executes — a blocked call raises an exception before any money moves. All changes are presented as diffs first, and cslcore wire --undo restores files to their original state, lowering the barrier to adoption.

Prompt Injection is one of the primary attack surfaces for LLM agents today: attackers embed malicious instructions in input data to trick the model into ignoring system-level safety rules and performing unintended actions. This is precisely why relying purely on prompts to constrain tool behavior has a fundamental vulnerability — language models are, at their core, statistical predictors of natural language instructions and cannot follow rules with the same deterministic guarantees that code logic can. Model hallucination (when a model confidently outputs incorrect information or calls tools with wrong parameters) and edge cases (rare scenarios not covered by training data) can similarly bypass soft prompt-level constraints. CSL-Core pushes security controls down to the execution layer of function calls, making them hard constraints that are completely decoupled from language model behavior — fundamentally avoiding this entire category of risk.

Observe First, Block Later: The Pragmatic Design of Log Mode

Directly enabling enforcement in production often causes false positives that disrupt legitimate business operations. CSL-Core addresses this with a gradual activation path.

Tools start in log mode by default: no calls are blocked, but every call is recorded as either allow or would-block. This lets you clearly see what your current rules would actually do before you switch to block mode. cslcore watch lets you observe the decision process in real time.

This "shadow-run first, enforce later" approach mirrors mature security systems like WAF detection/blocking mode switching — reflecting the author's understanding of real-world production constraints.

Shifting Security Left into the CI Pipeline

CSL-Core also addresses continuous integration. The cslcore venom --check --fail-on-new-reach command fails the build whenever someone adds a tool that can move money, execute commands, or publish externally — without a corresponding policy in place.

This effectively shifts agent permission auditing left from runtime to the commit stage, preventing dangerous tools from quietly entering production unnoticed. For team-based projects, this is a particularly valuable line of defense.

Shift Left Security is a core concept in DevSecOps: moving security checks as early as possible in the software development lifecycle — from post-deployment detection to the code commit, build, or even design phase. The core logic is that the earlier a problem is found, the lower the cost to fix it, while also preventing vulnerabilities from reaching production and causing business damage or reputational risk. In the context of AI agents, "shifting left" means developers must provide a corresponding permission policy when adding a new tool to the codebase — rather than scrambling to respond after an agent exceeds its authority in production. CI gate mechanisms like --fail-on-new-reach distribute security review responsibility across every code change, rather than concentrating it in a manual audit before deployment.

Honest Limitations

The author doesn't sidestep the tool's shortcomings — which is commendable. He explicitly calls out several limitations:

• Default rules lean strict: Before switching a busy agent to block mode, expect to tune the rules — which is exactly why log mode exists.
• Pure schema tools need manual handling: For tools that exist only as schemas and are dispatched by your own code, decorators aren't applicable. You'll need to add a guard.check(...) call — and the tool will tell you exactly where.

Getting started is straightforward: install with pip install csl-core, then run cslcore setup in your repository. The entire process remains read-only until you confirm each change, and all data stays local — nothing is sent externally.

A Question Worth the Entire Industry's Attention

At the end of his post, the author poses two questions aimed at practitioners running production systems — questions that hit directly at the governance gap in today's AI agent ecosystem:

How are you limiting what a tool can do today — inside the tool, in the prompt, or not at all?

What would you most want a policy to block first?

The real-world significance of these questions is that most teams today still rely on prompt-level "soft constraints" — and prompt injection, model hallucination, and edge cases can all cause that layer to fail. CSL-Core represents a more engineering-driven approach: pushing security controls down to the execution layer of tool calls, using verifiable policies rather than natural language rules as the last line of defense.

As agents are granted more and more real-world operational permissions, these kinds of "deterministic guardrails" may well shift from nice-to-have to a hard requirement for production deployment. Whether CSL-Core is mature enough for direct production use still needs to be validated in practice — but the problem framework it articulates is one every team deploying LangChain agents should take seriously.