MCP server: One MCP server.

Gateway

@authzxMCP server · External

AuthzX MCP Gateway — policy-enforcing proxy between AI agents and MCP servers

AI agent governancev1.0.1Apache-2.0TypeScript
Freeno charge per call

Runs on your machine from its package; the steps are below.

What it does

  1. Reads
  2. Writes
  3. High impact

At most: moves money, runs code or commands, deletes data, or sends messages for you.

What it costs

Free

Odel charges nothing per call. The publisher may charge for its own service.

Runs locally over stdio

This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).

npm@authzx/mcp-gatewayv1.0.1

Run

npx -y @authzx/mcp-gateway

MCP client config

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": [
        "-y",
        "@authzx/mcp-gateway"
      ]
    }
  }
}
README6 min read

Vengtoo MCP Gateway

License Node npm

Authorization gateway for AI agents and MCP tool calls.

Open-source. Drop-in. Works with any MCP client.

Why

AI agents connected to MCP servers can call any tool they have access to: read your database, delete files, execute arbitrary SQL. Vengtoo MCP Gateway puts a policy enforcement point between the agent and those tools, so every call is authorized before it executes.

What it does

  • Sits between MCP clients (Claude Code, Cursor, VS Code, GitHub Copilot) and any MCP server
  • Intercepts every tool call and checks authorization before forwarding
  • Two modes: cloud (Vengtoo Cloud API) and local (Vengtoo Agent + .rego policy file)
  • Full audit trail of every tool invocation: subject, tool name, arguments, and decision are logged as structured JSON:
json
{"ts":"2026-05-25T10:03:11.482Z","level":"info","msg":"mcp_tool_call","subject":"agent:ai-assistant","tool":"database__query","allowed":true,"latency_ms":0.8}

Quick Start

  1. Install and start the Vengtoo Agent. The agent runs locally and evaluates your authorization policy; no cloud account needed.
bash
go install github.com/vengtoo/agent/cmd/agent@latest
vengtoo-agent --policy ./policy.rego

Create a policy.rego to define what your agent can do:

rego
package vengtoo.mcp

default allow := false

# Allow read-only tools
allow if { input.resource.name == "database__query" }
allow if { input.resource.name == "database__list_tables" }

# Allow writes, but block destructive SQL
allow if {
    input.resource.name == "database__execute"
    not contains(lower(input.resource.attributes.sql), "drop")
    not contains(lower(input.resource.attributes.sql), "delete from")
}

See demo/policies/ for more examples including Kubernetes namespace protection.

  1. Create a gateway.config.json:
json
{
  "vengtoo": {
    "agentUrl": "http://127.0.0.1:8181"
  },
  "subject": "agent:ai-assistant",
  "servers": {
    "database": {
      "command": "node",
      "args": ["./my-database-mcp-server.js"]
    }
  }
}
  1. Add to your MCP client (e.g. Claude Code):
bash
claude mcp add --transport stdio vengtoo-gateway -- \
  npx vengtoo-mcp-gateway --config /path/to/gateway.config.json

Configuration

Config schema

FieldTypeRequiredDescription
vengtoo.agentUrlstring*URL of local Vengtoo Agent (local mode)
vengtoo.cloudUrlstring*URL of Vengtoo Cloud API (cloud mode)
vengtoo.apiKeystringAPI key from Vengtoo Cloud (or set VENGTOO_API_KEY env var)
vengtoo.timeoutMsnumberAuthorization request timeout (default: 5000)
subjectstringyesIdentity of the agent making tool calls
subjectTypestringSubject type (default: "agent")
resourceTypestringResource type for authorization checks (default: "mcp_tool")
serversobjectyesMap of downstream MCP servers to proxy
transportstringCaller transport: "stdio" (default) or "http", see Transport
httpobjectHTTP transport settings (used when transport is "http")

* Provide either agentUrl (local mode) or cloudUrl (cloud mode).

Each entry in servers has:

FieldTypeRequiredDescription
commandstringyesCommand to spawn the MCP server
argsstring[]Command arguments
envobjectAdditional environment variables

Modes

Cloud mode

Connect to Vengtoo Cloud for managed policies:

json
{
  "vengtoo": {
    "cloudUrl": "https://api.vengtoo.com/access/v1/evaluation",
    "apiKey": "vgt_..."
  },
  "subject": "agent:prod-assistant",
  "servers": {
    "database": {
      "command": "node",
      "args": ["./db-server.js"]
    }
  }
}

Local mode

Run the Vengtoo Agent locally with a .rego policy file for offline, self-contained authorization:

bash
# Start the agent with your policy
vengtoo-agent --policy ./policy.rego
json
{
  "vengtoo": {
    "agentUrl": "http://127.0.0.1:8181"
  },
  "subject": "agent:dev-assistant",
  "servers": {
    "database": {
      "command": "node",
      "args": ["./db-server.js"]
    }
  }
}

Transport

The gateway exposes its (policy-enforced) tools to callers over one of two transports.

stdio (default)

Runs as a local subprocess speaking MCP over stdin/stdout: the right choice for a single desktop agent (Claude Desktop, Cursor, Claude Code). No network surface.

HTTP (remote)

