Secure AI Agent Credentials: 13-Step MCP Setup [2026]

An open-source tool called AI Agent Gateway appeared on GitHub on October 1, 2026, built by security firm Tuskira, and it tackles a problem that has quietly become one of the messier parts of running AI coding agents in production: where do the credentials live? Every time Claude Code, Cursor, or a homegrown agent calls out to GitHub, Jira, or a database through a Model Context Protocol (MCP) server, something has to hold the API key or OAuth token that makes that call work. Most teams paste that secret straight into an agent’s config file or a developer’s local environment, and it sits there, readable by anything that can open the file. Tuskira’s gateway sits between the agent and everything it touches, pulls the real credential from an encrypted store only at the moment a call is approved, and never lets the agent itself see the underlying token.

This tutorial walks through a full deployment of that gateway, from a bare Docker host to a working setup that fronts a real MCP server and an LLM provider, with scoped agent profiles that limit exactly what each agent can touch. Every command, port number, and environment variable below comes from the project’s own documentation as published in its GitHub repository at github.com/Tuskira/tusk-ai-secured-gateway, current as of October 7, 2026. The project ships under the Apache 2.0 license and is explicitly labeled pre-1.0 alpha, so treat the exact flag names as subject to change and always check the README before copying commands into a production pipeline.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

Why AI Agent Credential Leaks Became 2026’s Quiet Security Problem

Credential sprawl around AI agents did not arrive with a single breach that made headlines. It built up gradually, one MCP server connection at a time, as teams wired agents into GitHub, Jira, Slack, and internal databases faster than anyone wrote a policy for how those connections should authenticate. The Model Context Protocol itself does not solve this by design. In a policy analysis of the NSA’s MCP security guidance, the agency is quoted making the gap explicit: “Associating a session to an identity is not defined by the protocol… Many implementations omit authentication entirely, and those that do include it often lack any role-based enforcement,” according to a policy response covering the NSA’s guidance. That is not a theoretical gap. It means two different MCP servers can handle the exact same request in two different, equally valid, and equally insecure ways.

Amazon Web Services published its own guidance on securing agent access patterns to AWS resources through MCP, and the framing is blunt about what that means operationally. “You must assume an agent can do anything within its granted entitlements, whether OAuth scopes, API keys, or AWS Identity and Access Management (IAM) permissions, and design your controls accordingly,” AWS wrote in its security blog, available at aws.amazon.com/blogs/security. The company also recommends that teams “create agent-specific IAM roles with narrower permissions than equivalent human roles, and direct developers to use them,” a direct rejection of the common shortcut where an agent inherits whatever broad role a developer already has on their laptop.

Regulators and standards bodies have started moving too. NIST published a quick-start guide for applying AI to the Cybersecurity Framework 2.0 in August 2026, aimed at giving security teams practical, actionable ways to use AI across analysis, planning, implementation, and monitoring, according to the draft published at csrc.nist.gov. Google Cloud’s M-Trends 2026 Executive Edition report separately recommends hardening high-impact administrative pathways with privileged identity management and conditional access, so that administrative privileges stay time-bound and observed rather than standing indefinitely, per the report at cloud.google.com. None of that guidance is AI-agent-specific, but it describes exactly the kind of control an AI agent gateway is built to enforce at the MCP layer instead of at the IAM console.

What Is an AI Agent Gateway, and How Does It Work

An AI agent gateway is a proxy that sits between your agents and everything those agents are allowed to call: MCP tool servers, LLM providers, and whatever APIs sit behind them. Instead of an agent holding a GitHub personal access token or an Anthropic API key directly in its own configuration, the agent holds a single gateway key and a profile name. Every outbound request passes through the gateway first, where it is checked against that profile’s permissions before the gateway decides whether to forward it, and if so, with which real credential attached.

The Credential Injection Flow, Step by Step

Tuskira’s documentation describes the mechanism in concrete terms: an agent registers the gateway as its MCP server and sends a gateway key and a profile name with every request. The gateway verifies the key, checks which tenant and role it belongs to, and confirms whether that profile is permitted to invoke the specific tool being requested. If the call is allowed, the gateway retrieves the real credential from its encrypted store and attaches it to the outbound call on the way out. The agent itself never receives or holds the GitHub token, the Jira API key, or whatever secret the destination service actually requires. A separate, independently developed open-source project called Agentgateway, which was donated to the Linux Foundation in 2025 and accepted as an Agentic AI Foundation project in 2026, describes the same general pattern in its own documentation: “Any calls to MCP servers or APIs have their credentials injected transparently by the infrastructure,” and “the cornerstone of this injection is exchanging an agent or user’s identity for the correct secrets/API keys/tokens,” according to agentgateway.dev’s blog. The two projects are not the same codebase, but the convergence on identity-for-secret exchange as the core mechanism tells you this is becoming the accepted pattern rather than one vendor’s idea.

