Warden

The secure gateway connecting AI agents to the enterprise systems they need to do real work.

Agents discover what they're allowed to access. Warden brokers every connection. Operators get one control plane for identity, policy, and audit — across every MCP server, cloud, code-host, observability stack, database, and SaaS the agent reaches.

Try it in five minutes

The playground is Warden with everything it protects already in place: its own identity provider, and a small bank to govern. Start it:

docker run --rm --name warden-playground -p 127.0.0.1:8400:8400 \
  ghcr.io/stephnangue/warden:latest -dev-playground -dev-root-token=root

Then open Getting started and pick your agent — Claude Code, Codex, Cursor, Gemini CLI, opencode, VS Code, or any MCP client. The tour is written out for each. In nine short scenarios your agent holds no secret while Warden brings the bank's credential, policy decides its tools and then its arguments, it acts for a person, a prompt-injected memo fails to move the money, every call is audited, the agent finds its own roles — and the last scenario puts your own GitHub behind Warden. There's no identity provider to set up and no API key to find.

---

The problem

Agents are useful only when they reach real systems: cloud accounts, code repositories, observability stacks, databases, ITSM, secrets backends. Today, pointing an agent at production means handing it over-scoped, long-lived credentials, with no per-request policy and no identity-tied audit. Each new system is another credential in the agent's environment, governed by nothing in the request path.

The control gap, not the credential, is the headline. MCP servers make it acute — every server wraps one upstream API and holds one credential in process env, so an agent with a dozen tools has a dozen static secrets scattered across a dozen processes, none of them rotating, none of them governed.

How Warden works

Warden sits in the request path between an agent and the systems it needs. The agent presents its own identity — a JWT, TLS client certificate, SPIFFE SVID, or Kubernetes service-account token — and points at Warden as if it were the upstream.

┌──────────────┐                      ┌──────────────┐                      ┌──────────────┐
│              │    identity only     │              │   real credentials   │ MCP servers  │
│   AI Agent   │ ───────────────────▶ │    Warden    │ ───────────────────▶ │ Cloud · LLMs │
│              │ ◀─────────────────── │              │ ◀─────────────────── │ Code · SaaS  │
│              │       response       │              │       response       │ ...          │
└──────────────┘                      └──────────────┘                      └──────────────┘
                                      • Identity ✓
                                      • Policy ✓
                                      • Audit ✓

For each request, Warden authenticates the identity, evaluates the call against policy at request time, injects the real upstream credential, and proxies it — streaming the response back unchanged. The agent holds no secrets, gets exactly the access its policy permits — no more — and every call is tied to its identity in the audit log.

Warden need not hold a standing secret at all. Rather than storing an upstream's key, it can prove who the caller is to the upstream and let the upstream mint the credential itself — or fetch a needed secret from an external vault per request and forget it — so there is no secret trove at the gateway to breach. And a request can carry a second identity: the person the agent is acting for. Warden verifies both, so the upstream can authorize the real human, not just the agent — even for systems that have no built-in way to act on someone's behalf.

Agents don't need that access wired in ahead of time. They can ask Warden which roles and systems are open to them and read a per-system recipe at runtime, then connect — so a newly mounted system is reachable without redistributing config or rebuilding an SDK. See the agent flow for the full loop.

Agent identity and governance

Register every agent, name the team that answers for it, and refuse the ones nobody claimed. A credential proves which workload is calling, not who is accountable for it, so Warden keeps each agent in its identity store: the identity it presents, and the team that sponsors it. A registered agent holds only the roles granted to it by name, and only while its team stands behind it; one whose sponsor steps away, or that is suspended, loses them on its next call. Start by watching: Warden records which callers it would refuse. When every agent you rely on is registered, turn refusal on, and an agent nobody claimed gets nothing. People sign in with their company login and hold the roles their identity provider's groups give them, including built-in roles for running Warden itself. See Identity and access.

Use cases

• Access brokering — Warden brokers the upstream credential into each request while the agent presents only its own identity — a JWT, a TLS client certificate, or a SPIFFE SVID — and never holds a key. Warden itself need not hold the secret either — it can prove the caller's identity so the upstream mints the credential, fetch the secret from your own store per request, or hold it and inject a scoped, short-lived credential. The same identity reaches every upstream the policy permits, so there's no per-system credential sprawl, nothing to rotate per integration, and nothing in the agent to leak.
• Breach containment — a prompt-injected, jailbroken, or otherwise compromised agent has nothing to exfiltrate, because it never holds a credential — and in Warden's keyless modes there is no secret trove at the gateway to steal either. Every call it issues is still bounded by policy at request time and backed by short-lived access, so one bad step — or one hallucination — stays a contained, recoverable event instead of a broad compromise.
• Per-user access — an agent can act on behalf of the verified person behind it, so the upstream authorizes the real human with their own scope — not a shared service identity — and every action is attributed to that person. It works even for upstreams with no built-in way to act on someone's behalf, and scales to a whole fleet of users without a separate role for each.
• Runtime authorization — every call is authorized the moment it happens, down to the action and its arguments, evaluated against caller IP, time of day, day of week, and on whose behalf the agent is acting — the verified attributes its identity carries, so a shared agent still admits one principal and refuses another. For MCP traffic the policy reaches inside each tool call — which tools an agent may invoke and which arguments it may pass — so the agent gets the narrowest fit for each step, not a session-wide grant.
• Centralized governance — one control plane for every system an agent touches: one identity, one policy surface, and one audit log across clouds, code hosts, observability, databases, SaaS, and MCP servers. Namespaces isolate teams on shared infrastructure, and Warden rotates any upstream secrets it does hold on a schedule, so they stay fresh without operator coordination.
• Audit & attribution — every request tied to the real identity behind it, the role used, the policy decision, and the upstream called — including the decision recorded on each MCP tool call. A shared MCP server acting for many agents still resolves to the specific agent it acted for, and secrets are never written to the log in the clear.