Runs a Streamable HTTP MCP server at a URL, so a remote agent (or many concurrent agents) can share one governed gateway. Enable it with --http (or "transport": "http" in the config):

bash
vengtoo-mcp-gateway --config gateway.config.json --http --port 8808
json
{
  "vengtoo": { "cloudUrl": "https://api.vengtoo.com/access/v1/evaluation", "apiKey": "vgt_..." },
  "subject": "agent:prod-assistant",
  "transport": "http",
  "http": {
    "port": 8808,
    "host": "0.0.0.0",
    "path": "/mcp",
    "authTokens": ["<caller-token>"],
    "allowedHosts": ["gateway.example.com"]
  },
  "servers": { "database": { "command": "node", "args": ["./db-server.js"] } }
}

HTTP config (http.*):

FieldTypeDefaultDescription
portnumber8808TCP port to listen on
hoststring127.0.0.1Interface to bind; 0.0.0.0 accepts remote connections
pathstring/mcpURL path of the MCP endpoint
callersobject[]-Per-caller identity: { "token": "...", "subject": "agent:claude" }; each bearer token authorizes as its own subject
authTokensstring[]-Anonymous bearer tokens; grant access, run as the global subject
allowedHostsstring[]-Enables DNS-rebinding protection; rejects requests with an unlisted Host
allowedOriginsstring[]-Enables DNS-rebinding protection; rejects requests with an unlisted Origin

Per-caller identity. Give each agent its own token and subject, and your policies (and audit trail) see each caller's real identity through one shared gateway:

json
"http": {
  "port": 8808,
  "callers": [
    { "token": "<claude-token>", "subject": "agent:claude" },
    { "token": "<cursor-token>", "subject": "agent:cursor" }
  ]
}

Also settable via VENGTOO_GATEWAY_HTTP_CALLERS="<token>=agent:claude,<token>=agent:cursor". Sessions are bound to the token that opened them: a different caller presenting another caller's session id gets a 401, so identities cannot cross sessions. Tokens listed in authTokens (or callers omitted entirely) run as the config's global subject.

Safety: the gateway refuses to bind a non-loopback interface with no caller auth (callers or authTokens). Either configure tokens, or set VENGTOO_GATEWAY_ALLOW_UNAUTHENTICATED=true to knowingly expose an open endpoint. An unauthenticated GET /healthz liveness probe is always served.

⚠️ Security: Vengtoo trusts whichever subject this gateway asserts. The callers token→subject mapping above (owned by this gateway's own config) is the correct pattern; it is NOT the same as trusting a client-supplied header. Never change this to derive the subject from a header/field a calling client sends; that would let any caller claim to be any subject and inherit its permissions within your tenant. If you front this gateway with another reverse proxy, make sure that proxy cannot be made to forward an arbitrary caller-chosen bearer token or subject.

CLI Flags

FlagDescription
--config <path>Path to gateway config file (default: ./gateway.config.json)
--httpServe over HTTP instead of stdio
--port <n>HTTP listen port (default: 8808; implies --http-compatible config)
--host <h>HTTP bind interface (default: 127.0.0.1)
--path <p>HTTP endpoint path (default: /mcp)
--list-toolsList all tools from configured downstream servers and exit
--generate-policy [path]Generate a starter .rego policy file for the configured tools (default: policy.rego)

Environment overrides: VENGTOO_API_KEY, VENGTOO_AGENT_URL, VENGTOO_SUBJECT, VENGTOO_GATEWAY_TRANSPORT (http), VENGTOO_GATEWAY_PORT / PORT, VENGTOO_GATEWAY_HOST, VENGTOO_GATEWAY_PATH, VENGTOO_GATEWAY_HTTP_TOKENS (comma-separated), VENGTOO_GATEWAY_ALLOW_UNAUTHENTICATED.

MCP Client Setup

The gateway runs as a stdio MCP server. Point your MCP client at it instead of the downstream server directly.

Claude Code

bash
claude mcp add --transport stdio vengtoo-gateway -- \
  npx vengtoo-mcp-gateway --config /path/to/gateway.config.json

Cursor

Add to .cursor/mcp.json:

json
{
  "mcpServers": {
    "vengtoo-gateway": {
      "command": "npx",
      "args": ["vengtoo-mcp-gateway", "--config", "/path/to/gateway.config.json"]
    }
  }
}

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

json
{
  "mcpServers": {
    "vengtoo-gateway": {
      "command": "npx",
      "args": ["vengtoo-mcp-gateway", "--config", "/path/to/gateway.config.json"]
    }
  }
}

VS Code / GitHub Copilot

Add to .vscode/mcp.json:

json
{
  "servers": {
    "vengtoo-gateway": {
      "type": "stdio",
      "command": "npx",
      "args": ["vengtoo-mcp-gateway", "--config", "/path/to/gateway.config.json"]
    }
  }
}

See demo/ for full end-to-end examples with sample policies.

Roadmap

See ROADMAP.md for what's planned: per-caller OAuth, downstream resilience, dynamic tool lists, metrics, remote downstream servers, and more.

Feedback

License

Apache-2.0, see LICENSE.

Similar modules

Browse AI agent governance