Why This Beats Pasting Keys Into Config Files

The practical upside shows up the first time an agent’s configuration file, laptop, or CI runner gets compromised. Without a gateway, whatever credentials that agent was configured with are exposed in plaintext, full stop. With a gateway in front of it, the compromised agent only ever held a scoped gateway key tied to a specific profile. Revoking that one key through the gateway’s admin console cuts off exactly that agent’s access without touching any other agent’s credentials, and without rotating the underlying GitHub token, Jira key, or LLM API key that every other agent might also depend on.

Real-World Use Cases for Credential Isolation in AI Agents

Tuskira’s own launch material points to the kind of mixed environment this is built for: teams running Claude Code, Cursor, and a homegrown internal ticket bot side by side, each needing different levels of access to different services. A coding agent inside Claude Code might need read-write access to a specific GitHub repository but should never touch the company’s Jira admin API. A ticket-triage bot needs read access to Jira issues but has no business calling GitHub at all. Under the old model, each of those agents either gets its own separately managed credential set, which multiplies the number of secrets someone has to rotate and audit, or they share one overly broad token because that is easier to set up, which is worse.

A gateway collapses that into one place: a single admin console where you create a profile per use case, scope that profile to exactly the tools it needs, and hand each agent only a gateway key tied to its own profile. Changing what the GitHub-connected coding agent can do means editing one profile, not hunting down every place that agent’s old token might be cached. This is also where the gateway’s audit trail becomes genuinely useful rather than decorative: every tool call an agent makes passes through one choke point, so a security team investigating unusual activity has one log to check instead of the scattered application logs of a dozen separately configured MCP servers.

Prerequisites: Software, Versions, and Accounts You Need

Confirm every item in the table below before you start. The gateway’s Docker Compose path is the fastest route to a working deployment, but if you intend to build from source, the Go and Node versions matter: the gateway will not compile against older toolchains.

Requirement	Version / Spec	Notes
AI Agent Gateway	Pre-1.0 alpha, main branch (as of Oct. 7, 2026)	Pin a specific commit or tag rather than tracking main in production
Docker	Any version with the Compose plugin	The docker compose subcommand, not the standalone docker-compose binary
Go (source builds only)	1.27	Required only if you build the gateway binary yourself instead of using the published Docker images
Node.js (source builds only)	26	Needed to build the admin console UI from source
GNU Make	Any current version	Drives the make build and make run targets
PostgreSQL	Required backend	Stores tenants, users, roles, profiles, and encrypted credentials
Redis or Valkey	Optional	Used for session storage, not required for a basic deployment
ClickHouse	Optional	Only needed if you enable the analytics sink on port 8090
Free local ports	8080, 8081, 8082, and optionally 8090	MCP traffic, the API/console, LLM proxy traffic, and analytics respectively
At least one LLM provider key	Anthropic, OpenAI, Google Gemini, or AWS Bedrock	You only need credentials for the provider(s) you plan to proxy
Claude Code or Cursor	Current release	Used in Step 10 to test the end-to-end flow

Set aside roughly 90 minutes for the full walkthrough, including time to connect a real MCP server and run the end-to-end credential injection test in Step 11. If you already run MCP servers directly, our MCP server setup guide is worth reviewing first, since this tutorial assumes you already have at least one MCP-compatible server you want to put behind the gateway rather than building one from scratch.

Step 1: Audit Where Your Agents Currently Store Credentials

Before touching the gateway, spend thirty minutes finding every place a credential currently lives for the agents you plan to migrate. Check each agent’s configuration file, any .env file in its working directory, shell history on developer laptops, and CI pipeline secrets. This step matters more than it looks: migrating to a gateway while leaving the old plaintext key sitting in a forgotten config file defeats the entire point, since that leaked key still works until it is manually revoked at the source service.

grep -rl "GITHUB_TOKEN\|JIRA_API_KEY\|ANTHROPIC_API_KEY\|OPENAI_API_KEY" ~/.config ~/projects --include="*.env" --include="*.json" --include="*.yaml" 2>/dev/null