See the use-case guides for the full write-ups.

Supported systems

Warden fronts systems across MCP servers, LLMs, cloud, code-hosting, observability, ITSM, Kubernetes, secrets, and databases. Follow any link below to configure your first endpoint, or see docs/provider-backends/README.md for the full list.

Category	Providers	Warden does
MCP servers	Generic — GitHub, Google Cloud, Slack, Cloudflare, …; AWS (SigV4)	Proxies tool calls — injects credentials, enforces tool-level policy
LLM APIs	Anthropic, OpenAI, Mistral, Cohere, Amazon Bedrock	Injects a short-lived token (keyless) or API key
Cloud infrastructure	AWS, Azure, GCP, Alicloud, IBM Cloud, OVH, Scaleway, Cloudflare	Temporary credentials / Bearer tokens
Code hosting & CI/CD	GitHub, GitLab, Atlassian, Ansible Tower, Terraform Enterprise	Injects App token, PAT, or Bearer token
Observability	Datadog, Dynatrace, Elastic, Grafana, Honeycomb, New Relic, Prometheus, Sentry, Splunk	Injects API key / proxies metrics
Microsoft 365	Microsoft Graph — mail, calendar, Teams, SharePoint, OneDrive, Entra ID	Calls Graph as the signed-in person the agent acts for, or as the app
Incident & ITSM	PagerDuty, ServiceNow, Slack	Injects Bearer token
Kubernetes	Kubernetes	Injects service account token
Secrets backend	HashiCorp Vault / OpenBao	Mints short-lived tokens
Databases	AWS RDS / Aurora, AWS Redshift	Issues IAM database auth token

Authentication methods

Agents prove who they are with the methods below; none binds a role at login, since groups grant roles on every request. People sign in with their company login.

Method	Identity Source	How the agent presents the credential to its SDK
JWT	Signed JWT token	The same JWT goes in whichever credential slot the upstream SDK natively expects (AWS_SECRET_ACCESS_KEY, OPENAI_API_KEY, X-Vault-Token, Authorization: Bearer, …). Warden detects it, validates the identity, and swaps in the real upstream credential. Existing SDK code keeps working — only the base URL changes.
TLS Certificate	X.509 client certificate	Identity is proven at the TLS handshake (or forwarded by a TLS-terminating proxy via X-SSL-Client-Cert). The SDK's credential slot is filled with any placeholder value — Warden ignores it once cert auth has proven the identity. Role selection follows the same per-provider conventions as JWT mode.
SPIFFE	SPIFFE X.509-SVID or JWT-SVID	First-class SPIFFE identity on a single mount: a workload presents an X.509-SVID at the TLS handshake (or forwarded by a TLS-terminating proxy) or a JWT-SVID as a bearer token, and Warden verifies it against the trust domain's bundle — with federation across trust domains and periodic refresh. It relies on short-lived SVIDs and bundle rotation rather than revocation lists, so it suits workloads already issued identities by a SPIFFE provider such as SPIRE.
Kubernetes	Kubernetes ServiceAccount token (projected SA JWT)	The pod's ServiceAccount token goes in the SDK's credential slot exactly as in JWT mode. Warden validates it with the issuing cluster itself — no public keys to distribute — and groups grant roles by the ServiceAccount's namespace and name.
OIDC (people)	Your company login: Microsoft Entra ID or any OpenID Connect provider	Operators sign in from the command line through their browser. The identity provider's groups decide which roles they hold, so access is managed where the rest of the company's is.

Tutorials

Once the playground has shown you the ideas, put them to work on real systems.

Governing an agent. In the same playground: register one of the tour's agents, have its team sponsor it, grant its roles by name, and then refuse the agents nobody claimed. See the tutorial.

Securing agents on the workstation — from one secret on disk to zero. A three-part, hands-on series that takes a local coding agent (Claude Code) and removes every credential from the laptop, one rung at a time, without changing how the agent works:

• Certificate → LLM — the agent's model calls flow through Warden under an mTLS client-certificate identity; the LLM API key never touches the workstation.
• Certificate → LLM + MCP — a hosted MCP server (GitHub) joins the same identity, and its token never touches the workstation.
• SPIFFE → LLM + MCP — the identity becomes a keyless, auto-rotating SPIFFE SVID, so even the private key leaves the disk. Zero long-lived credentials remain on the machine.

Every rung makes the same three wins concrete — and demonstrates them, not just asserts them: the secret leaves the workstation, and each rung turns on the audit log and watches a request get denied by policy. See the series.

Install

Warden is a single static binary — the same one is both the command-line client and the server — and a container image built from it.

docker pull ghcr.io/stephnangue/warden:latest
# or, on macOS and Linux:
curl -sL https://wardengateway.com/install.sh | bash

Windows archives and the Helm chart are published on every release too; see the install guide for those, and for the difference between a one-command dev server and a real deployment.

Architecture

See the architecture overview for Warden's design decisions, high availability model, and deployment configuration.

Kubernetes

A first-party Helm chart deploys Warden as a 3-replica HA cluster on any Kubernetes 1.27+ cluster — bring your own Postgres, your own TLS certificate, and either a Vault Transit endpoint for auto-unseal or a static seal key for development. The chart ships production-leaning defaults; a quickstart values file shrinks the install to a single replica for kind or minikube.

See the chart reference for the values it exposes, and the Kubernetes guide for the full deployment walkthrough.

Contributing

We welcome contributions! See the contributing guide for setup instructions, build commands, testing conventions, and submission guidelines.

License

MPL-2.0