AgentGuard sits on the wire between your agent and its tools and checks every call against your policy before it runs. Open source, self-hosted, no agent code changes.
agentguard cloud · hosted · early access
open source · self-host it now, free
curl -fsSL https:// github.com/ Caua-ferraz/ AgentGuard/ releases/ latest/ download/ install.sh | sh
Installs agentguard, the MCP gateway and the LLM proxy after checking them against the release checksums. Then run agentguard setup.
Put the firewall on the wire — at the protocol boundary between the agent and the world. Define policy. Stream the audit. Self-hosted by default — we never see your traffic.
Point your MCP client at the gateway, or set one base-URL env var so OpenAI / Anthropic SDK traffic flows through the proxy. Every tool call is now policy-checked — including dynamic and model-generated ones.
# agentguard-llm-proxy export OPENAI_BASE_URL=http://127.0.0.1:8081/v1
Rules in YAML across seven scopes — shell, filesystem, network, browser, cost, data, MCP tools. Allow, deny, or pause for human approval; rate limits and spend caps compose on top.
scope: shell deny: "rm -rf *" · require_approval: "sudo *"
Append-only JSONL trail — agent, scope, command, reasoning — that can be sealed into a hash chain agentguard audit verify checks offline. Query it by CLI, dashboard, or Prometheus; replay any session, subagents included.
# 14:02:11.482 shell → DENY · audit #4821 · 0.53 ms
The agent issues a tool call; the checkpoint evaluates policy; the call proceeds, pauses for human approval, or is denied. One policy, one audit trail, one approval queue — whether the checkpoint runs as an MCP gateway, an LLM API proxy, or in front of your SDK.
intent agent
Policy evaluated at the protocol boundary. One decision per call. Append-only, replayable audit.
YAML policy · append-only audit · human approvals · self-hosted
real systems
Run it on the wire for zero code changes, or embed the SDK where the wire isn’t practical. Same policy engine, same audit trail, same approval queue on every path.
JSON-RPC checkpoint between any MCP client and the real MCP server, local or remote over Streamable HTTP. Every tools/call is policy-checked before it reaches the server. No agent code changes.
HTTP checkpoint in front of the OpenAI and Anthropic APIs — set one base-URL env var. Tool calls in the response stream are gated against policy, with streaming support.
agentguard hook checks each agent’s shell, file, web and MCP calls against the same policy, and can fail closed when the server is down. agentguard setup connects and disconnects each one.
The SDKs are opt-in by design — the agent calls guard.check(…). Use them when you control the agent’s source; pair them with the wire-level paths when you don’t.
We took out the things you don’t want in your security path: an outbound dependency, a vendor with your prompts, a black-box decision. AgentGuard is yours — on your wire, in your infrastructure.
Single binary or library. Runs in your VPC, your container, your laptop — one node on SQLite, or many behind PostgreSQL. There is no SaaS to call.
By default, prompts, tool args, and results never leave your network: the runtime makes no outbound calls, sends no telemetry, and runs no update check. If you opt in to the hosted dashboard, you choose what gets sent.
Every decision written to an append-only JSONL trail — agent, scope, command, reasoning — with secrets masked before they are written (since v1.2). Since v1.4 each entry is chained to the last with an HMAC, and agentguard audit verify finds any edit, deletion or reordering offline. Replay any session, subagents included, on the dashboard.
YAML with a stable v1 schema across seven scopes — shell, filesystem, network, browser, cost, data, MCP tools. Reviewable in PRs. Versioned, diff-able, deployable like any service.
The full firewall is open source — install, configure, self-host. AgentGuard Cloud is the hosted, multi-tenant version: same policy engine, same audit trail, run for you. Currently in design; the waitlist is open.
The full firewall — wire-level transports, policy engine, approvals, dashboard. Apache 2.0, source on GitHub. You write the YAML, you run the binary, you keep every byte.
Same engine, run for you. Central control plane for teams running multiple agents in production — shared policy libraries, global rate limits, and a managed audit trail if you want one.
The claims below track the open-source repo — when the code changes, this page changes.
Yes. The full runtime — policy engine, wire-level transports, approval queue, and dashboard — is Apache 2.0, source on GitHub. Self-hosted, single binary. AgentGuard Cloud is a separate hosted layer that never gates the open path.
One command. On macOS or Linux: curl -fsSL https://github.com/Caua-ferraz/AgentGuard/releases/latest/download/install.sh | sh. On Windows, in PowerShell: irm https://github.com/Caua-ferraz/AgentGuard/releases/latest/download/install.ps1 | iex. Both install the server, the MCP gateway, and the LLM API proxy after checking them against the release checksums. Then run agentguard setup: a menu that starts AgentGuard at login with a starter policy and an API key, and later updates or uninstalls it. Running the install command again also updates. There is also a multi-arch Docker image, ghcr.io/caua-ferraz/agentguard, and a go install path for Go 1.26+.
AgentGuard intercepts at the protocol boundary instead of asking the agent to opt in. The MCP gateway sits between any MCP client (Claude Desktop, Cursor, Cline, Continue, Zed) and the real MCP server, policy-checking every tools/call. The LLM API proxy sits in front of the OpenAI and Anthropic APIs — set one base-URL environment variable and tool calls in the response stream are gated before your code ever sees them.
Yes. agentguard hook claude-code, cursor, gemini-cli and codex plug into each agent's own hook system and check its shell commands, file reads and writes, web fetches and MCP tool calls against the same policy as every other path (Claude Code since v1.3; Cursor, Gemini CLI and Codex CLI since v1.4). agentguard setup connects and disconnects each agent and can add a starter rule block for it. By default a call the hook cannot check goes ahead with a warning; with --fail-closed it is denied instead. Calls from subagents are linked to the session that started them, and the dashboard replays the session with one lane per agent.
It refuses it. Gating fails closed: a response the proxy cannot decode into a tool call, a stream that ends mid-tool-call, and a tool input that arrives orphaned from its call are all denied under a stable rule string rather than forwarded unexamined. v1.1 closed five such paths in the LLM API proxy — before it, a stream that ended with a tool call still buffered produced an empty 200, and a body an SDK could execute but Go could not decode was passed through. Refusals are recorded in the audit trail with the DENY the client received, and they are deliberately not subject to --fail-mode allow: that flag governs an unreachable guard, not a healthy guard that cannot see what the client will execute.
No. AgentGuard is self-hosted and makes no outbound calls by default. Prompts, tool arguments, and results stay in your network unless you configure notifications (Slack, webhooks) or opt in to AgentGuard Cloud.
0.53 ms p99, measured end-to-end on the full HTTP check path with persistence enabled (the v1.0 verification). A CI gate fails the build of every release if p99 crosses the 3 ms budget; v1.2's command-by-command shell checks left the simple-command path at v1.1's speed.
Yes, since v1.0, and hardened in v1.1. The zero-config default is single-node SQLite; point --store-dsn at PostgreSQL and give each replica a --node-id to share approval, rate-limit, and cost state across nodes. Reconciliation runs in the background — no synchronous database call is added to the /v1/check hot path, so the sub-3 ms p99 budget is preserved. v1.1 added an advisory lock so replicas no longer race each other through schema migration at boot, and a shared row-lock order that removed cross-node flush deadlocks: a three-node cluster served 5.1M requests across three runs with zero errors and zero deadlocks, where the pre-fix build of the same shape produced 393. Distributed rate limiting is bounded-overshoot by design, and conflicting approval resolutions always converge to DENY.
Tamper-evident, since v1.4. AgentGuard writes an append-only JSON-Lines audit trail of every decision — agent, scope, command, reasoning — and with --audit-seal it chains every entry to the one before it with an HMAC-SHA256. agentguard audit verify checks the log offline, archives included, and names the first edited, deleted or reordered line by file and line. New installs made with agentguard setup are sealed; an existing server stays unsealed until you turn it on. A chain cannot show that its newest entries were cut off, so AgentGuard publishes the chain head every few minutes: forward those anchors, or the trail itself, to append-only/WORM storage such as S3 Object Lock, a SIEM, or syslog.
No. AgentGuard is a policy-enforcement and audit layer, not an OS sandbox — it does not intercept syscalls. Combine it with OS-level isolation (containers, seccomp, egress rules) when your threat model includes a hostile agent that controls its own runtime. As of v1.1 this is written down rather than implied: docs/THREAT_MODEL.md states the actors in decreasing order of trust, the trust boundaries between them, the fail-open versus fail-closed matrix, and the explicit non-goals.
Built in public. Shipped against a thesis, not a press release.
policy precedes action · lex antecedit actum
Want AgentGuard run for you? Join the AgentGuard Cloud waitlist — design partners go first. The open-source core stays free, forever.