Write down every match before you move on. You will revoke each of these at the source (GitHub, Jira, your LLM provider’s console) only after the gateway is live and the corresponding agent profile is working, not before, so you do not break a production agent mid-migration.

Step 2: Provision the Host and Install Docker

Any Linux host with Docker and the Compose plugin works, including a local development machine for testing. For anything beyond a quick test, use a dedicated VM or container host with at least 2 vCPUs and 4GB of RAM, since the gateway, PostgreSQL, and the admin console UI all run as separate containers.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker compose version

Confirm the Compose plugin responds before continuing. If docker compose version returns a “command not found” error, your distribution likely only has the older, unsupported standalone binary installed, in which case reinstall Docker using the official script above rather than your distribution’s package manager.

Step 3: Clone and Configure the AI Agent Gateway

Clone the repository and take a look at the deployment directory before changing anything. The project’s Docker Compose file lives under deploy/, alongside the templates you will use to set environment variables.

git clone https://github.com/Tuskira/tusk-ai-secured-gateway.git
cd tusk-ai-secured-gateway
cp deploy/.env.example deploy/.env 2>/dev/null || touch deploy/.env

Open deploy/.env and set, at minimum, a PostgreSQL connection string and the egress controls that limit which hosts the gateway is allowed to reach on your agents’ behalf. Every configuration key uses the GATEWAY_ prefix:

GATEWAY_EGRESS_ALLOWED_HOSTS=api.github.com,your-company.atlassian.net,api.anthropic.com
GATEWAY_EGRESS_ALLOWED_CIDRS=
GATEWAY_LLM_PROXY_CAPTURE_STORE_BODIES=false
GATEWAY_CAPTURE_STORE_BODIES=false
GATEWAY_SINKS_CLICKHOUSE_ENABLED=false

Leaving GATEWAY_EGRESS_ALLOWED_HOSTS empty effectively tells the gateway to allow outbound calls to anywhere, which turns your credential-isolation layer into an open proxy that happens to also hold your secrets. List only the exact hosts your agents legitimately need to reach.

Step 4: Launch the Gateway With Docker Compose

With the environment file in place, bring up the stack. The project’s recommended path builds the gateway image locally rather than pulling a pre-built one, which matters given the alpha status of the code.

docker compose -f deploy/docker-compose.yml up --build -d
docker compose -f deploy/docker-compose.yml ps

You should see containers for the gateway itself and PostgreSQL reporting a healthy or running state. A representative compose configuration for this stack, assuming you are not using the bundled file verbatim and want to see each service explicitly, looks like this:

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: gateway
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: gateway
    volumes:
      - gateway-db:/var/lib/postgresql/data

  gateway:
    build: .
    depends_on:
      - postgres
    ports:
      - "8080:8080"   # MCP
      - "8081:8081"   # API / console
      - "8082:8082"   # LLM proxy
    env_file:
      - deploy/.env
    environment:
      GATEWAY_DATABASE_URL: postgres://gateway:${PG_PASSWORD}@postgres:5432/gateway

volumes:
  gateway-db:

Tail the logs if any container exits immediately. A gateway container that restarts in a loop in the first minute is almost always waiting on a PostgreSQL connection that is not ready yet or a required environment variable that was left blank.

Step 5: Bootstrap Your Admin API Key

With the gateway running, generate the first administrative key. This is the credential that lets you manage tenants, users, and profiles through the admin console, so treat it with the same care you would a root database password.

docker compose -f deploy/docker-compose.yml exec gateway /gateway bootstrap-key

Expect output similar to this, with a key you should copy immediately into a password manager, since most bootstrap flows will not display it a second time:

Bootstrap key generated successfully.
Key: gw_admin_7f2a9c3e1b8d4f6a0e5c2b9d7a1f4e8c
Store this key securely. It will not be shown again.

Step 6: Create Tenants, Users, and Roles

Multi-tenant support means you can run one gateway for multiple teams or environments, each with its own isolated set of profiles and credentials. For a first deployment, create a single default tenant and an admin user tied to it.

docker compose -f deploy/docker-compose.yml exec gateway /gateway create-user \
  -tenant default -username admin -role admin

Log into the admin console at http://localhost:8081 with the generated credentials to confirm access before moving on. If your browser cannot reach that address, check that port 8081 is not already bound by another service on the host, which is one of the more common first-run failures.

