AI Agent Egress Security: Why Domain Allowlists and Static IP Allowlists Solve Different Risks

QuotaGuard Engineering
October 3, 2026
•
5 min read
Pattern

AI agents running on cloud and serverless platforms often cannot reach IP-restricted APIs, databases, enterprise systems, or MCP servers because their outbound IP addresses keep changing. QuotaGuard gives customer-controlled agent traffic two stable outbound IPs that the receiving system can allowlist, without forcing you to move the workload or operate your own egress infrastructure.

Route only the protected connection through QuotaGuard. Keep the agent's existing destination restrictions, approvals, credentials, and monitoring. The destination sees a predictable source address, while the rest of the agent's traffic continues using its normal path.

Need a static outbound IP for an AI agent?

Connect the agent's proxy-capable HTTP, HTTPS, or SOCKS5 client to QuotaGuard, give the destination owner both IP addresses shown in your dashboard, and keep your existing application security controls in place.

Give AI Agent Traffic a Stable Source IP

APIs, databases, enterprise firewalls, and private services often accept connections only from approved source addresses. That creates a problem for AI agents running on platforms where outbound traffic can leave through changing cloud IPs.

A redeploy, restart, scaling event, or infrastructure change can send the next request through a different address. The destination rejects the request even though the API key, TLS connection, and application code are correct.

QuotaGuard places a managed static egress layer between the customer-controlled agent and the protected destination:

customer-controlled AI agent or tool executor
  -> QuotaGuard proxy
  -> two stable outbound IPs
  -> allowlisted API, database, MCP server, or enterprise system

The destination owner allowlists both addresses assigned to the QuotaGuard subscription. Approved requests then arrive from that stable pair regardless of which supported cloud platform runs the agent.

See the QuotaGuard AI agent static IP integration, compare current Static and Shield plans, or talk to QuotaGuard engineering about the connection path.

Destination Allowlists and Source IP Allowlists Solve Different Problems

AI agent egress security still requires destination controls. A stable source IP does not replace them. The two controls sit on opposite sides of the connection.

Control What it protects What it does not replace
Domain or destination allowlist Limits which hosts or services the agent runtime, application client, or egress layer may reach. Does not provide a stable source address that the receiving firewall can allowlist.
Static source IP allowlist Lets the receiving API, database, MCP server, WAF, or firewall accept traffic from an approved egress address. Does not stop prompt injection, unsafe tool selection, or misuse of an approved destination.
Authentication and authorization Establishes caller identity and limits which data or operations the caller may access. Does not stabilize the workload's network identity or operate the egress infrastructure.

Use destination policy to control where the agent may connect. Use QuotaGuard to give permitted connections a stable source address. Use authentication and authorization to control what the caller may do after the connection is accepted.

When QuotaGuard Is the Right AI Agent Egress Solution

QuotaGuard is a strong fit when all of the following are true:

  • The agent, tool executor, application, or integration runs in infrastructure you control.
  • The client opening the downstream connection supports an HTTP, HTTPS, or SOCKS5 proxy.
  • The destination requires one or more fixed source IP addresses.
  • You want to keep the workload on its existing cloud, serverless, container, or application platform.
  • You do not want to operate redundant proxy servers, NAT gateways, health checks, failover, patching, and monitoring yourself.

QuotaGuard provides

  • A load-balanced pair of stable outbound source IPs.
  • Managed proxy infrastructure, monitoring, maintenance, and failover.
  • A portable network identity that can remain stable across hosting-platform changes.
  • Selective routing for the destinations that require fixed source addresses.
  • Dedicated IPs and proxy resources on Enterprise plans when customer-only infrastructure is required.

Keep these controls in place

  • Agent sandboxing and approval controls.
  • Domain, host, and HTTP-method restrictions.
  • TLS, credentials, authentication, and authorization.
  • Least-privilege tool scopes and write permissions.
  • Application logs, proxy monitoring, rate limits, and incident alerts.

Codex and MCP: Check Which Environment Opens the Connection

The important question is not simply whether the workload uses Codex or MCP. The important question is which environment opens the connection to the protected destination.

Customer-controlled agent or executor

If the request leaves a command, script, application, or executor running in infrastructure you control, and that client supports a proxy, the connection may be routed through QuotaGuard.

Keep the runtime's native network restrictions active. OpenAI's Codex internet-access guidance recommends limiting agents to the domains and HTTP methods they need because unrestricted access increases the risk of prompt injection, secret exfiltration, malware, and vulnerable dependencies.

Vendor-hosted or remote MCP connection

If the connection originates entirely inside a vendor-managed runtime, adding QuotaGuard to your own application does not reroute that vendor-originated traffic. OpenAI's agent-environment security guidance distinguishes customer-controlled executor connections from remote service connections.

