Send Large Files Between AI Agents Without a Cloud Storage Bucket: Direct Transfers Over an Encrypted Tunnel

Your agent finished training and the other agent needs the weights. Or a pipeline stage produced a dataset and the next stage lives on a different cloud. The reflex is to stand up an S3 bucket, hand credentials to both sides, and pay the egress bill while you're at it.

But if you need to send large files between AI agents without a cloud storage bucket, there's a more direct path: give the agents a real network channel between them and transfer the file point-to-point. No bucket policy, no shared NFS mount, no third party sitting in the middle of your data.

This tutorial walks through what the direct approach actually requires, then shows a working agent-to-agent file transfer with Pilot Protocol — an open-source overlay network that gives every agent a permanent address and encrypted tunnels through NAT.

Why buckets became the default

Let's be fair to object storage first. S3 (and GCS, and Azure Blob) became the standard way to move artifacts between machines for a good reason: reachability. Two servers behind NAT can't open connections to each other, but both can reach a bucket. Upload from one side, download from the other. Problem solved — at the cost of:

• Credentials on both sides (plus rotation, plus a bigger leakage surface)
• A third party holding your data, even briefly
• Egress and storage costs for data that was just passing through
• Bucket policies, lifecycle rules, and versioning you never wanted to configure

A shared filesystem (NFS and friends) only works inside one trust domain — the same VPC, the same cluster. The moment your agents live on different clouds, or one sits behind a corporate firewall, the shared mount is off the table.

The underlying problem was never "we need storage." It was "these two machines can't reach each other."

The direct approach: agent-to-agent file transfer

If two agents have a persistent, encrypted, NAT-traversing channel, moving a file becomes a point-to-point operation. You don't need a bucket to transfer data between two endpoints that can already talk to each other.

That's the shape of an overlay network like Pilot Protocol. Each agent gets a permanent virtual address that survives restarts and IP changes. Traffic flows over encrypted UDP tunnels (X25519 key exchange + AES-GCM, with reliability handled in userspace), and STUN plus hole-punching with a relay fallback means agents behind NAT are reachable without any port forwarding. Trust is explicit: a handshake between the two peers, approved on both sides — joining the network doesn't make you trusted by anyone.

File transfer is built into the daemon, not bolted on. No object-store client library, no SDK ceremony for the common case. One command sends, one command lists what arrived.

Tutorial: moving an artifact between two agents

Here's the whole loop. Two hosts, worker-a and worker-b, on different networks.

1. Install on both hosts

curl -fsSL https://pilotprotocol.network/install.sh | sh

Same one-line install for the daemon and the pilotctl CLI, on both machines.

2. Start each daemon

pilotctl daemon start

Each agent registers and gets its permanent virtual address. From here on, that address is how the other side reaches it — no public IP, no port forwarding, no DNS gymnastics.

3. Establish trust

Private nodes require mutual trust before any data flows. On worker-a:

pilotctl handshake worker-b "shipping model weights"

On worker-b, approve the incoming request:

pilotctl approve <node-id>

That's the entire trust model — membership and trust are decoupled. Being on the network doesn't grant anyone access to your agent; you explicitly approve who can talk to you.

4. Send the file

On worker-a, where the artifact lives:

pilotctl send-file worker-b ./model-weights.bin

The command returns delivery metadata: filename, bytes, destination, sha256, verified, transport. Those last two fields are the integrity story — the receiving daemon verifies the transfer, so you're not shipping silent corruption risk across the wire.

5. Receive on the other side

On worker-b:

pilotctl received

Files land in ~/.pilot/received/ on the target. Delivery is asynchronous — the daemon stores files on arrival, so the recipient doesn't need an interactive session running at the exact moment the file lands. When you're done with them, pilotctl received --clear wipes the directory.

What sending large files without a cloud storage bucket actually requires

For big artifacts, the default transfer is streamed in chunks rather than sent as a single frame, so artifact size isn't what gates the transfer. What does matter:

• Both sides must be reachable on the overlay. That's what the NAT traversal is for — it's handled for you, relay fallback included.
• Disk space on the receiving side. The file lands in ~/.pilot/received/; the daemon doesn't garbage-collect for you.
• Mutual trust before you send. The handshake is a one-time setup and it persists.
• If your agent isn't the CLI, there's an SDK. Go, Python (pilotprotocol on PyPI), Node, and Swift bindings cover the programmatic case.

The whole thing is open source (AGPL-3.0, Go, zero external dependencies), so the tunnel and the trust logic are inspectable rather than a black box.

When to keep the bucket anyway

Direct transfer is a delivery mechanism, not a storage service. Keep the object store when:

• You need durable archival — the artifact must outlive both agents
• You're sharing with parties outside the overlay — humans, other orgs, pre-signed URLs
• You need CDN distribution — many readers, one source
• You want an audit trail of who accessed what — bucket logging gives you that

For the common case — one agent handing a large artifact to another agent it trusts, across clouds, through NAT — the direct channel removes a whole class of credential management and takes the middleman out of the data path. The network already carries 243k+ agents and users, so the addressing and trust layer is a solved problem rather than something you assemble from parts.

Try it

Install the daemon on the two hosts that need to trade files:

curl -fsSL https://pilotprotocol.network/install.sh | sh

Then handshake, send-file, and check received. The full command reference for file transfer, the inbox, and the stream and pub/sub models for everything that isn't a file lives in the Pilot Protocol docs.

The next time an agent needs to hand a large artifact to another agent, ask whether you actually need a bucket — or just a direct connection.