Casbin Gateway, a local proxy that watches your AI coding agents

One endpoint in front of 44 model vendors

The problem Casbin Gateway addresses is that nobody knows what the AI coding agents on their machine are actually doing. Every tool talks to its own vendor endpoint with its own credentials, and the result is that the request, the token usage and the prompt content are invisible unless you read each tool's own logs separately.

The project's own framing is that you can see what every AI coding agent on your machine is doing, and whether the API behind it is the one you paid for. The mechanism is a proxy. The agents are pointed at the gateway, the gateway talks to the vendors, and in between it records what happened. The description names a single endpoint for 44 model vendors, A through F API authenticity grading, per-agent permissions, and usage and prompt records.

The agent list in the documentation is long and specific: Claude Code, Claude Desktop, Codex and Codex CLI, Gemini CLI, Cursor and Cursor Agent, Windsurf, Cline, Qwen Code, iFlow CLI, Kimi Code CLI, CodeBuddy Code, Grok Build, Roo Code, Copilot CLI, Continue, Zed, Aider, goose, Crush and Droid, and the list is cut off in the documentation as it stands.

That breadth is the product. Nobody runs one agent. A developer switching between a terminal agent and an editor agent on the same afternoon has two separate API relationships, and the gateway collapses them into one observable place.

The audience is a developer or a small team that has already adopted these tools and is now asking where the tokens are going and what the agents are being told.

A Go service with a Casbin core and a large internal package map

The repository is a Go module named github.com/apache/casbin-gateway, requiring Go 1.25.0 with a go1.25.8 toolchain. The dependency list makes the design intent plain: casbin/v2 is there for the access control, casdoor-go-sdk for identity, beego for the web layer, xorm with the MySQL, PostgreSQL, MSSQL and SQLite drivers for storage, and BurntSushi/toml with yaml.v3 for configuration.

Casbin in the dependency list is the reason for the project's name and the mechanism behind per-agent permissions. Policy is expressed as rules and enforced by the enforcer, which is a very different model from hardcoding an allowlist in Go code. For a tool whose whole job is deciding which agent may call which endpoint with which credentials, an externalisable policy engine is the right call, and it also means an organisation can express rules the way it already expresses them elsewhere.

The directory listing is the map of the feature set, and it is unusually revealing. There are `agent/` and `agentauth/`, `agentconfig/`, `agentegress/`, `agentenv/`, `agenthistory/`, `agenthook/`, `agentinstall/`, `agentlink/`, `agentmonitor/`, `agentpatch/`, `agentprocess/`, `agentprovider/`, `agentsession/`, and `agentusage/`. So agents can be authenticated, configured, monitored, patched, hooked, linked, and their usage tracked, with sessions, history, environment handling, egress control, installation and provider abstraction each in its own package.

Beyond that there is `proxy/` and `protocol/` for the request path, `mcpproxy/` and `mcpserver/` for the Model Context Protocol, `auth/`, `auditutil/`, `ccswitch/`, `cloudsync/`, `connector/`, `controllers/`, `routers/`, `i18n/`, `imbridge/`, `embedsupport/`, `localserver/`, `desktop/`, `object/`, `service/`, `cmd/` and `conf/`.

The scale of that package list is the honest characterisation of this project. It is not a small shim. It is a service with a policy engine, a data layer, an audit trail and a desktop component.

Running it as a container with one mounted config and one volume

The deployment path documented by the repository is Docker Compose, and the compose file is short enough to read in full.

version: '3.1'
services:
  casbin-gateway:
    restart: always
    build:
      context: ./
      dockerfile: Dockerfile
    ports:
      - "17000:17000"
    environment:
      RUNNING_IN_DOCKER: "true"
    volumes:
      - ./conf:/conf/
      # Holds the SQLite database, so the data survives "docker compose down".
      - casbin-gateway-data:/data

volumes:
  casbin-gateway-data:

Three things in that file matter. The service listens on port 17000, which is the address your agents will point at. The configuration directory `./conf` is bind-mounted to `/conf/`, so you edit rules and settings on the host and restart. And the named volume `casbin-gateway-data` holds the SQLite database, and the inline comment states the reason plainly, that the data survives `docker compose down`.

The Dockerfile shows a three-stage build, and the structure explains how a Go project with a web frontend gets shipped.

FROM golang:1.25.8 AS BACK
WORKDIR /go/src/casbin-gateway
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o server .

FROM alpine:latest AS STANDARD
LABEL MAINTAINER="https://caswaf.org/"

COPY --from=BACK /go/src/casbin-gateway/ ./
RUN mkdir -p web/build && apk add --no-cache bash coreutils tzdata
COPY --from=FRONT /web/build /web/build
# Holds the SQLite database at /data/casbin-gateway.db.
VOLUME /data
ENTRYPOINT ["./server"]

The front stage builds the web assets with yarn on a Node 20 image, the back stage compiles a static Linux binary with CGO disabled, and the final Alpine image copies the binary and the built web assets together and adds bash, coreutils and tzdata. The volume declaration matches the compose file, and the entrypoint is the server binary itself.