An executor MCP running in your infrastructure may qualify for QuotaGuard routing. A remote MCP connection opened by the vendor's service does not use your QuotaGuard subscription unless the architecture gives you control over the component making that downstream request.

Deploy Static Egress for an AI Agent

  1. Identify the blocked connection. Record the protected API, database, MCP server, or enterprise system and determine which component opens the connection.
  2. Confirm proxy support. Verify that the customer-controlled HTTP, HTTPS, database, or SOCKS5 client can use the appropriate QuotaGuard proxy.
  3. Restrict the destination. Allow only the hosts, endpoints, and HTTP methods the agent actually needs.
  4. Route only the protected traffic. Configure the relevant client to use the QuotaGuard proxy instead of sending every agent request through it.
  5. Allowlist both QuotaGuard IPs. Give the destination owner the exact address pair displayed in the QuotaGuard dashboard.
  6. Verify the egress address. Call ip.quotaguard.com through the configured proxy and confirm that the returned address belongs to the assigned pair.
  7. Test the real destination. Confirm that the protected service accepts the request, that both assigned addresses are allowed, and that authentication and authorization still behave correctly.

Managed Static Egress Versus Building It Yourself

You can create a stable outbound IP with NAT gateways, elastic IPs, proxy virtual machines, load balancers, or regional network appliances. The IP address is only the beginning of the production responsibility.

A self-managed egress path requires redundant hosts, health checks, failover, capacity planning, operating-system maintenance, proxy upgrades, credentials, monitoring, regional placement, and incident response. It can also bind the allowlisted identity to one cloud architecture, making a future migration another firewall project.

QuotaGuard operates that network layer as a managed service. Your application keeps its existing hosting platform, while approved outbound traffic receives a stable source identity that partners and enterprise systems can retain on their allowlists.

Standard QuotaGuard plans use managed shared infrastructure with a stable IP pair assigned to the subscription. If a security review or contract requires customer-only addresses and dedicated proxy resources, use QuotaGuard Enterprise dedicated infrastructure.

What a Static Source IP Does Not Solve

A static source IP is a network control. It does not determine whether an agent's decision was safe, whether a prompt contained malicious instructions, or whether an approved credential is being misused.

OpenAI's MCP security guidance warns that untrusted content can attempt to retrieve private data and send it through another tool. The MCP project likewise describes tool annotations as risk hints rather than enforceable security contracts.

A stable IP lets the receiving system confirm that a request arrived from an approved source address. It does not prove user identity, workload integrity, request intent, or model safety.

Keep destination restrictions, approval controls, scoped credentials, authentication, authorization, audit logs, and monitoring. QuotaGuard solves the stable egress identity problem so those other controls can remain focused on the decisions they are designed to enforce.

Frequently Asked Questions

How do I give an AI agent a static outbound IP?

Run the agent or tool executor in customer-controlled infrastructure, configure its proxy-capable client to use QuotaGuard, and give the destination owner both static IPs assigned to the subscription. Only traffic sent through the proxy receives the QuotaGuard source address.

Does a static IP stop prompt injection?

No. Static source IP allowlisting controls which network addresses a receiving service accepts. Prompt-injection defenses require constrained tools, destination restrictions, approvals, least privilege, careful handling of untrusted content, and monitoring of consequential actions.

Can QuotaGuard route MCP traffic?

QuotaGuard can route an MCP-related connection when the component opening that connection runs in customer-controlled infrastructure and supports the required proxy configuration. It cannot reroute a remote MCP connection originating entirely inside a vendor-managed service.

Can a static source IP protect a stolen API key?

It can reduce where the stolen key works if the receiving service requires both valid credentials and a request from an approved IP. It does not replace credential rotation, short-lived tokens, scoped permissions, or monitoring.

Are standard QuotaGuard IPs dedicated?

No. Starter, Production, and Business plans use managed shared infrastructure with a stable IP pair assigned to the subscription. Enterprise plans provide dedicated IPs and proxy resources reserved for the customer.

Should an AI agent use QuotaGuard Static or Shield?

QuotaGuard Static is the normal starting point for API, automation, database, and agent allowlisting. Outbound HTTPS remains encrypted to the destination and is tunneled without decrypting the application payload. Shield also protects the client-to-proxy connection with TLS and is designed for approved compliance-sensitive architectures.

Give approved AI agent traffic a stable source identity.

Talk to QuotaGuard engineering about your agent runtime, protected destination, proxy protocol, regional requirements, and whether shared or dedicated infrastructure fits the security review.

QuotaGuard Static IP Blog

Practical notes on routing cloud and AI traffic through Static IPs.

Reliability Engineered for the Modern Cloud

For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.

Get the fixed identity and security your application needs today.