Agent traffic, governed

A reverse proxy between your agents and the servers they call.

Agents call tools, read data, and send prompts to models. This proxy sits in the middle: it checks every request against rules you wrote, keeps upstream credentials to itself, and logs every decision, allow or deny, to an append-only audit log.

Run it in a container How it works
Gateway status console: decision counters for the last 24 hours, upstream health with a paused failing server, live rate-limit usage, and tools awaiting review
The admin console at a glance: counters, upstream health, rate limits, pending reviews, and the audit feed. Take the console tour →

Why we built it

An agent will use whatever access you give it.

Hand an agent a finance tool and it reads balances and transactions. A shell tool, and it runs commands on someone's machine. A provider key, and it spends money on tokens until somebody thinks to look. Agents act right away on whatever access they have, and the access list only ever grows.

Most setups skip the middle. The agent points straight at the upstream, the upstream trusts whatever token arrives, and the record of who called what lands, at best, in a provider's log that nobody on your side controls.

This proxy sits in that middle. Every call is checked against your rules and written to the audit log before anything is forwarded, whether it is a tool call, a resource read, or a model request. Upstreams only ever see the proxy's own credentials, so a leaked agent token is useless outside your network.

How a request moves

Two kinds of access, one proxy.

Models are reached over OpenAI- and Anthropic-style APIs. Tools are reached over MCP. Both go through the same checks before anything leaves the proxy:

/llm/{slug}/v1

An LLM endpoint your agents connect to. Allowlists decide which models they may call, approved system prompts apply to every request, and token budgets cap the spend. Off by default; enable with LLM_PROXY_ENABLED=true.

/mcp/{vserver}

An MCP endpoint your agents connect to. It exposes selected tools, prompts, and resources from upstream MCP servers (HTTP or stdio) under one stable name. Agents see this endpoint, not the upstreams behind it.

Caller AI agents Claude Desktop · ChatGPT · CI · automations
go-agentic-gateway authenticate → policy → DLP → forward every step writes an audit event
LLM providers OpenAI / Anthropic APIs
MCP servers HTTP / stdio
Every decision is logged Append-only audit log hash-chained · signed checkpoints · SIEM export
Administration WebUI · gwctl CLI SSO login, role-based admin access, approvals and policies

Features

What stands between an agent and an upstream.

Approvals
New tools, prompts, and resources from an upstream land in an approval inbox. Nothing goes live until someone approves it, and the approval records a SHA-256 hash of the exact definition. With strict_hash enabled, a call is blocked when the upstream changes the definition after approval.
Access rules
Everything is denied unless a rule allows it. Deny rules win over allow rules, allow rules can require specific scopes, and rate limits and daily budgets apply to provider endpoints, models, tools, prompts, and resources.
Credentials
Upstream credentials are stored encrypted on the gateway host, never in agent configs. Each upstream authenticates with its own credential or a token exchange. Agent tokens are never forwarded upstream.
LLM controls
Approved system prompts are plain text with parameters, no template language and no code. Model pinning and tool allowlists restrict what a request can do, token budgets cap the spend, and an injection scanner can flag or block suspicious requests without modifying them.
DLP
Built-in detectors and custom regex rules redact, hash, or remove sensitive data in tool arguments and prompt inputs, in both directions. The same rules apply to what the audit log stores.
Operations
A web UI and the gwctl CLI cover day-to-day operation: syncing, approvals, policies, exports. Every screen is documented on this site in the console tour. Prometheus metrics, optional OpenTelemetry traces, and an optional split that runs administration and request handling as separate processes.
All features in detail

Audit & compliance

A log you can verify later.

Decisions are written to an append-only log where each entry includes a hash of the previous one. Signed checkpoints let you, or an auditor, verify later that no entry was changed or removed. Actors are stored as pseudonyms and payloads are stored encrypted.

GDPR data-subject requests, cryptographic erasure with four-eyes approval, a RoPA export, and evidence packs are built in. Audit payloads are encrypted at rest with AES-256-GCM, and IP addresses stay out of the access log by default.

More about the audit log

See every decision in your own audit log.

Clone the repository ↗ Get started