AI agents that call MCP tool servers and model APIs no longer need to store model keys and MCP tokens in their own configuration files, thanks to an open-source gateway that brokers the credentials at the moment of the call and runs inside a team’s own environment.
Why credentials end up in agent config files
Teams that run coding agents like Claude Code and Cursor, alongside a homegrown ticket bot, commonly paste model keys and MCP credentials into each agent’s configuration, then copy that configuration across laptops and CI runners. Any file that holds those secrets is a credential, and the agent itself does not check its own permissions when it acts on behalf of the user.
How the gateway sits between agents and the services they call
The gateway registers as the agent’s MCP server. On every request the agent sends a gateway key and a profile name. The gateway validates the key, which is tied to a tenant and a role, then checks whether the named profile is allowed to use the requested tool. A denied call returns an error and is logged without reaching the backend. An allowed call has the real credential pulled from an encrypted store and attached on the way out, so the GitHub token, for example, never lives in the agent’s config file at all.
That permission check runs at the moment of the call, on top of the trimmed tool list each agent sees. The practical effect is that an agent that has been talked into calling a tool it was never shown is still refused at the gateway.
Model traffic can travel through the same gateway by changing an SDK’s base URL. The gateway covers Anthropic, either directly or through AWS Bedrock, plus OpenAI and Gemini, and it records tokens and an estimated cost for each call.
Two defaults worth changing before production use
Profiles only bind when an operator binds them. A gateway key with no profile attached lets the caller name its own profile in a request header, which means a leaked unbound key can ask for any profile it wants. Binding each key to its profile narrows what a leaked CI key can reach, and the project’s sample CI profile allows exactly one tool.
The demo stack also stores LLM request and response bodies, capped at 1 MiB each, so the console can replay them. Those bodies hold whatever prompts and code the agents send, and a single setting turns the storage off.
The shipped Docker Compose file allows outbound connections to the host machine and the loopback range so local testing works. The project instructs operators to remove both on anything shared. Outside those exceptions the gateway refuses connections to private and loopback addresses by default and always blocks the cloud metadata address.
What it runs on and what’s in the repository
The gateway runs on macOS and Linux, and Windows through WSL2 is untested. The repository ships worked examples for Claude Code, Cursor, VS Code, Codex CLI, a Python agent, and Kubernetes. The full project is available for free on GitHub.
FAQ
What is Tuskira’s AI Agent Gateway?
It is an open-source tool that sits between AI agents and the MCP tool servers and model providers they call. It brokers credentials at the moment of the call so model keys and MCP tokens never have to live in agent config files, and it runs in the team’s own environment without a vendor account.
Which model providers and coding tools does the gateway support?
The gateway covers Anthropic, either directly or through AWS Bedrock, plus OpenAI and Gemini. The repository ships worked configuration examples for Claude Code, Cursor, VS Code, Codex CLI, a Python agent, and Kubernetes.
What should an operator change before using the gateway in production?
Bind every gateway key to a specific profile so a leaked key cannot ask for any profile it wants, turn off LLM request and response body storage if the prompts and code should not be retained, and remove the Docker Compose file’s outbound rules for the host machine and loopback range on any shared deployment.
This article summarizes reporting from helpnetsecurity.com.