Open sourceSelf-hostedNo Tuskira account

Tuskira Open Sources AI Agent Gateway

One self-hosted gateway connects your AI agents to the LLMs and MCP tools they use, with access control, visibility and cost tracking built in.

Quickstart
# clone, then bring up all three planesgit clone https://github.com/Tuskira/tusk-ai-secured-gateway.gitcd tusk-ai-secured-gatewaydocker compose -f deploy/docker-compose.yml up --build -d # health checkscurl localhost:8080/health          # MCP planecurl localhost:8081/api/v1/health   # control plane + consolecurl localhost:8082/health          # LLM plane # create your first admin keydocker compose -f deploy/docker-compose.yml exec gateway /gateway bootstrap-key

Then point Claude Code, Cursor, VS Code or Codex CLI at the gateway as their MCP server. Worked examples for each are in examples/.

v0.2.0pre-1.0, tagged releases on GHCR
Apache 2.0license, NOTICE and SECURITY policy in the repo
One Go binarythree planes: MCP :8080, control + console :8081, LLM :8082
12 runnable examplesClaude Code, Cursor, VS Code, Codex CLI, Python, Kubernetes

How it fits

One gateway between your agents and what they call

TUSKIRAopen source · runs in your environment DevelopersDriving agents interactively AutomationPipelines, schedulers, background jobs AI agents>_Claude Code▶Cursor</>Codex✸Custom agents◉Sub-agentsAgent-to-agent calls AI Agent GatewaySits in the path. Checks eachsupported action against yourpolicy before it runs. auth · profile · credentials · log MCP serversGitHubSlackJiraSnowflakeSalesforceAny MCP servertools/call LLM providersAnthropicOpenAIGeminiBedrockAzureSelf-hosted/v1/messages Self-hosted inside your boundary · no Tuskira account or connection required · product names shown are example destinations, not partnerships

Point your agent at it

One config change per agent

Register the gateway as the agent's MCP server. Tools, credentials and policy come from the gateway from then on. Each snippet has a worked, self-checking example in the repo.

.mcp.json in your projectJSON
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:8080/mcp",
      "headers": {
        "X-Gateway-Key": "gk_...",
        "X-Agent-Profile-Name": "coding"
      }
    }
  }
}
.cursor/mcp.jsonJSON
{
  "mcpServers": {
    "gateway": {
      "url": "http://localhost:8080/mcp",
      "headers": {
        "X-Gateway-Key": "gk_...",
        "X-Agent-Profile-Name": "coding"
      }
    }
  }
}
.vscode/mcp.jsonJSON
{
  "servers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:8080/mcp",
      "headers": {
        "X-Gateway-Key": "gk_...",
        "X-Agent-Profile-Name": "coding"
      }
    }
  }
}
~/.codex/config.tomlTOML
[mcp_servers.gateway]
url = "http://localhost:8080/mcp"

[mcp_servers.gateway.http_headers]
X-Gateway-Key = "gk_..."
X-Agent-Profile-Name = "coding"
  • X-Gateway-Key is the key you created with bootstrap-key. Roles and rotation are in example 09.
  • X-Agent-Profile-Name picks the allow-list this agent gets. Same connector, different tools per profile, in example 05.
  • Sending LLM calls through the gateway too? Set ANTHROPIC_BASE_URL to :8082. Example 07 covers all four providers.
  • All 12 examples

The problem

Every agent is wired up on its own

A team might run Claude Code in the terminal, Cursor in the editor and a few custom agents in CI. Each one has its own model keys, its own list of MCP servers and its own rules about what it may do.

Config sprawl

Keys and tool lists everywhere

API keys and MCP server settings are copied into every agent on every laptop and runner. Changing a model means touching each one.

No shared view

No shared view across agents

There is no single record of which models and tools agents called, what they tried to do or how many tokens they used.

No enforcement

Policy lives in a wiki

Rules about what agents may do are written down, but nothing checks them at the moment an agent acts.

gatewayspec
sits
In the path, between agents and models or tools
agents
Claude Code, Cursor, VS Code and Codex CLI over MCP; custom agents on the Python MCP and Anthropic SDKs; pipelines and background jobs
connects_to
Anthropic, OpenAI, Gemini and AWS Bedrock with your own keys, and any MCP server
runs
In your environment. No Tuskira account or connection required

Why a gateway

Put one control point in the path, and run it yourself

Models and tools are handled in the same place, so one config, one profile and one log can serve agents across your environment.

Configure once

Register MCP servers as connectors and scope them per agent profile. Agents point at the gateway instead of at each server.

One endpoint for supported providers

Provider-native routes on :8082, with your own keys. /v1/messages for Anthropic, /openai/… and /gemini/… for the rest, /model/… for Bedrock. Change the base URL in your SDK, nothing else. Token usage and estimated cost are captured per call.

Keep credentials out of agents

Backend credentials live in an encrypted store and are injected per request. The agent never holds them.

Enforce access on every call

Each tool call is checked against the agent's profile at execution time, not just filtered from the list.

AllowedDeniedLogged

See every call through the gateway

Access logs, LLM logs and an analytics dashboard in the embedded admin console, with stdout, OpenTelemetry and ClickHouse sinks.

Stay inside your boundary

Self-hosted with no Tuskira account. Logs stay where you choose and can be sent to the logging tools you already use.

Open source, so you can check it and change it

Read how every decision is made, run it on your own infrastructure and extend it for your stack.

  • Apache 2.0 license
  • Install and deployment guides
  • Example configs and profiles
  • Contribution guidelines
Star on GitHub

Run it in your environment

Get the source, install guide and documentation on GitHub. Apache 2.0 licensed.