wardline
Supports CrewAI agents with Wardline's control-plane proxy, enforcing policies and automatically blocking compromised agents.
Allows LangChain agents to route tool calls through Wardline for policy enforcement, budget control, and anomaly detection.
Integrates with the OpenAI Agents SDK to apply Wardline's policy, budget, and anomaly detection to agent tool calls.
The control-plane proxy that auto-blocks compromised AI agents, all from one static Go binary.
Give an AI agent a thousand tools and no one watching it, and sooner or later it does something you didn't plan for. Maybe it gets prompt-injected. Maybe someone jailbreaks it. Maybe it just goes wrong on its own. However it happens, it starts calling things it never should, and you never wrote a rule to stop that, because you had no idea it was coming.
Wardline sits between your agents and everything they call: MCP servers, tools, gRPC upstreams. Every call goes through it, and on the way it checks who's asking, whether policy allows it, whether there's budget left, and it writes the decision down. Then it does the part a rulebook can't. It learns how each agent normally behaves, and the moment one stops acting like itself, it shuts it down. Right then, while it's happening. No rule for the specific attack, nobody woken up at 2am.
It's a single Go binary. No database to run, no identity provider to wire up, no sidecar. You download it and start it.
See it for yourself
A normal agent goes about its work, gets compromised partway through, and gets shut down for it. This is a real run, not a mockup:
make demo # runs exactly this on your machine, in about 30 secondsAnd here's the whole thing from the operator's side. You sign in, and there's the agent that got blocked, the anomaly that gave it away, the policy it was working against, and who's even allowed to touch any of it:
How it works
Anything that calls a tool (an AI agent, your CLI or IDE, an app) can only reach its upstreams by going through Wardline first. On the way through, it checks identity, applies policy, counts the call against the budget, runs it past anomaly detection, and records what it decided. Then it forwards the call, or it doesn't.
Full design: Architecture.
Related MCP server: guardrails-mcp-server
What it does
The baseline (proxy, policy, audit) is always on. Everything else is one config flag away.
Catches a compromised agent on its own. Seven detectors watch each agent and learn its normal rhythm as it runs: sudden spikes, tools it has never called before, a climbing deny rate, a combined z-score, a slow drift that no single moment looks wrong on, patterns across a whole tenant, and floods of brand-new identities. There's no training data and nothing to host. When one trips, the agent is actually blocked for a while, not just written to a log. The real hit rates, and the honest gaps, are in the recall benchmark.
Write policy three ways, still one binary. Plain YAML, OPA/Rego, or AWS Cedar. You pick one with a config key. Nothing external to run, no network hop.
Real identity, not a header you have to trust. Short-lived signed tokens with refresh and key rotation, sign-in over OIDC or mTLS/SPIFFE, Kubernetes-style RBAC, SCIM for provisioning, and hard tenant isolation.
Budgets that actually stop a call. Limits per agent and per tenant. A call has to clear both to go through.
An audit trail an auditor can use. Every decision as structured JSON, a signed evidence bundle you can hand over, retention you control, and a command that reads your real traffic and writes you a starting allow-list.
See it and scale it. Correlation across instances, OpenTelemetry traces, Prometheus metrics, a live dashboard, and multi-replica HA backed by Postgres.
Getting Started
# From source (always works)
go build -o wardline ./cmd/wardline
# Or pull the published multi-arch image (built for each tagged release)
docker pull ghcr.io/kabirnarang39/wardline:latest./wardline validate-policy --file policy.yaml.example
./wardline validate-config --config wardline.yaml.example
./wardline serve --config wardline.yaml.examplePoint upstream at a real MCP server. Until you do, a proxied call just returns 502 (for a quick test, python3 -m http.server 9000 is enough). Every request carries an X-Wardline-Identity header, and policy matches on that value plus the MCP tool name:
curl -X POST http://localhost:8080 \
-H "X-Wardline-Identity: agent-abc123" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"read_file"}}'Here, X-Wardline-Identity is just a plain header with nothing behind it, so anyone who can reach the proxy can claim to be anyone. That's fine for a local smoke test with no real upstream. It is not fine for anything someone else can reach. Before you point this at a real upstream, turn on credential_issuance (so a signed token replaces the header anyone could fake) and rbac. See Hardening below.
Prebuilt binaries (linux/darwin/windows · amd64/arm64) and multi-arch images ship on every v* tag via Releases and GHCR.
Documentation
Full docs, per-feature design notes, and honest known-limitations live on the docs site:
Getting Started: install, quickstart, configuration
Concepts: architecture, policy backends, identity, audit
Features: every capability in depth
Deployment: Docker, Helm, HA, observability
Framework integrations: LangChain, LlamaIndex, OpenAI Agents SDK, CrewAI, raw MCP
Full capability list
Everything below is shipped and testable under internal/features/. The v0.1 baseline (proxy + policy + audit) is always on; everything else is gated by a config flag.
Capability | Docs |
Policy backends: YAML · OPA/Rego · AWS Cedar | |
Anomaly detection + auto-block | |
Budget enforcement (per-identity + per-tenant) | |
Credential issuance (JWT + refresh + JWKS) | |
SSO (OIDC) / mTLS-SPIFFE bootstrap | |
RBAC + SCIM + tenancy | |
Federation (cross-instance correlation) | |
Compliance evidence export + retention | |
Auto-generated sandbox policy | |
Policy packs (12 embedded + | |
gRPC transport passthrough | |
Postgres storage + HA deployment | |
Web dashboard | |
OpenTelemetry tracing | |
Prometheus metrics ( | |
Taint tracking (untrusted-read gating) | |
Approval workflow (needs_approval + approve-and-retry) | |
Per-job budget ceiling (hard cap per tenant/identity/session job) | |
Per-job cost/token budget (declared per-tool cost, not just call count) |
Performance
These are real go test -bench numbers you can reproduce, not figures off a slide:
Policy decision: about 33 ns and zero allocations at 10 rules (YAML backend, Apple Silicon), around 2.4 µs at 1000 rules.
The full seven-detector stack: about 299 ns per call and 5 allocations with everything on (around 255 ns for the original four).
Race-tested: 205 goroutines at once (5 tenants, 40 identities each, plus 5 attackers) all hitting one shared
Detectorundergo test -race, with no data race.False positives:
ml_scorestays at 0 out of 6,000 windows across 20 seeds on steady traffic.
The full recall curve for each attack shape, plus the adversarial battery (sybil, mimicry ceiling, burst-pause, disposable-identity rotation), are in the recall benchmark.
Security
By default, the dashboard and the X-Wardline-Identity header are unauthenticated. Turn on credential_issuance and/or rbac before they count as security at all. Everything optional is off by default and fails closed, and on startup Wardline prints a WARN for every insecure default you've left in place, so you're never guessing about where you stand. Found a vulnerability? See SECURITY.md.
Hardening
Out of the box the proxy fails closed on policy, but identity and the dashboard are wide open. For anything real, turn these on:
features:
credential_issuance: true # verify a signed bearer token instead of trusting X-Wardline-Identity
rbac: true # gate the dashboard and admin actions on real permissionsWith credential_issuance on, a signed token replaces the header anyone could fake. With rbac on, both viewing the dashboard and changing anything require an identity that's actually allowed to. One thing worth being honest about: ml_score and auto_block catch loud, sudden abuse well, but not a slow ramp. drift_detection (a CUSUM control chart, on by default in the shipped config) closes most of that gap, and the measured numbers are in the recall benchmark. One real gap stays: an attacker who has read the public thresholds can hold a roughly 1.15x ramp forever, which is written up plainly in known limitations. So keep explicit policy and budget limits as your hard floor no matter what.
Project status
Wardline is young and moving fast. Every feature's docs page is deliberately blunt about what it does and doesn't do. Feedback, issues, and contributions are welcome, especially on the anomaly-detection approach and threat model.
Contributing
See CONTRIBUTING.md and CODE_OF_CONDUCT.md. Architecture and engineering conventions are documented in CLAUDE.md; the roadmap lives in the docs.
License
This server cannot be installed
Maintenance
Related MCP Servers
- Flicense-quality-maintenanceA transparent proxy and execution firewall that intercepts and audits AI agent tool calls against configurable security policies before forwarding them to downstream MCP servers. It provides safe execution environments with features like data redaction, anti-loop protection, and unified alert dispatching.
- Alicense-qualityCmaintenanceMCP server for AI agent security guardrails. Provides input validation, prompt injection detection, PII redaction, output filtering, policy enforcement, rate limiting, and comprehensive audit logging.461MIT
- Alicense-qualityAmaintenanceA local-first control plane for AI agent tools, providing policy enforcement, spend caps, rate limiting, and audit trails for MCP servers.1Apache 2.0
- Alicense-qualityBmaintenanceCentralized MCP control plane that proxies multiple upstream MCP servers with tool namespacing, filtering, policy enforcement, audit logging, and health checks.7MIT
Related MCP Connectors
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kabirnarang39/wardline'
If you have feedback or need assistance with the MCP directory API, please join our Discord server