{"slug": "ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix", "title": "AI Agent Cannot Reach Peer on Another Cloud? Here's the Fix", "summary": "A developer explains that AI agents on different clouds often fail to communicate due to security groups blocking inbound traffic, ephemeral IPs and NAT hiding peers, and ingress rules designed for human traffic. The fix is to use Pilot Protocol, an open-source overlay network that gives each agent a permanent virtual address, enabling reliable cross-cloud agent-to-agent communication without opening public ports.", "body_md": "You spin up an agent on AWS. It needs to call a tool-serving agent your teammate deployed on GCP. You get `connection refused`\n\n, or worse, a silent timeout. Both boxes are up. Both processes are listening. The agent still can't reach its peer on another cloud.\n\nThis is one of the most common failure modes in multi-agent systems once you move past a single-host demo, and it's worth understanding exactly why it happens before reaching for a fix.\n\nWhen an AI agent needs to call a peer — another agent, a tool server, an MCP endpoint — that peer needs a stable address and an open path. Cross-cloud, you lose both by default:\n\n**1. Security groups and firewalls block inbound by default.** AWS security groups, GCP firewall rules, and Azure NSGs all deny inbound traffic unless you explicitly allow it. That's correct behavior for security, but it means your agent on GCP has no way to accept a connection from your agent on AWS until someone opens a port — and opening ports to the public internet for agent-to-agent traffic is exactly the kind of exposure most teams don't want.\n\n**2. Ephemeral IPs and NAT hide the peer entirely.** Most agents run behind NAT (a Kubernetes pod, a container on a laptop, a serverless function) with no public IP at all. Even if you did open a port, there's no stable address to open it *on* — the IP changes on every redeploy, every autoscale event, every restart.\n\n**3. Ingress rules assume human traffic, not agent traffic.** Load balancers and ingress controllers are built around HTTP request/response from browsers or known API clients. Long-lived, bidirectional, agent-initiated connections don't map cleanly onto that model, which is part of why long-running agent tasks that rely on webhooks time out or drop mid-conversation.\n\nPut together: two agents can be perfectly healthy and still have no valid network path between them the moment they're on different clouds, different VPCs, or different NAT boundaries.\n\nThe fix that generalizes across all three failure modes above is to stop routing to IP addresses and start routing to a permanent virtual address that belongs to the agent, not the host it happens to be running on. This is the same idea behind CGNAT-friendly overlay networks broadly, applied specifically to AI agents.\n\n[Pilot Protocol](https://pilotprotocol.network/docs) is an open-source overlay network built for exactly this: every agent gets a permanent virtual address that survives restarts, IP changes, and moving across clouds. Under the hood:\n\nIt's implemented in Go with zero external dependencies (stdlib only), open source under AGPL-3.0.\n\nInstall the daemon on both hosts — the AWS box and the GCP box, or wherever your agents live:\n\n```\ncurl -fsSL https://pilotprotocol.network/install.sh | sh\n```\n\nStart the daemon on each:\n\n```\npilotctl daemon start --hostname agent-a   # on the AWS host\npilotctl daemon start --hostname agent-b   # on the GCP host\n```\n\nFrom agent-a, initiate a handshake with agent-b — this is the one step that replaces \"open a security group rule and hope the IP doesn't change\":\n\n```\npilotctl handshake agent-b \"coordinating a task pipeline\"\n```\n\nAgent-b approves it (or an auto-trust policy can do this automatically for known sources):\n\n```\npilotctl approve <node_id_of_agent_a>\n```\n\nOnce mutual trust is established, either side can message the other by hostname — no public IP, no open inbound port, no re-propagating addresses after a redeploy:\n\n```\npilotctl send-message agent-b --data \"status check\" --wait\n```\n\nCheck that the tunnel is actually up:\n\n```\npilotctl ping agent-b\npilotctl peers   # shows transport state — direct or relayed\n```\n\nThat's the whole loop: install, start, handshake, approve, send. The address for agent-b never changes even if GCP assigns it a new ephemeral IP tomorrow.\n\nOnce agents can reach each other reliably, the next problem is usually \"what can I actually call on the other end.\" Pilot also ships an app store — installable capabilities that run locally on a daemon as typed JSON-in/JSON-out services, auto-spawned on install:\n\n```\npilotctl appstore catalogue\npilotctl appstore install io.pilot.cosift\npilotctl appstore call io.pilot.cosift cosift.search '{\"q\":\"your query\",\"k\":\"5\"}'\n```\n\nThe pattern is discover → install → call, and it composes with the peer addressing above: an agent on any cloud can reach a peer's installed capabilities the same way it reaches the peer itself.\n\n**Is this the same problem as a webhook timing out?** Related but distinct. Webhook timeouts happen because HTTP request/response wasn't designed for long-running agent tasks. Cross-cloud unreachability happens because there's no valid network path at all — the ingress/NAT/firewall layer never let the connection through in the first place. An overlay network with persistent tunnels addresses both: it replaces the fragile HTTP round-trip with a standing, encrypted connection.\n\n**Do I need to open any inbound ports?** No — that's the point. NAT traversal (STUN + hole-punching, relay fallback) is designed so neither peer needs a public IP or an open inbound port.\n\n**What if the peer is on a completely different cloud provider, not just a different VPC?** Doesn't matter — the overlay address is independent of the underlying network. That's the difference between routing to an IP (tied to a specific host, cloud, and subnet) and routing to a virtual address (tied to the agent's identity).\n\n**Does joining the network mean every agent can reach every other agent?** No. Trust is a separate, explicit step from being on the network — each peer relationship requires mutual approval before traffic flows.", "url": "https://wpnews.pro/news/ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix", "canonical_source": "https://dev.to/pstayet/ai-agent-cannot-reach-peer-on-another-cloud-heres-the-fix-30hp", "published_at": "2026-07-09 16:32:02+00:00", "updated_at": "2026-07-09 16:35:40.115590+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Pilot Protocol", "AWS", "GCP", "Azure"], "alternates": {"html": "https://wpnews.pro/news/ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix", "markdown": "https://wpnews.pro/news/ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix.md", "text": "https://wpnews.pro/news/ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix.txt", "jsonld": "https://wpnews.pro/news/ai-agent-cannot-reach-peer-on-another-cloud-here-s-the-fix.jsonld"}}