Static IPs for AI agent sandboxes: dedicated egress guide

Your agent needs to call a partner's payment API. The partner won't grant production access until you register your outbound IP addresses.

Global Payments states the rule plainly: "For Production, we only accept transactions from IP addresses on your account's allow list." Your sandboxes run across shared infrastructure. Each one draws an outbound IP from a rotating pool. That IP changes with every lifecycle event. You can't give the partner a stable list because there isn't one.

This blocks production for teams integrating agents with enterprise APIs. Fiserv's ControlCenter requirements are "mandated for any merchant" sharing trusted IP ranges. Unshared IPs get blocked. Optum lists customer-side IP allowlisting as a production-readiness step for its eligibility API. Rotating IPs work fine for web browsing and public APIs that authenticate by key or token. They break integrations with partners that verify callers by source address.

TL;DR

• Rotating IPs block partner integrations: Enterprise APIs that verify callers by source address can't accept traffic from rotating sandbox IPs.
• A dedicated egress gateway assigns static outbound IPs: Sandbox traffic routes through a gateway with a fixed IP set. Partners allowlist those IPs once.
• The gateway manages the IP: It handles egress at the infrastructure layer, so agent code makes standard outbound calls with no networking configuration.
• Multiple agents share the same static IP set: Every sandbox assigned to the gateway exits through the same addresses. One IP set covers the fleet.
• Allowlisting stops being an integration blocker: Partners see a stable source IP. The handshake works like it does for a traditional server with a static address.

Why AI sandboxes produce changing outbound IPs

Default outbound paths for ephemeral compute often aren't suitable for stable allowlists. Sandbox platforms inherit that behavior because they're built on the same primitives.

Why ephemeral networking obscures the caller's identity

Don't build an allowlist on an auto-assigned address. Auto-assigned public IPv4 addresses on EC2 come from Amazon's pool. They are released when an instance stops, hibernates, or terminates. A new address arrives on restart. On Azure, Microsoft owns the default outbound access IP.

It "can change without notice" and isn't recommended for production. On platforms that use this model, each sandbox draws its outbound IP from a shared pool. AWS and Azure don't guarantee the same address across lifecycle events. Without that guarantee, integrations depending on IP stability can break during create, standby, resume, or delete. Partners end up holding an allowlist entry that no longer matches.

With shared network address translation (NAT), many tenants exit from the same addresses. Behind shared NAT, the IPv4 address no longer uniquely identifies a subscriber. You can't hand a partner "your" IP because it isn't yours alone. Allowlisting the shared address doesn't fix the problem.

A partner who admits the NAT IP admits every tenant behind it. Broad cloud IP ranges are accessible to any organization that rents space from the vendor. The guidance explicitly includes "malicious actors." Apply the same identity standard used for legitimate AI bots. Cloudflare requires IPs used solely by that bot, verifiable through a public list, reverse DNS, or ASN ownership.

How dedicated egress gateways provide static IPs

A dedicated egress gateway is a workspace-scoped network component with its own fixed IP set. Sandboxes attached to it send all outbound traffic through that gateway. They no longer use the shared pool.

Route sandbox traffic through a gateway

The IP belongs to the gateway, not to any individual sandbox. Attached sandboxes can spin up and later scale down or resume from standby. These events don't change the address a partner sees.

Blaxel Sandboxes return to standby after 15 seconds of network inactivity. They resume in under 25 milliseconds. Agent sessions cross that boundary repeatedly. Tying identity to the gateway removes every transition from the partner's view.

Blaxel's dedicated egress gateways, currently in private preview, let customers "exclusively attach IP addresses to sandboxes within their workspace." A single egress IP supports up to 32,000 sandboxes. IPs can be grouped into pools that load-balance outbound traffic for high-demand workloads. Sandboxes created without a gateway keep using the shared public IPs.

Gateway assignment occurs at sandbox creation, and removing it requires deleting the sandbox. The feature is currently limited to preproduction validation. Use the preview to validate the partner handshake. Plan the production cutover for general availability.

Compare the partner view with your infrastructure

The partner's firewall sees one consistent source IP for every request from your agents. From their side, your traffic looks identical to traffic from a fixed server in a data center. Agent code makes ordinary HTTP requests. The gateway rewrites the source address at the network layer and forwards the packet. No SDK changes or per-agent networking code are needed.