Step 7: Connect an LLM Provider

The gateway proxies calls to Anthropic Claude, AWS Bedrock, OpenAI, and Google Gemini. Rather than giving every agent its own copy of your Anthropic API key, add that key once in the admin console under LLM Providers, and agents will reach it through the gateway’s LLM proxy port, 8082, using their gateway key instead of the real provider credential.

In the console, navigate to the LLM Providers section, select Anthropic (or your provider of choice), and paste your real API key into the field provided. That key is stored encrypted at rest and never returned to any agent directly. Agents authenticate to the gateway’s LLM proxy endpoint with their own gateway key, and the gateway swaps in the real provider key behind the scenes on every call.

Step 8: Register an MCP Server Behind the Gateway

This is the step that actually puts the gateway to work. In the admin console, add an MCP server connector pointing at the real MCP server your agents already use, for example a GitHub MCP server. Provide the real GitHub credential once, here, in the gateway’s encrypted store, rather than in any agent’s own configuration.

The gateway supports any MCP-compatible tool server through its connector framework, so the same pattern applies whether you are fronting a GitHub MCP server, a Jira connector, or an internal tool built against the MCP spec. Once registered, the gateway exposes that server to agents through its own MCP endpoint on port 8080, with the real downstream credential injected per request rather than exposed to the calling agent.

Step 9: Build Scoped Agent Profiles

A profile is where you define exactly what a given agent is allowed to do. Create one profile per use case rather than one broad profile shared across every agent, since a shared profile with wide permissions reintroduces the exact problem a gateway is meant to solve. In the console, create a profile named something like github-readonly-coding-agent, and scope it to only the specific GitHub MCP tools that agent legitimately needs, such as reading file contents and listing pull requests, while explicitly excluding write or delete operations.

Create a second, separate profile for any agent that needs write access, such as one allowed to open pull requests but not merge them. The discipline of one narrow profile per real-world use case is the single biggest factor in whether a gateway deployment actually reduces risk or just adds a layer of indirection around the same broad access everyone had before.

Step 10: Point Claude Code or Cursor at the Gateway

With a profile created, generate a gateway key scoped to that profile from the admin console, then register the gateway as an MCP server inside your agent’s configuration, exactly as you would register any other MCP server, except the endpoint now points at the gateway instead of the original service.

{
  "mcpServers": {
    "github-via-gateway": {
      "url": "http://localhost:8080/mcp",
      "headers": {
        "X-Gateway-Key": "gw_profile_a93f7c1e8b2d",
        "X-Gateway-Profile": "github-readonly-coding-agent"
      }
    }
  }
}

Both Claude Code and Cursor read MCP server definitions from their own configuration files, so drop this block into whichever one you are using in place of the direct GitHub MCP server entry you had before. Restart the agent to pick up the new configuration.

Step 11: Test Credential Injection End to End

Ask your agent to perform an action that exercises the new connection, such as listing open pull requests on a repository the github-readonly-coding-agent profile is scoped to access. If everything is wired correctly, the agent completes the request successfully without ever having been given the real GitHub token.

Confirm this by checking the gateway’s logs for the request and verifying the agent-facing side only ever shows the gateway key, never the downstream GitHub credential:

docker compose -f deploy/docker-compose.yml logs gateway --tail=20

[info] tenant=default profile=github-readonly-coding-agent tool=list_pull_requests status=allowed
[info] credential injected target=api.github.com latency_ms=142
[info] response forwarded to agent status=200

Then try an action outside that profile’s scope, such as asking the same agent to merge a pull request. A correctly configured profile should return an authorization failure from the gateway itself, before the request ever reaches GitHub, which is the behavior that proves the scoping is actually enforced rather than decorative.

Step 12: Turn On Audit Logging and Analytics

Every call that passes through the gateway is already logged by default, but the optional ClickHouse analytics sink turns those logs into something you can query and build dashboards against, which matters once you have more than a handful of agents running. Enable it by setting the relevant flag and bringing up the analytics service on port 8090.

GATEWAY_SINKS_CLICKHOUSE_ENABLED=true

Restart the gateway container after changing this value so it picks up the new configuration, then confirm the analytics endpoint responds on port 8090 before relying on it for monitoring. If you are only running a handful of agents, the default logs captured by docker compose logs are enough, and enabling ClickHouse is worth deferring until the log volume justifies a dedicated analytics store.

Step 13: Harden Egress and Rotate Keys for Production

