varden 0.1.1

A self-hosted runtime firewall for AI agents

Varden

Using Varden? I read everything — open a blank issue titled "Using this" Your developers are using Cursor. It's calling APIs, running git commands, talking to external services, executing shell commands.

Do you know what it's doing?

Now multiply that by a team of ten, all running AI agents with MCP access to your infrastructure. Nobody has a list of what those agents can touch. Nobody sees it when one does something unexpected.

Varden is the thing watching.

---

Try it now

# 1. Install
git clone https://github.com/markndg/varden
cd varden
python -m venv .venv && source .venv/bin/activate
pip install -e .

# 2. Start Varden
python -m varden.api --config examples/dev.env

# 3. In a second terminal — wrap Cursor
export VARDEN_BASE_URL=http://127.0.0.1:8000
export VARDEN_API_KEY=admin-demo-key
varden session . -- cursor .

Subprocess calls, HTTP requests, and LLM calls that Cursor makes now appear in your dashboard — blocked, warned, or logged according to your policy.

Note: Varden intercepts via a PATH shim. Child processes Cursor spawns will be covered; processes Cursor launches outside the shell PATH may not be. Use an interactive varden session shell for broadest coverage.

---

One line protects your Python agents

import varden
import requests

varden.protect()

# Everything below is now intercepted, checked against policy, and logged.
# Nothing changes in your code. Everything changes in your visibility.
requests.post("https://partner.example/api", json={"token": "abc123"})

Varden patches the Python runtime — requests, httpx, subprocess, OpenAI, Anthropic — so every action is checked before it runs. Your developers add one line. You get a dashboard full of traces.

---

What Varden covers

Action type	What gets checked
Tool calls	MCP tool calls, before execution
HTTP/API requests	Outbound calls, including payload classification
Subprocess execution	Shell commands, before they run
LLM calls	Provider calls to OpenAI, Anthropic, others
CLI tools	kubectl, terraform, aws, gcloud, git, docker, cursor — via varden session

Decisions are allow, warn, block, or monitor. Every decision lands in the dashboard with classifiers, risk scores, and a full trace.

---

Rule impact intelligence

Know which rules are working, which are over-firing, and where your coverage gaps are.

Every rule shows its detection count, coverage percentage, false positive proxy, and which agents and tools it's touching. The drilldown panel shows the most recent decision for any rule in one click.

---

Why self-hosted matters

Most AI security products inspect prompts in the cloud. Your data leaves your infrastructure to be evaluated by someone else's service.

Varden runs on your infrastructure. Your policy file, your data, your control plane. No traffic leaves unless you decide it does.

---

Quickstart

1. Install

git clone https://github.com/markndg/varden
cd varden
python -m venv .venv && source .venv/bin/activate
pip install -e .

2. Create a policy

python -c "import json, pathlib; p=pathlib.Path('policy-packs/baseline-operational-safety.json'); pathlib.Path('policy.json').write_text(json.dumps(json.loads(p.read_text(encoding='utf-8'))['template'], indent=2) + '\n', encoding='utf-8')"

3. Start Varden

python -m varden.api --config examples/dev.env

4. Open the dashboard

• Dashboard: http://127.0.0.1:8000/
• Rules editor: http://127.0.0.1:8000/ui/rules
• API docs: http://127.0.0.1:8000/docs
• Bootstrap key: admin-demo-key

5. Run the demo

python -m varden.cli demo

Shows a blocked action, a warned action, and a clean allowed action — all visible in the dashboard immediately.

---

Policy model

Policies are a JSON file with four lists: block, warn, monitor, allow.

{
  "block": [
    {"type": "tool_call", "tool": "delete_database"},
    {"type": "tool_call", "tool": "subprocess.run", "field:args.args": {"contains": "delete_database"}}
  ],
  "warn": [
    {"classifier:secrets": true},
    {"classifier:internal": true}
  ],
  "monitor": [],
  "allow": []
}

Rules are evaluated in order: block → warn → monitor → allow. First match wins. Edit visually at /ui/rules or directly in the JSON file. Policy versions are tracked.

---

LangChain integration

import varden
from varden_langchain import protect_tools

varden.protect_from_env(auto_instrument=False)
tools = protect_tools(tools, agent_name='support-agent')

Pre-execution allow / warn / block on every tool call, with full trace visibility in the dashboard. Drop-in — no changes to your agent architecture.

Demos:

python demos/langchain/allow_warn_block_demo.py
python demos/langchain/sql_guard_demo.py
python demos/langchain/exfiltration_demo.py

varden session: wrap any CLI tool

The session command starts a shell with a PATH prefix so selected binaries route through Varden before running. Use it to watch — and enforce policy on — any tool your team or their agents call.

# Watch what Cursor does in the current directory
varden session . -- cursor .

# One-shot: guard a single kubectl command
varden session -- kubectl delete pod my-pod

# Passive mode: log without blocking
varden session --passive

Shimmed by default: cursor, kubectl, terraform, aws, gcloud, az, docker, docker-compose, git, npm, pip, pip3, railway, supabase, vercel, fly, render, psql, mysql.

---

Self-hosting

docker compose -f deploy/docker-compose.yml up

See deploy/self_hosting.md and deploy/operations.md for production configuration. Local defaults use SQLite. Production self-hosting should use a strong signing secret and disable the dev bootstrap auth.

---

Licence

Core platform and dashboard: AGPL-3.0 SDKs (sdks/python, sdks/java, sdks/rust): Apache-2.0

Commercial licence available for teams that cannot accept AGPL obligations — see COMMERCIAL.md.