Credential handling can move to the same layer. Blaxel's proxy secrets injection, in public preview, installs a certificate authority (CA) certificate. It also sets HTTP_PROXY, HTTPS_PROXY, and NO_PROXY inside the sandbox. The proxy matches outbound requests by destination domain. It resolves {{SECRET:name}} placeholders server-side. The sandbox runtime never holds the raw secret.

Standard clients such as curl, pip, npm, git, and Python requests use the proxy without code changes. Both configurations live under the sandbox's network key at creation. No combined example is currently available, so validate the pairing before production use. Treat the pairing as consistent with the documented primitives, not as a tested pattern. The partner receives an authenticated request from an allowlisted address. Neither the IP nor the credential appears in agent code.

How to configure static IPs for your agent sandboxes

List the partners requiring IP verification and your sandboxes' region. Those requirements determine gateway selection. Partners can then register the verified static IP.

1. Provision a dedicated egress gateway for your workspace

Create the gateway through your platform's console or API. It's scoped to your workspace. Any sandbox assigned to it routes outbound traffic through its IPs. In Blaxel, dedicated egress gateways are currently in private preview.

Order one from the console under Network → Egress gateways → Order IP. Then select the quantity and region. Provisioning typically completes within minutes. Contact the Blaxel team for preview access.

Assignment happens when you create a sandbox. Pick the gateway from the Egress IP drop-down in the console. Alternatively, pass a network.egress object through the SDK:

network: {
  egress: {
    mode: "dedicated",
    gateway: "egress-gateway-4"
  }
}

Only gateways in the new sandbox's region appear for assignment. Cross-region assignment isn't supported. Record the static IPs assigned to the gateway once the order completes. You'll hand those addresses to integration partners next. Store them alongside the gateway name and region.

2. Share the static IP set with your integration partners

Send the gateway's IPs to each partner requiring allowlisting. Use each partner's documented registration path. In Adyen, register them under Developers → API credentials → Server settings → Allowed IP range. Stripe registers IP restrictions through Access Policies. It recommends IP restrictions on all live mode keys. Some partners require separate IPs per environment. Galileo, for example, requires separate production IPs from those used in its CV environment.

Write a runbook for your operations team while the details are fresh. Record which partners hold which IPs. Include the date each was last verified.

Apply the same change discipline to the IPs your partners depend on. Adopt Stripe's seven days' notice before changing IPs and Auth0's weekly programmatic check on published ranges. Build the same check for your addresses.

3. Verify outbound traffic uses the static IP

Test from inside a running sandbox before declaring the setup complete. Make an outbound request to an IP-echo service. Compare the answer with the gateway's assigned IP. Use an external service such as curl ifconfig.me or checkip.amazonaws.com. If the response shows a shared pool IP, the sandbox lacks the gateway. Recreate it with the gateway assigned.

Don't confuse this check with instance metadata. On AWS, the metadata path for public-ipv4 returns the instance's own address. An external echo reflects the egress IP that the partner's firewall receives behind a NAT.

Close the loop with the partner. Ask them to confirm that requests from your static IP appear in their access logs. Nothing should arrive from other addresses.

4. Monitor gateway health and IP reputation

A static IP is a long-lived asset, and its reputation travels with it. Check it against blocklists on a schedule. Query its four datasets through Spamhaus. AbuseIPDB scores addresses 0–100 and recommends a blocking threshold of 75–100. Flags can arrive through no fault of your own.

Cloud IP reuse can transfer reputation between tenants. Malicious tenants can "pollute the address space" for future tenants. If an IP gets listed, plan for delisting time. Blocklist operators should reply within 2 days and must reply within seven. Partner traffic can stall for that week.

Keep a spare IP allocated. Monitor gateway health separately from sandbox health. A healthy sandbox behind a dead gateway has no route to the partner. Log the owner and timestamp for each check, along with its result. Alert on a new listing or reputation-score change so the team can start delisting before a partner blocks traffic.

When to use static or rotating IPs

Static IPs solve a specific integration problem. Routing every request through an unnecessary gateway adds a failure point.

Use cases that require static IPs

Route through a gateway when the destination checks your source address.