Before calling this deployment production-ready, revisit the egress allowlist from Step 3 and confirm it contains only the exact hosts your registered MCP servers and LLM providers need, nothing broader. Then rotate the admin bootstrap key generated in Step 5, since that key was likely visible in your terminal scrollback and should not remain the permanent administrative credential for the deployment.

docker compose -f deploy/docker-compose.yml exec gateway /gateway rotate-admin-key

Finally, go back to the list of leaked or overly broad credentials you documented in Step 1 and revoke each one at its source now that the corresponding agent is routing through a scoped gateway profile instead. Skipping this cleanup step is the most common way teams end up running a gateway in parallel with the exact plaintext-credential problem it was supposed to replace.

AI Agent Gateway vs Vault vs Doppler vs Infisical

An AI agent gateway is not a drop-in replacement for a general-purpose secrets manager, and the two solve overlapping but distinct problems. HashiCorp Vault, Doppler, and Infisical are built to store and distribute secrets to any application, human or machine. Tuskira’s AI Agent Gateway is built specifically for the agent-to-MCP-to-service call pattern, with profile-based scoping designed around how agents actually make tool calls rather than how a generic application reads an environment variable at startup.

Tool	Primary Purpose	Deployment	License / Model	Native MCP Awareness
Tuskira AI Agent Gateway	Credential injection for agent-to-MCP-to-service calls	Self-hosted only	Apache 2.0, free	Yes, built around MCP from the ground up
HashiCorp Vault	General-purpose secrets management and encryption	Self-hosted or HCP Cloud	Open source core + paid Enterprise tier	No, requires custom integration for MCP flows
Doppler	Team secrets management with sync across environments	SaaS	Commercial, published team/business tiers	No native MCP layer, but publishes guidance on securing MCP servers manually
Infisical	Open-source secrets management with a Kubernetes operator	Self-hosted or cloud	Open source core + paid tiers	No native MCP layer

In practice, the two categories complement each other rather than compete. A reasonable production setup stores the actual long-lived secrets, the GitHub app credentials, the LLM provider keys, in Vault or Infisical, and configures the AI Agent Gateway to pull from that backend rather than maintaining its own entirely separate credential store. The gateway’s value is the MCP-aware policy layer on top, not a reinvention of secrets storage itself.

Complete Working Project: Securing a Claude Code + GitHub MCP Workflow

Putting every step above together, here is the full working deployment: a gateway fronting a GitHub MCP server, with a scoped profile for a Claude Code coding agent that can read repository contents and list pull requests, but cannot merge or delete anything.

# 1. Clone and configure
git clone https://github.com/Tuskira/tusk-ai-secured-gateway.git
cd tusk-ai-secured-gateway
cat > deploy/.env <<'EOF'
GATEWAY_EGRESS_ALLOWED_HOSTS=api.github.com,api.anthropic.com
GATEWAY_LLM_PROXY_CAPTURE_STORE_BODIES=false
GATEWAY_CAPTURE_STORE_BODIES=false
GATEWAY_SINKS_CLICKHOUSE_ENABLED=false
EOF

# 2. Launch
docker compose -f deploy/docker-compose.yml up --build -d

# 3. Bootstrap admin access
docker compose -f deploy/docker-compose.yml exec gateway /gateway bootstrap-key
docker compose -f deploy/docker-compose.yml exec gateway /gateway create-user \
  -tenant default -username admin -role admin

# 4. In the console at http://localhost:8081:
#    - Add Anthropic as an LLM provider with your real API key
#    - Add a GitHub MCP connector with your real GitHub token
#    - Create profile "github-readonly-coding-agent" scoped to
#      read_file, list_pull_requests, list_issues only

# 5. Generate a gateway key for that profile, then configure Claude Code:
cat > ~/.claude/mcp.json <<'EOF'
{
  "mcpServers": {
    "github-via-gateway": {
      "url": "http://localhost:8080/mcp",
      "headers": {
        "X-Gateway-Key": "gw_profile_REPLACE_ME",
        "X-Gateway-Profile": "github-readonly-coding-agent"
      }
    }
  }
}
EOF

# 6. Restart Claude Code and test
#    Ask it to list open pull requests, confirm success,
#    then ask it to merge one and confirm the gateway rejects it.

