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.
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.
# 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-keyThen point Claude Code, Cursor, VS Code or Codex CLI at the gateway as their MCP server. Worked examples for each are in examples/.
How it fits
Point your agent at it
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.
{
"mcpServers": {
"gateway": {
"type": "http",
"url": "http://localhost:8080/mcp",
"headers": {
"X-Gateway-Key": "gk_...",
"X-Agent-Profile-Name": "coding"
}
}
}
}{
"mcpServers": {
"gateway": {
"url": "http://localhost:8080/mcp",
"headers": {
"X-Gateway-Key": "gk_...",
"X-Agent-Profile-Name": "coding"
}
}
}
}{
"servers": {
"gateway": {
"type": "http",
"url": "http://localhost:8080/mcp",
"headers": {
"X-Gateway-Key": "gk_...",
"X-Agent-Profile-Name": "coding"
}
}
}
}[mcp_servers.gateway]
url = "http://localhost:8080/mcp"
[mcp_servers.gateway.http_headers]
X-Gateway-Key = "gk_..."
X-Agent-Profile-Name = "coding"bootstrap-key. Roles and rotation are in example 09.ANTHROPIC_BASE_URL to :8082. Example 07 covers all four providers.The problem
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
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
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
Rules about what agents may do are written down, but nothing checks them at the moment an agent acts.
Why a gateway
Models and tools are handled in the same place, so one config, one profile and one log can serve agents across your environment.
Register MCP servers as connectors and scope them per agent profile. Agents point at the gateway instead of at each server.
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.
Backend credentials live in an encrypted store and are injected per request. The agent never holds them.
Each tool call is checked against the agent's profile at execution time, not just filtered from the list.
Access logs, LLM logs and an analytics dashboard in the embedded admin console, with stdout, OpenTelemetry and ClickHouse sinks.
Self-hosted with no Tuskira account. Logs stay where you choose and can be sent to the logging tools you already use.
Read how every decision is made, run it on your own infrastructure and extend it for your stack.
Get the source, install guide and documentation on GitHub. Apache 2.0 licensed.
Tuskira AI Agent Gateway is released under the Apache 2.0 license. Product names mentioned are trademarks of their respective owners and are used only to identify compatible tools. Their use does not imply a partnership or endorsement.
We use cookies to enhance your browsing experience, serve personalized ads or content, analyze our traffic. By clicking "Accept All", you consent to our use of cookies. Cookie policy