Crust sits between your coding agent and the LLM API and blocks tool calls it does not like
🌟 Open Source AI Agent Security Infrastructure — intercepts and blocks dangerous agent behaviors before they happen. Just one command! Join us to build safer Human-AI Symbiosis!
At a glance
- What is it?
- Crust is a Go gateway that proxies agent traffic to LLM providers and inspects tool calls in both directions. It is aimed at people running file-reading, shell-executing agents on their own machines, and its practical value depends on how much you trust a local rule engine to sit in the request path.
- Who is it for?
- Adopt Crust if you already run an agent that reads files and executes shell commands on a machine holding credentials, and you want a local checkpoint that does not require changing agent code. Do not adopt it if your agent talks to a provider over a protocol the proxy does not cover, or if you need the interception layer itself to be independently audited before it touches your traffic.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Crust targets: agents that read files and run commands
A coding agent with filesystem and shell access is a process that decides, at runtime, which paths to open and which commands to run. The README frames the goal bluntly: your agents should never read your secrets. That is the threat model. Not a remote attacker, not a supply chain compromise, but the agent itself taking an action that a human would have refused. The README states that Crust intercepts every tool call, including file reads, shell commands and network requests, and blocks dangerous actions before they execute, with no code changes required. The intended user is someone running an agent loop locally against a real repository, where an .env file, an SSH key or a cloud credential file is one tool call away. Crust is not a sandbox. It does not confine the agent's process. It sits in the network path and inspects the payloads that describe what the agent wants to do.
Five entry points and one shared evaluation pipeline
Crust does not have a single interception mechanism. The README lists five entry points, and the choice between them is the main architectural decision a user makes. The HTTP proxy, started with crust start, sits between the agent and the LLM API and scans tool calls in both the request (conversation history) and the response (new actions). The MCP stdio gateway, invoked with crust wrap, wraps any stdio MCP server and intercepts tools/call and resources/read in both directions, including what the README calls DLP scanning of server responses for leaked secrets. The same crust wrap command also acts as a reverse proxy for Streamable HTTP MCP servers, and as an ACP stdio proxy that intercepts file reads, writes and terminal commands before the IDE executes them. A fifth auto-detect mode inspects both MCP and ACP methods at once, for cases where you do not know which protocol a subprocess speaks. All five apply the same pipeline: self-protection, input sanitization, Unicode normalization, obfuscation detection, DLP secret scanning, path normalization, symlink resolution, and rule matching. The README claims each step runs in microseconds. That claim is not backed by a published benchmark in the material available, so treat it as an implementation note rather than a measured figure. The ordering matters more than the timing: Unicode normalization and obfuscation detection run before rule matching, which suggests the rule engine matches on a canonicalized form of the tool call rather than the raw bytes. Symlink resolution running before rule matching is the detail that makes path-based rules meaningful at all, since a rule that blocks /etc/shadow is trivial to defeat with a symlink otherwise.
Getting it running: install, crust start, and a base URL change
Installation is a shell one-liner on macOS, Linux and BSD: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/BakeLens/crust/main/install.sh)". On Windows the README gives a PowerShell equivalent using irm against install.ps1. There is also a Docker path: docker compose up -d uses the repository's included docker-compose.yml, or you can build with docker build -t crust https://github.com/BakeLens/crust.git and run docker run -p 9090:9090 crust. After install, the gateway starts with crust start. The README states that auto mode is the default, detecting your LLM provider from the model name with zero configuration, and that the agent's existing auth is passed through. Wiring an agent in is a base URL change, not a code change. Claude Code takes ANTHROPIC_BASE_URL=http://localhost:9090. Codex CLI, OpenCode and Aider take OPENAI_BASE_URL=http://localhost:9090/v1, with Aider using the OPENAI_API_BASE spelling. Cursor, Cline, Windsurf, JetBrains AI, Continue, Zed, Tabby, avante.nvim, codecompanion.nvim, CodeGPT and OpenClaw are each configured through their own settings field pointing at the same local address. OpenClaw's is baseUrl in ~/.openclaw/openclaw.json. Two details are worth flagging. First, the README notes that clients sending /api/v1/... paths, such as some JetBrains configurations, are also supported, which implies the proxy rewrites or tolerates non-standard base paths. Second, the port is 9090 everywhere in the examples, so running two agents against two differently configured Crust instances means changing that.
Where the design gets thin: rules, failure modes and the licence
The README never documents the rule format. It names rule matching as a pipeline stage and says dangerous actions are blocked, but the material supplied does not show a rule file, a config key for adding rules, or a list of what ships by default. That is the single largest gap for anyone evaluating this. A blocking gateway is only as good as its rules, and without the rule syntax in the README you cannot tell whether adding a path or a command pattern requires editing Go source, dropping a YAML file next to the binary, or something else. The second gap is failure behaviour. The README does not state what happens when the pipeline errors out, when the upstream provider returns a malformed response, or whether a rule engine crash fails open (traffic passes) or closed (agent stops). For a security control, that is the question that decides whether it is worth deploying. Third, the licence is genuinely ambiguous in the supplied material. The repository metadata reports NOASSERTION, while the README badge says Elastic 2.0. Elastic 2.0 is a source-available licence, not an OSI-approved open source licence, and it restricts offering the software as a hosted service. If you plan to embed Crust in a product, resolve that discrepancy before writing code against it. Nothing here is legal advice; read the LICENSE file in the repository. Finally, the project ships releases at a fast clip: v4.2.0, v4.3.0 and v4.4.0 all landed within a week in March 2026, and the last push to main is dated 2026-09-07. Frequent minor releases in a security tool mean the rule set and interception logic are moving, and any local fork or custom rule set will need rebasing.
What Crust is not, and what a policy engine like OPA does differently
The closest conceptual neighbour is a policy engine such as Open Policy Agent, and the difference is where the decision point lives. OPA evaluates policy over structured input that some other component hands it; you write Rego, you run a sidecar or a library, and you own the integration that feeds it tool-call data and enforces the verdict. Crust inverts that. It is the integration. It occupies the transport, whether that is the HTTP hop to the provider or the stdio pipe to an MCP or ACP server, and enforcement is built into the same process that observes the traffic. The upside is that you get interception without writing a line of glue. The downside is that you inherit Crust's rule vocabulary and its coverage. An OPA setup can express policy over anything your application emits; Crust can only see what flows through its five entry points. If your agent calls a tool that does not traverse the LLM API, an MCP server, or an ACP agent, Crust does not see it. That boundary is the honest way to think about the tool: it is a transport-level checkpoint, not a general authorization layer.
Local-only logging, encrypted storage, and what that implies for operations
The README states that all activity is logged locally to encrypted storage and that the tool is 100% local, with data never leaving the machine. For teams, that is both the selling point and the operational problem. There is no central aggregation described in the material, so if you deploy Crust on ten developer machines you have ten encrypted local logs and no stated mechanism for shipping or reviewing them together. The README also does not document the log format, the retention policy, or how the encryption key is managed. Until those are answered, treat the log as a local forensic artefact rather than an audit trail. The same locality applies to the DLP scanning of MCP server responses: the scan happens on your machine, which is good for confidentiality, but it also means the detection quality is whatever the local rule set provides.
Upgrade cost and the maintenance surface you are taking on
Three releases in six days, each a minor version bump, tells you the project is iterating on the interception logic rather than settling it. For a component in the request path, that is a real cost. Every upgrade is a chance for the pipeline to change behaviour in a way that blocks a tool call your agent depends on, and the README gives no compatibility statement for rule sets across versions. The install method is a curl-to-shell script, which means the upgrade path is either rerunning that script or pinning a release artefact yourself; the README does not describe a package manager route for any platform. The practical implication is that anyone adopting Crust should pin a specific version, keep a copy of the binary, and test the new release against their own agent workflow before swapping it in. The Docker path is the more reproducible option here, since docker build against a tagged commit gives you a fixed artefact rather than whatever the install script resolves to at run time.
Editorial conclusion
Adopt Crust if you already run an agent that reads files and executes shell commands on a machine holding credentials, and you want a local checkpoint that does not require changing agent code. Do not adopt it if your agent talks to a provider over a protocol the proxy does not cover, or if you need the interception layer itself to be independently audited before it touches your traffic. Verify three things first: that the NOASSERTION licence metadata matches the Elastic 2.0 badge in the README, whether the rule set is editable without rebuilding the binary, and what the encrypted local logs contain and how they are rotated.
Community notes