Agent-to-Agent File Transfer and Messaging

An agent working on its own is limited to what its owner gave it access to. Many useful tasks cross that boundary: a coding agent asks a colleague's agent for the schema of a service it does not own; a research agent hands a 150 MB dataset to an analysis agent on another machine; a scheduling agent negotiates a time with someone else's assistant. In each case the counterpart is not a tool with a fixed API but another agent with its own owner, its own judgement and the right to say no.

Files make this sharper. A message can be retried or rephrased; a file has to arrive intact, from the sender the recipient thinks it came from, and only if the recipient wanted it. That turns a messaging problem into an identity and consent problem.

Addressing and discovery

A web service has a domain name. An agent running in a terminal on a laptop has none, changes IP address when the laptop moves, and may be one of several agents on the same machine. It needs a stable name that does not depend on where it runs, plus a way for others to find agents that can help with a task.

Identity and trust

Display names are free to copy. A recipient needs to know that the agent writing today is the same one it talked to last week, and ideally which human or organisation stands behind it. Without that, a forged message asking an agent to send a file somewhere is indistinguishable from a real one.

Presence

Agents start and stop with their sessions, run in sandboxes that are destroyed after a task, and sleep with the laptop. A design that assumes the recipient always has a reachable endpoint excludes most agents; one that stores every message centrally until the recipient returns builds a mailbox of other people's data.

Consent

An agent that reads every incoming message and acts on it is an open door for spam and prompt injection. The recipient, or its owner's policy, needs to decide before any content is processed whether a stranger may start a conversation at all, and should be able to refuse with a reason rather than silently dropping it.

Encryption, files and audit

Content should be readable only by the two agents, not by every relay or gateway in between. Files need chunking, size limits, integrity checks and a rule about where on disk they may be read from and written to. And the owner needs a record of who contacted the agent and what it did, without that log becoming a copy of every message.

The Model Context Protocol is about an agent using capabilities. A host application runs clients that connect to servers; servers expose tools, resources and prompts; the model decides when to call a tool. The specification makes the host responsible for user consent before tools run. An MCP server is a capability rather than a peer: it does not have goals, discover other servers or start conversations. Two agents can share an MCP server, but MCP itself does not define how they address or authenticate each other.

The Agent2Agent protocol (A2A), contributed by Google and now an open-source project under the Linux Foundation, is about agents delegating to agents. In its 1.0 specification a remote agent publishes an Agent Card at /.well-known/agent-card.json describing its skills, endpoint and authentication schemes (API keys, HTTP auth, OAuth 2.0, OpenID Connect, mutual TLS). Clients send messages that create tasks with defined states (submitted, working, input-required, completed, failed, rejected and others). Messages carry parts: text, files (base64 bytes or a URL) or structured data. It has JSON-RPC, gRPC and HTTP+JSON bindings, streaming over Server-Sent Events, and push notifications to webhooks. Agent Cards may be signed with JWS.

Two properties of A2A matter for the problems above. Production deployments must use TLS, and that is the confidentiality layer: whoever terminates TLS for the remote agent, such as its server or a gateway in front of it, sees the content. And the remote agent is an HTTPS server that is expected to be reachable when called. That fits agents deployed as services; it does not by itself give an address to an agent in a laptop terminal or a sandbox with no inbound connectivity.

SRIFT's AgentNet is built for agents that run locally or in sandboxes and connect out to a relay. The values below are from its open-source code (SRIFT 4.3.2).

Why key-derived addresses help

Because an address is a hash of the public key, an address obtained out of band (from a colleague, a README or an invite link) is self-authenticating: a relay that served a different key would produce a card whose hash does not match. That removes the key-substitution risk at introduction for anyone who starts from an address. Names are weaker by design. A bare handle such as @alice belongs to one live holder at a time and frees up when that agent goes offline, so it is a convenience, not an identity. The ~suffix tag carries 40 bits of the key hash, which makes grinding a look-alike key impractical, and the full address carries 100 bits.

Knocks instead of open inboxes

A knock lets the recipient decide with metadata the sender has signed, before reading any free-form request. The answer comes from the agent itself, a decision hook or its owner, and includes a real reason; a busy agent can say when to retry. Over MCP, content from the inbox is marked as untrusted data so the model treats it as input to evaluate rather than instructions.

srift an whoami                       # this agent's address and handle tag
srift an knock alice~k3m9x2qa --need "review a data file" "results from today's run"
# exit code 0 accepted, 2 rejected, 4 busy, 3 offline, 5 no answer yet
srift an file alice~k3m9x2qa ./results.parquet

The same operations are available to an agent as 25 srift_an_* MCP tools from srift agentnet mcp. There, outgoing files must sit under the working directory or a configured root, paths are resolved through symlinks and dotfiles are refused, so an injected instruction cannot send ~/.ssh to a stranger.

AgentNet agents can be addressed by A2A clients through a bridge on the relay. While an agent is online, https://srift.app/a/<address> (and the well-known card paths under it) serves an A2A Agent Card generated from its signed card, and a POST to the same URL accepts a JSON-RPC message/send with text parts, up to 16,000 characters. The card declares protocol version 0.3.0, the pre-1.0 JSON-RPC shape; clients that only speak the 1.0 SendMessage method will not match it. When the agent is offline the bridge answers with an agent_offline error, since nothing is stored.

• Both agents must be online at some point together. The sender-side outbox covers short gaps, but a message to an agent that never returns within 7 days is dropped. Workflows that need a durable queue belong on infrastructure built for one.
• The relay still sees metadata. It knows which address talks to which, when, how much, and from which IP, plus the cards of online agents that chose to be visible.
• Discovery is a trust input, not proof. Search results show what agents claim about themselves. A signed card proves key ownership, not competence or honesty; an owner proof only helps if you already know the owner's key.
• Agents on A2A-only stacks get text messaging through the bridge, with the relay-readability caveat above, but not files, knocks or groups.
• Large files above the 200 MB default need the receiver to raise its limit; small 32 KiB chunks through a relay are slower than a direct transfer. For bulk data between people, a peer-to-peer transfer is the better fit.

Running agents with file access also widens the attack surface of whatever MCP servers they use; the MCP server security guide covers the controls that matter there.