Hi,
As I enjoy building software around difficult problems, ive spent the last 5-6 months designing and building an open-source agent control plane called Varden. I wanted to share some of the architectural approach I took to secure the execution layer, and get feedback from other people on how you are monitoring this.
Interception Hooks and CLI Shimming
Varden sits directly between the agent’s reasoning loop and its execution environment, acting as an active runtime firewall. It splits security into two layers:
1. The Interception Hook (varden.protect())
Instead of just hoping tool-calling prompts hold up, Varden wraps the execution logic. Based on your active policies, it evaluates incoming tool requests in real-time, triaging them into Allow, Warn (requires human-in-the-loop approval), or Block modes. It supports both a low-overhead fast scan and a full deep scan for classification. I have tried to implement this with as low overhead as possible so in python with use of monkey-patching, varden.protect() is all that is needed in the code. Ive also added some basic sdk for java and rust along with demos of lang chain integration.
2. Local CLI Sandboxing via varden session
One of the hardest problems was catching agents that try to execute system-level commands through subprocess shells (e.g., executing kubectl, terraform, aws, or git directly).
To solve this without spinning up heavy, slow Docker containers for every single minor agent step, Varden uses a temporary PATH prefix injection. When you run your agent via varden session, it shims local CLI tools. If the agent tries to run an unapproved bash hook or access an environment variable it shouldn’t, Varden intercepts the call before it hits the actual system binary.
It’s structured as a Rust-core monorepo with lightweight SDKs (Rust, Python, Java, LangChain adapters) and a React/TypeScript telemetry dashboard to link parent/child trace IDs so you can actually audit an agent’s chain of thought when a policy triggers.
3. User-defined rules
I have tried to build a feature rich UI to define rules, it ships with a core set but also allows users to implement their own and upload. It’s maybe a bit clunky but will continue to work on it.
4. Coverage gaps
The start of a page to see if its possible to work out which issues are not captured in current rules but close enough to existing to warrant the possible implementation.
Repo: github.com/markndg/varden (AGPL-3.0 Core / Apache-2.0 SDKs)
While Varden works as a firewall, a major cause of runtime policy violations is model behavioral drift. When a cloud provider rolls out an unexpected model iteration or deprecation, the model might suddenly change its formatting, drop specific validation keys, or become more susceptible to instruction failures.
To tackle this pre-deployment side of the house, I built a companion tool called ARSENIC (previous post) —a differential behavioral testing engine that uses deterministic, sentence-level claim cross-matching to flag silent regressions before code hits production. I recently added the ability to hook it into CI/CD workflows (arsenic-action).
Next ideas on my roadmap are linking the two tools together into a closed-loop system:
-
Pre-Flight (ARSENIC): CI pipeline automatically tests prompt corpus against new model versions. If it catches a behavioral regression or an over-hedging issue, it flags it.
-
Post-Flight/Runtime (Varden): ARSENIC would automatically export a temporary warning rule into Varden. The Varden control plane then actively monitors live production logs for those specific failure signatures, protecting your system while working on a permanent prompt patch.
Still lots of work to do but I would love to get your thoughts on this and the integration path between my two tools.