Once this is working, the only credential Claude Code ever holds is the scoped gateway key from Step 5 of the main walkthrough. The real GitHub token and Anthropic API key live exclusively inside the gateway's encrypted store, and revoking Claude Code's access, if the laptop running it is ever lost or compromised, is a single key revocation in the admin console rather than a scramble to rotate every underlying secret across every service that agent touched.

5 Common Pitfalls When Deploying an AI Agent Gateway

Most of the problems teams run into with a new gateway deployment trace back to a handful of avoidable mistakes, and they tend to surface in the first week rather than months in.

Running pre-1.0 alpha software against a production credential store without pinning a version. The project is explicitly labeled pre-1.0 alpha, meaning its APIs are subject to change. Pulling the latest main branch on a routine basis can silently change behavior you depend on. Pin a specific commit hash and upgrade deliberately after reviewing what changed.

Creating one broad profile shared across every agent. This is the single most common way teams undermine the entire point of a gateway. A profile scoped to "everything GitHub can do" shared across five different agents is not meaningfully different from five agents each holding the same unscoped GitHub token directly.

Leaving the egress allowlist empty or overly broad. An empty GATEWAY_EGRESS_ALLOWED_HOSTS value does not fail closed by default in every configuration path, so always verify explicitly which hosts are reachable through the gateway rather than assuming an empty list means nothing is allowed.

Forgetting to revoke the original, now-redundant credentials. Migrating an agent to use the gateway does nothing to disable the plaintext key it was using before. That old key keeps working at the source service until someone manually revokes it, which means the migration has added a layer of control without actually closing the original exposure.

Never rotating the bootstrap admin key. The administrative key generated in Step 5 is powerful enough to create and modify every profile in the tenant. It is also typically the first key generated, often visible in shell history or terminal scrollback from the initial setup session, which makes rotating it early a cheap insurance policy against a leftover screenshot or shared terminal session.

Troubleshooting the Gateway: 8 Issues and How to Fix Them

Gateway container restarts in a loop immediately after startup. Check docker compose logs gateway for a database connection error first. This almost always means PostgreSQL was not ready when the gateway tried to connect, or the connection string in deploy/.env points at the wrong host or port.

Port 8080, 8081, or 8082 already in use. Another service on the host, often a previous MCP server or a development web server, is already bound to one of these ports. Run sudo lsof -i :8080 to identify the conflicting process, then either stop it or remap the gateway's port in the Compose file.

Admin console at port 8081 returns a connection refused error. Confirm the gateway container is actually healthy with docker compose ps before assuming the console itself is broken. A gateway container stuck restarting will never serve the console, no matter how long you wait on the browser.

Agent calls return a 403 despite a profile that should allow the action. Double-check the exact tool name scoped in the profile against the tool name the MCP server actually exposes. A mismatch as small as list_pull_requests versus listPullRequests will cause every call for that tool to fail authorization even though the profile looks correct in the console.

Bootstrap key command returns an error about an existing key. The bootstrap flow is meant to run once per fresh deployment. If you already generated a key and lost it, use the admin recovery path documented in the repository's README rather than attempting to force a second bootstrap, which the gateway will reject.

LLM proxy calls through port 8082 hang or time out. Verify the provider key entered in the admin console is still valid and has not been rotated or revoked at the provider's end. A stale key will often cause the gateway to hang waiting on a response rather than failing immediately, depending on the provider's own timeout behavior.

ClickHouse analytics sink shows no data after enabling it. Confirm the ClickHouse service itself is running and reachable from the gateway container, and that you restarted the gateway after flipping GATEWAY_SINKS_CLICKHOUSE_ENABLED to true. Changing this flag without a restart leaves the gateway running with its old configuration in memory.

Claude Code or Cursor does not pick up the new MCP server entry. Both tools cache MCP server definitions per session. Fully restart the agent application, not just reload the active window, after editing its MCP configuration file to point at the gateway.

Credential injection appears to work, but the downstream GitHub call fails with an authentication error. This usually means the real GitHub credential registered in the gateway's MCP connector configuration has expired or lacks the scope needed for the specific call. Re-check the token's permissions directly on GitHub's side rather than assuming the gateway's routing is at fault.

Advanced Tips: Scaling, Rotation, and Multi-Tenant Hardening

Once the basic deployment is stable, a few practices separate a gateway that survives contact with a real engineering org from one that quietly becomes shelfware. Run the gateway behind a load balancer with multiple replicas sharing the same PostgreSQL backend once you have more than a handful of agents, rather than scaling a single container vertically. Because the gateway is stateless beyond its database connection, horizontal scaling is straightforward as long as every replica points at the same PostgreSQL instance and, if you use it, the same Redis or Valkey session store.

