agentgateway.dev funnels every LLM call, MCP tool connection, and A2A hop into one data plane you run. Give that data plane two fixed static EU IPs, and providers, firewalls, and partner agents all see one dependable origin.
llm:
models:
- name: gpt-3.5-turbo
provider: openAI
params:
model: gpt-3.5-turbo
apiKey: "$OPENAI_API_KEY"
# gateway egress fixed via
# HTTPS_PROXY in its environment
The gateway solved routing, auth, and observability for AI traffic. What it cannot solve from inside is the address that traffic leaves from.
Every agent, tool, and model call your teams make now crosses one process. But that process rides whatever address the scheduler gave it: rescheduled on another node, restarted after a config rollout, and the whole company's AI egress silently changes origin. The consolidation you built stops at the cluster boundary.
Half the point of the MCP gateway is reaching tools and data sources that sit inside someone's perimeter: internal APIs, SaaS endpoints, partner MCP servers. Those endpoints admit traffic from addresses they know. A gateway phoning in from rotating cloud ranges turns every new tool connection into a firewall ticket negotiation.
Virtual keys and budget controls govern how teams consume models, but underneath them the gateway still holds real credentials for OpenAI, Anthropic, Bedrock, Gemini, and the rest. If one leaks, the blast radius is every model you route. Restricting those keys to addresses you own is the backstop that survives a leak.
Load balancing and automatic provider failover are core reasons teams adopt agentgateway, and they mean many different front doors judge your source address at once. When your traffic exits from shared cloud pools, reputation problems on one range hit you mid-failover, exactly when you needed the spare provider to just work.
agentgateway
LLM routes, MCP tools, A2A
HTTPS Proxy
(Static EU IP)
Providers & tools
LLM APIs, MCP, A2A peers
Seen from outside, your entire agent fleet becomes a single well-behaved client on two permanent European addresses. Allowlists written once keep matching after every node reschedule and every config rollout.
Your config.yaml keeps describing listeners, routes, and policies exactly as the agentgateway docs intend. Egress belongs to the environment the process runs in, so that is where the pair of addresses gets attached.
Add a streaming route tomorrow, federate three more MCP servers next week: none of it touches your network story, because the addresses at the exit do not move when the routing table grows.
Prompts, tool payloads, and agent conversations leaving through fixed European exits give your GDPR and EU AI Act documentation a network section that fits in two sentences.
Teams who run the data plane themselves and answer for what it touches.
Groups offering an internal AI platform through the Gateway API controller, who need the gateway pods' egress to be as predictable as their ingress.
Security-minded orgs federating internal MCP servers and APIs through the gateway, where the destination side insists on knowing exactly who is calling.
Teams leaning on virtual keys, budgets, and provider failover, who want every provider front door to recognize the same two addresses.
Consultancies deploying gateways for client after client, who want the network posture question answered once instead of per engagement.
Clients keep talking to the gateway. The gateway's environment gains the fixed exit.
Your application code changes nothing about its egress; it talks to the gateway on localhost like the quickstart shows. The OpenAI SDK just swaps its base URL.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:4000/v1",
api_key="agentgateway-virtual-key",
)The proxy lives in the environment of the agentgateway container, not in its YAML. Official image, config mounted, plus an env file holding the proxy URL and the provider key.
# .env.agentgateway (git-ignored)
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
NO_PROXY=localhost,127.0.0.1
OPENAI_API_KEY=sk-your-keyservices:
agentgateway:
image: cr.agentgateway.dev/agentgateway:v1.2.0
ports:
- "3000:3000"
volumes:
- ./config.yaml:/config.yaml
env_file: .env.agentgateway
command: ["-f", "/config.yaml"]Run any HTTP client inside the same environment; requests picks the proxy up from the variables and prints the address your provider logs will show.
import requests, os
# HTTPS_PROXY honoured from the environment
print(requests.get("https://api.ipify.org", timeout=30).text)On the Gateway API deployment, the pod spec carries the egress so the controller's pods inherit it. Keep the proxy URL in a Secret, never in the manifest.
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway
key: proxy-url
- name: NO_PROXY
value: localhost,127.0.0.1,.cluster.localTwo addresses behind one attachment
The URL you store points at a redundant pair of European IPs: traffic flows through whichever node is healthy, and the pair trades places without introducing an address nobody allowlisted. Provider-side rules you write today keep describing your gateway tomorrow.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
A gateway for AI workloads concentrates prompts, tool payloads, and agent conversations. Where that concentration exits is now a one-line answer.
Personal data riding inside prompts and tool responses leaves through named European addresses, so the transfer description in your records matches the infrastructure instead of a rotating pool.
Operational control over where your AI system sends data is exactly the kind of technical measure the Act's documentation asks providers and deployers to describe. Fixed egress is a paragraph, not a project.
Firewall rules and partner entries written against your two addresses keep matching through reschedules, upgrades, and cluster migrations.
No YAML surgery, no new policies: the addresses ride in the process environment, and routing behavior stays byte-for-byte identical.
Maintenance on one node hands traffic to its partner, and the outside world still sees the same two addresses it always did.
Every provider call and tool fetch leaves from inside the Union, keeping residency descriptions short and checkable.
LLM front doors, MCP servers, A2A peers, plain HTTP APIs: whatever route the gateway opens, the exit covers it the same way.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
You centralized the routing. Attach two permanent EU addresses and the outside view of your entire agent platform finally holds still.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
No. Your listeners, routes, backends, and policies stay exactly as the agentgateway documentation describes them. The egress lives one level down, in the environment of the process itself: standard proxy variables on the container or pod, stored separately from your routing configuration. Attach, restart, done.
Unfortunately no. The gateway consolidates where requests come from, not where they go out to. Its own outbound connections still use whatever network the process sits on, so a pod rescheduled to another Kubernetes node, or a container restarted on a new host, presents a different address to every provider and tool it calls. Centralized routing and stable egress are two separate problems, and the second one is ours.
You register both addresses once, everywhere a source IP matters, and forget about it. They operate as a failover set: the proxy picks a healthy node per connection, and if one steps out for maintenance its partner takes over without any third address ever appearing. Nothing to update, nobody to notify.
Tell us which providers and MCP endpoints yours talks to. We will map out what the fixed egress should cover, including your Gateway API setup.
Contact Our Founders →