• Partner APIs with source-IP verification: Revolut's Business API makes IP allowlisting mandatory when the READ_SENSITIVE_CARD_DATA scope is active. Skipping it blocks every endpoint. Payment processors are the strictest group. Adyen and Optum document IP allowlisting or whitelisting controls for payments and healthcare eligibility.
• Compliance-driven segmentation: Compliance frameworks focus on restricted and deny-by-default outbound traffic. PCI DSS Requirement 1.3.2 requires cardholder-environment outbound traffic to be restricted to necessary traffic. Everything else is denied. NIST control SC-7(5) requires deny-by-default, allow-by-exception for outbound traffic. A dedicated egress IP makes that path identifiable and auditable for assessors.
• Internal network access: Agents reaching services behind a corporate firewall need an address the firewall team can register. If the partner also uses your cloud, ask about a private interconnect first. AWS PrivateLink removes the need to allowlist public IPs entirely.

Tag each of these integrations in your inventory before provisioning IPs.

Use cases where rotating IPs are fine

Keep gateway assignment limited to the IP-verified integrations tagged in your inventory.

• Key- or token-authenticated public APIs: Most SaaS APIs and public model endpoints fall here. Some providers actively discourage IP restrictions. Mastercard does not recommend IP allowlisting because its infrastructure changes. athenahealth doesn't guarantee stable IP addresses for its API servers and advises against allowlisting.
• Development and test environments: These rarely need a static IP, unless a partner's test environment demands one.
• Same-platform service calls: Calls between services on the same platform don't traverse the egress gateway.

Don't over-provision. Routing all traffic through one gateway creates a single point of failure when only a subset needs it. Resources across Availability Zones sharing one NAT gateway lose internet access if that gateway's zone fails.

Start by inventorying outbound destinations and tagging those that verify by IP. Attach the gateway only to sandboxes serving those integrations.

Give your agents a predictable network identity

Static IPs remove the blocker encountered when an agent needs production access to an allowlisted enterprise API. The gateway owns the address, so sandbox churn stops mattering to the partner.

A self-hosted NAT instance means the customer patches the OS and scripts failover. Istio's egress gateway "cannot securely enforce" that all egress traffic flows through it. Firewall rules have to backstop it.

Cilium's egress gateway leaves the administrator to manage and monitor the EC2 instances used as gateways. Each option adds a component your team runs. It also adds a failure mode your partners feel. Blaxel, the perpetual sandbox platform behind Blaxel Sandboxes, offers dedicated egress gateways, currently in private preview.

They assign static outbound IPs per workspace. Proxy secrets injection and Firecracker microVM isolation sit alongside them. IP identity and credential handling stay in infrastructure, out of agent code. Request private preview access at blaxel.ai/contact, or explore the platform at app.blaxel.ai.

[CTA:contact header="Unblock your partner integrations with static IPs" description="Dedicated egress gateways assign stable outbound IPs per workspace. Proxy secrets injection and Firecracker microVM isolation sit alongside them." buttonText="Request

FAQ

What is a dedicated egress gateway? It is a network boundary that gives selected sandboxes a shared, stable outbound identity independent of their individual lifecycles. Use one when a partner or firewall must register a source address rather than relying solely on credentials. Blaxel's dedicated egress gateway is currently in private preview and should be used to validate integrations, not as a production dependency.

How many static IPs do I need? Start with the minimum accepted by your partners. Add IPs when environments must remain separate, deployments span regions, traffic requires a larger pool, or you need a spare for reputation and availability incidents. Capacity rarely determines the initial count. Each additional address increases blocklist monitoring, change coordination, and the number of partner allowlist records your operations team must maintain.

Does the static IP change when sandboxes restart? The gateway keeps the address stable when a sandbox restarts, pauses, is replaced, or scales. The visible source changes only after a gateway, region, allocation, or outbound-path change. Treat those infrastructure changes as partner-facing network changes.

Can I use static IPs with proxy secrets injection together? Yes, at the design level. The two controls solve different problems: the gateway stabilizes network identity, while the proxy supplies credentials for matching destinations. Test routing and secret substitution independently before validating the combined request. Blaxel documents the features separately today; dedicated egress gateways are in private preview, and proxy secrets injection is in public preview.