Treat profile definitions as infrastructure, not console clicks. Export each profile's configuration and keep it in version control alongside the rest of your infrastructure-as-code, so a change to what an agent can access goes through the same review process as any other infrastructure change, rather than living only as an unaudited edit in the admin console. For larger organizations running multiple teams or environments, use the multi-tenant support from Step 6 to give each team its own tenant with its own isolated set of profiles, rather than running separate gateway deployments per team, which multiplies the operational burden of patching and version management.

Finally, build key rotation into a recurring schedule rather than a one-time setup task. Gateway keys tied to profiles should rotate on a cadence that matches your organization's broader secrets rotation policy, and the admin bootstrap key specifically should rotate immediately after any incident involving a shared terminal session, a screen share, or a laptop that left the building. If your organization already tracks credential exposure incidents, our guide on blocking API credential stuffing covers the detection side of the same underlying problem: credentials that outlive their intended exposure window.

Keep an eye on the broader MCP security landscape too. CISA has already flagged its first MCP-related vulnerability in LiteLLM, and funding is pouring into dedicated AI agent security vendors, as covered in our look at the funding gap between Zenity, HiddenLayer, and Straiker. A gateway is one layer of defense, not a replacement for keeping up with vulnerabilities in the MCP ecosystem itself, including in gateways and AI tooling from larger vendors, as GitLab learned with the critical flaw in its own AI Gateway component.

Frequently Asked Questions

Is Tuskira's AI Agent Gateway free to use?
Yes. It is released under the Apache 2.0 license and is available at no cost from its GitHub repository. Tuskira also sells a broader commercial security platform, but the gateway itself is a standalone open-source project that runs entirely in your own environment without requiring a Tuskira account.

Is this gateway ready for production use?
The project is explicitly labeled pre-1.0 alpha as of early October 2026, meaning its APIs are subject to change without the stability guarantees of a 1.0 release. Treat it as suitable for a controlled rollout with version pinning and close monitoring rather than an unattended, set-and-forget production dependency just yet.

Which LLM providers does the gateway support?
Anthropic Claude, AWS Bedrock, OpenAI, and Google Gemini, according to the project's documentation. You only need to configure credentials for whichever provider or providers your agents actually call.

Does the gateway work with any MCP server, or only specific ones?
It is designed to support any MCP-compatible tool server through its connector framework, not a fixed list. The common examples in its launch material are GitHub and Jira, but the underlying mechanism, gateway key plus profile, credential injection on approval, applies to any MCP server you register.

Do I still need a secrets manager like Vault if I'm using this gateway?
Most teams benefit from both. The gateway handles the MCP-aware policy layer, deciding which agent can call which tool, while a general-purpose secrets manager like Vault or Infisical can serve as the actual backend store for the long-lived credentials the gateway injects.

What happens if the gateway itself goes down?
Every agent configured to reach a service exclusively through the gateway loses that access until the gateway is restored, since the gateway is now the only path to the real credential. This is the standard tradeoff of any centralized proxy: it reduces the blast radius of a single compromised agent at the cost of becoming a dependency every agent now relies on.

Can I run this without Docker?
Yes, by building from source. That path requires Go 1.27 and, if you also want to build the admin console UI, Node.js 26, along with GNU Make to drive the build. The Docker Compose path is faster to get running and is what this tutorial focuses on.

How is this different from the separate Agentgateway open-source project?
They are two different codebases solving an overlapping problem. Agentgateway, donated to the Linux Foundation in 2025 and accepted as an Agentic AI Foundation project in 2026, is a broader AI-native proxy and control plane. Tuskira's AI Agent Gateway is a narrower, purpose-built tool focused specifically on keeping credentials out of individual agent configuration files. Both converge on the same core idea of exchanging agent identity for injected credentials, but they are not interchangeable and are not built or maintained by the same organization.

Related Coverage

• GitLab Patches CVSS 9.9 AI Gateway RCE in Duo Agent [2026]
• Falco Runtime Security Setup: 13 Steps, 90 Min [2026]
• GitGuardian ggshield Setup: Block AI Coding Leaks in 13 Steps [2026]
• Citrix NetScaler Hit by 3rd Zero-Day, CVE-2026-88779 [2026]
• South Korea Probes AI Use in Bank Hacks, 68,000 Exposed [2026]