For a Go developer, the interesting detail is `CGO_ENABLED=0`. The binary is fully static, which is what makes the Alpine image work cleanly and lets the same artefact run on any Linux host.

What the gateway records about each agent

The documentation names the record types directly: usage records, prompt records, and per-agent permissions. The package names in the tree give the shape of the implementation.

`agentusage/` is where token accounting lives, and `agenthistory/` is the history store, backed by the SQL layer the go.mod declares, xorm with drivers for SQLite, MySQL, PostgreSQL and MSSQL, and modernc.org/sqlite for the embedded default. `agentsession/` tracks sessions, `agentprovider/` abstracts the model vendors, and `agentmonitor/` and `agentlink/` cover live monitoring and the connection between an agent and its configured provider.

`agentegress/` is the one worth pausing on. Egress control in this context means deciding where traffic is allowed to go, which for a gateway in front of AI agents is the difference between an agent that can only reach the endpoints you approve and one that can reach anything. Paired with `agentauth/` and the Casbin enforcer, it is the mechanism behind the per-agent permissions claim.

`agentenv/` suggests that agent-specific environment is managed centrally, and `agentconfig/` that configuration is per agent rather than global. `agentpatch/` and `agenthook/` are more unusual. Patching and hooking an agent means altering its behaviour, presumably to redirect it to the gateway or to adjust how it presents itself. `agentinstall/` and `agentprocess/` cover putting an agent on the machine and keeping track of it as a process.

`auditutil/` is the audit trail, and `auth/` plus the casdoor-go-sdk dependency point at a Casdoor-based identity layer. `ccswitch/` is probably a client switcher, `cloudsync/` a synchronisation path for configuration, and `connector/` a pluggable interface to external systems.

The honest caveat is that the documentation excerpt available here is truncated, so the exact schema of a usage record or a prompt record is not stated. The categories are named; the field lists are not.

API authenticity grading, and what a letter grade can prove

The most distinctive claim in the project is the A through F API authenticity grading, tied to the question of whether the API behind the agent is the one you paid for.

The scenario is concrete. An agent is configured with a base URL and a key, and something in the path, a local agent, a proxy configuration, a misconfigured environment variable, means the request is answered by a different endpoint than the one intended. The subscription you pay for is not the one serving the tokens, and the symptom is subtle, because the agent still works and the response still looks right.

Grading the authenticity of the responding API is a direct answer to that. A to F is a coarse scale by design, and the grading presumably compares the responding endpoint against the expected provider, the model identity in the response, and the credentials in play. What it can establish is that the thing answering looks like the thing you expected. What it cannot establish is anything about the honesty of an endpoint that is deliberately impersonating the real one.

This is the feature to be careful with. A grade is evidence for a specific check, and the documentation excerpt does not describe the checks in detail, so the grading criteria have to be read in the source or on the project site before a letter is treated as a finding.

The related infrastructure is clearer. The MCP support appears twice in the tree, as `mcpproxy/` and `mcpserver/`, and the topics list includes mcp. Model Context Protocol traffic is exactly the kind of traffic that is worth seeing, since MCP servers are invoked by agents and can reach further into your system than a chat completion does.

Apache governance, a disclaimer and a nightly-only release

The repository sits under the Apache Software Foundation, with an `.asf.yaml` file at the top level, and the licence is Apache-2.0 with a LICENSE file and a NOTICE file alongside it. A DISCLAIMER file is also present, which is worth reading for a tool that sits in the path between your agents and your model subscriptions.

The governance markers matter for a project in this position. The project is under the Apache namespace, the repository carries the ASF metadata file, and it lists a Discord community, a LINUX DO community link and a Go reference badge on pkg.go.dev. It also has CLAUDE.md and .claude/ directories, which is a fun detail for a project about supervising AI agents: the agent instructions are checked in.

The release situation is the weak point, and it is the first thing to check. The only recorded release is a nightly build, explicitly labelled as not an official release, dated 2026-10-11, the same day as the last push. So there is no tagged stable version to pin to in the recorded history, and a team that wants reproducible builds is working from a moving branch or from a Go module pseudo-version.

The last push to the repository was on 2026-10-11, so the code has been touched recently, but with a nightly-only release line the practical upgrade story is: pull the latest commit, rebuild the container, and re-point your agents.

There is also a desktop/ directory and a desktop_test.go at the repository root, which suggests a desktop client ships alongside the server. The `localserver/` package points the same way, at a mode where the gateway runs locally on the developer's own machine rather than as a shared service.

Editorial conclusion

Casbin Gateway suits a developer or team running several AI coding agents on one machine who wants a single place to see what each agent sent, what it cost, and which upstream actually answered. It does not suit a project that needs model routing, failover or cost optimisation as its primary goal, since the documentation positions it as an observation and permission layer in front of the vendors you already use. Verify first that the agents you run can be pointed at a local endpoint, that the upstream credentials the agents already hold are the ones the gateway expects, and that the API authenticity grading is graded against a baseline you trust before you treat its letter grade as evidence.

Frequently asked questions

Official sources

1. apache/casbin-gateway on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases