Skip to content
RCreddit.com·

An open-source tool that finds the AI agents on a machine, maps what they can reach, and guards their tool calls

AI summary

CSL-Core is an open-source tool designed to secure AI agents that use real-world tools like shell commands or file writes. It addresses the limitations of prompt-based safeguards, which are not always reliable and lack a record. CSL-Core enforces limits outside the AI model, identifying agents, mapping their access, and guarding their tool calls to prevent unintended actions. The developer asks where others enforce limits and if agents have ever accessed unexpected resources.

Time & source

Times shown in UTC

Display time zone: UTC

Local time zone unavailable; showing UTC.

PublishedOffset at this time: UTC+0Oct 9, 2026, 13:09 UTC

IngestedOffset at this time: UTC+0Oct 9, 2026, 14:00 UTC

Published
Oct 9, 2026, 13:09
Ingested
Oct 9, 2026, 14:00
Source type
Dev community
Tier
Community
Source status
Healthy

Tier is a per-source editorial setting, not a per-item score.

AI agents now get real tools: refunds, shell commands, file writes, posting to Slack. The usual safeguard is a line in the prompt ("never refund more than $500"), which holds most of the time, not every time, and leaves no record. I built CSL-Core to enforce these limits outside the model instead. It's open source and runs locally. Here's how it approaches the problem, and most of it applies whatever you use.

Inventory first. You can't guard agents you don't know about. CSL-Core scans a machine for coding assistants, MCP servers, LangChain / OpenAI Agents / CrewAI tools, cron jobs and webhooks, and classifies each tool by what it can do: read, write, run commands, spend money, delete. The scan is read-only and never executes your code.

The risk is in the chain. Each agent usually looks harmless on its own. The danger shows up in how they connect: an agent that reads web pages can edit the files of another agent that runs as root, or an inbound webhook reaches an agent that can move money. Nobody designs these paths; they accumulate. The tool draws them as a map and highlights the chains, so you can see which single rule would break each one.

Enforce before the function runs. Money tools get a per-call ceiling and an approval threshold, commands an allowlist, file writes a folder scope. Each policy is checked with the Z3 solver for contradictions before it goes live. The call is decided before the tool function runs, and the model never sees the rules, so it can't argue past them.

Guards break in the glue code. A rule like "only write inside /srv/app" is easy to state. The code that turns a real call into what the rule checks is where bypasses happen:

- /srv/app/../etc/passwd passing a prefix check (resolve the real path first, then compare)

- /srv/app-backup passing as /srv/app (compare path components, not strings)

- ls; rm -rf ~ passing "starts with ls" (parse the command; reject ;, |, &&, $() and backticks)

- https://api.stripe.com@evil.example passing "contains api.stripe.com" (parse the URL and compare the hostname exactly)

CSL-Core tests every mapping against trick families like these, but the checks above are worth adding to any guard you write yourself.

Log before you block. Strict rules on day one break real work, and then the guard gets switched off. In log mode nothing is blocked: every call is recorded as "allow" or "would block", so you can tune the rules before you enforce them.

Unknown should mean deny. Agents gain tools over time through plugins, new MCP servers or a teammate's PR. A tool the guard doesn't recognise is denied, not allowed, and CI fails when someone adds a tool that can spend money or run commands without a rule.

Honest limit: the default rules are strict, so expect to tune them on a busy agent.

If you run agents with real tools: where do you enforce limits today, and has one ever reached something you didn't expect?

Source·reddit.com