Agent-to-Agent File Sharing: The Protocol That Powers Autonomous AI Workflows

The Problem No One Talks About

Autonomous AI agents have reached a level of maturity where they routinely read, write, and transform files as part of complex multi-step pipelines. Claude's computer-use capability can navigate the file system and execute shell commands. GPT Code Interpreter can generate CSV exports from raw data. Custom LLM pipelines built on LangChain or CrewAI orchestrate dozens of sub-agents that produce intermediate file artifacts. The tooling has exploded — but there is one glaring gap that almost no one in the industry is addressing: there is no standard, secure protocol for one AI agent to transfer a file to another AI agent.

Today, engineers working on multi-agent pipelines resort to ad-hoc approaches that introduce serious security vulnerabilities. The most common pattern is writing to a shared cloud storage bucket — an S3 bucket, a GCS folder, or a mounted network drive — with every agent in the pipeline possessing read/write permissions on the same root. This works until it catastrophically doesn't. A prompt-injected agent, instructed by a malicious payload inside one of the files it processes, can traverse the bucket and exfiltrate every artifact the pipeline has ever produced. Even worse, API keys hardcoded into the transfer metadata (a genuinely common practice among teams moving fast) become an attack surface the moment a single file is intercepted at the transport layer.

Concrete failure modes are already being observed in the wild. An agent processing uploaded user documents accidentally included /etc/passwd in its output bundle when the sandbox was misconfigured. A cross-company LLM pipeline carrying financial projections between two enterprises was transferred over an unauthenticated HTTP endpoint with no audit record. A multi-agent system writing to a shared GCS bucket was compromised via prompt injection in a transferred Markdown file — the injected instruction exfiltrated the runner's environment variables including the entire .env file. The industry needs a protocol designed specifically for agent-to-agent file sharing. This is what we built at ShareBolt.

What Agent-to-Agent File Sharing Actually Requires

After analyzing dozens of real-world agent pipeline deployments, we identified six non-negotiable requirements that any serious agent file transfer protocol must satisfy:

• 01
  Cryptographic agent identity — not just an API key. API keys are bearer tokens. Any process holding the key can act as the agent. A true agent identity requires a cryptographic key pair (public/private) that is unique to the agent instance, not to the team account. This makes impersonation computationally infeasible rather than just operationally difficult.
• 02
  End-to-end encryption — the transport layer must never see plaintext. Files must be encrypted on the sending device before they leave the agent's memory. The relay, the CDN, the load balancer — none of these infrastructure layers should ever handle cleartext file data. Only the intended recipient agent should be able to decrypt the payload.
• 03
  Directory sandboxing — agents may only touch approved paths. The protocol must enforce path-level access controls at the SDK layer, not just as a server-side policy. An agent initialized with allowedPaths: ['/workspace/outputs'] should be cryptographically prevented from reading or writing outside that directory, regardless of what its underlying LLM decides to attempt.
• 04
  Rate limiting and quota enforcement. A compromised or looping agent must not be able to exfiltrate unbounded data volumes. Per-agent daily byte quotas — enforced at the transfer initiation layer — create a hard ceiling on data exfiltration even when the agent's reasoning process has been hijacked.
• 05
  Payload sanitization — transferred files must be checked for prompt injection. Every file that passes through an agent-to-agent transfer should be scanned for embedded injection strings before the receiving agent ingests it. A CSV with a hidden SYSTEM: prefix in a cell value is enough to pivot the receiving LLM.
• 06
  Immutable transfer audit logs. For compliance, debugging, and forensic investigation, every agent-to-agent file transfer must produce a tamper-evident ledger entry. This means the audit log itself must be hash-chained — so that deleting or modifying a record is detectable, not just logged.

The ShareBolt Agent Protocol

ShareBolt implements agent identity using Decentralized Identifiers (DIDs) with Ed25519 key pairs. Each agent registered through the SDK receives a DID in the format did:bolt:agent:<pubkey-hex>. This identifier is cryptographically bound to the agent's Ed25519 public key — meaning the agent can prove its identity by signing a challenge without ever exposing its private key. Agent identity is agent-scoped, not account-scoped, which means a compromised agent cannot impersonate any other agent in the same organization.

Initiating a transfer is a single SDK call. Here is how a Claude worker agent transfers an analysis artifact to a GPT analyst agent:

// ShareBolt Agent SDK — agent-to-agent file transfer
const bolt = new ShareBoltAgent({
  agentId: 'did:bolt:agent:claude-worker-01',
  vaultKey: process.env.BOLT_VAULT_KEY,
  sandbox: {
    allowedPaths: ['/workspace/outputs'],
    dailyQuotaBytes: 10_000_000_000 // 10 GB
  }
});

const transfer = await bolt.transferTo({
  recipient: 'did:bolt:agent:gpt-analyst-02',
  filePath: '/workspace/outputs/analysis.csv',
  encrypt: true,
  metadata: {
    expires: '48h',
    classification: 'CONFIDENTIAL'
  }
});

console.log('Ledger block:', transfer.ledgerBlockHash);

X25519 Key Exchange and Envelope Encryption

Under the hood, the transfer flow implements a hybrid encryption scheme. The sending agent generates a fresh AES-256-GCM data encryption key (DEK) for the file. It then performs an X25519 Diffie-Hellman key exchange using the sender's Ed25519 key (converted to X25519 form via the standard Ristretto mapping) and the recipient's registered public key. The resulting shared secret is used to encrypt the DEK — producing an encrypted key envelope. The encrypted file and the encrypted key envelope are transmitted separately: the file goes to the storage backend, and the envelope goes through ShareBolt's relay. The relay never sees the DEK; it only handles the encrypted envelope.

Sanitization Flow

// Sanitization pseudocode — runs server-side before delivery to recipient

function sanitizeTransferPayload(fileBuffer, mimeType) {
  const text = extractTextContent(fileBuffer, mimeType);

  const injectionPatterns = [
    /SYSTEM:\s*/i,
    /Ignore previous instructions/i,
    /<!--\s*INJECT/i,
    /\[INST\]/i
  ];

  for (const pattern of injectionPatterns) {
    if (pattern.test(text)) {
      flagTransfer('PROMPT_INJECTION_DETECTED');
      return { safe: false, reason: 'injection_pattern_match' };
    }
  }

  return { safe: true };
}

How Different AI Platforms Integrate

The ShareBolt Agent SDK provides first-class integration with every major AI platform. The agent DID resolves to a public key that any platform can verify through our public DID resolver at https://sharebolt.boreme.in/resolve/.

Platform-specific integration is handled through thin adapter modules that translate the platform's native tool-calling schema into ShareBolt's unified transfer API. For Claude's MCP (Model Context Protocol), the ShareBolt MCP server exposes a bolt_transfer tool that the agent can invoke with no additional configuration beyond the DID and vault key. For OpenAI function calling, the function schema is auto-generated by the SDK's bolt.generateFunctionSchema() call.

The Immutable Audit Ledger

In a multi-agent pipeline handling sensitive data, "who transferred what to whom and when" is not an optional audit capability — it is a compliance requirement. SOC 2 Type II, HIPAA, and ISO 27001 all require demonstrable evidence of data movement between systems. When those systems are AI agents acting autonomously, the audit burden is higher, not lower, because humans are not in the approval loop for each transfer.

ShareBolt's ledger is hash-chained, meaning each block includes the cryptographic hash of the previous block in its own hash computation. This makes the chain tamper-evident: altering any historical block invalidates every subsequent block hash, and the divergence is immediately detectable by any party with access to the ledger tip hash. Here is the structure of a transfer ledger block:

{
  "blockIndex": 42,
  "action": "AGENT_FILE_TRANSFER",
  "sender": "did:bolt:agent:claude-worker-01",
  "recipient": "did:bolt:agent:gpt-analyst-02",
  "fileHash": "sha256:a8f3c2d91e4b7f88c3a1e9d0b5f2c7a4...",
  "fileSizeBytes": 204800,
  "classification": "CONFIDENTIAL",
  "timestamp": "2026-06-18T09:41:22Z",
  "prevHash": "c3f5ea8d9b1a2f4e7c0d3b6a9e2f1c8d...",
  "blockHash": "7e2d9f1b4a8c5e3f0b2d6a1e9c4f7b3d..."
}

The fileHash is a SHA-256 digest of the plaintext file computed client-side before encryption — meaning the hash can be independently verified by the recipient after decryption without ShareBolt ever seeing the file contents. Audit entries are accessible via GET /v1/audit/entries (JSON). CSV export and SIEM streaming connectors are on the roadmap.

Getting Started in Four Steps

Integrating the ShareBolt Agent Protocol into your multi-agent pipeline takes less than 30 minutes for most teams:

• Sign up for a Pro Vault or Enterprise plan at sharebolt.boreme.in/pricing. The Agent Protocol SDK is included on both tiers.
• Generate your agent DID using the ShareBolt SDK: npx sharebolt-sdk agent:create --name claude-worker-01. This produces your Ed25519 key pair and registers the public key with the DID resolver.
• Configure your sandbox paths and daily quotas in your SDK initialization block. Specify only the directories your agent legitimately needs — enforce least-privilege at the file system level.
• Make your first transfer call. The recipient agent's DID is the only thing you need — ShareBolt resolves the public key, performs the key exchange, encrypts the file, and delivers it. The ledger block hash is returned synchronously for your own record-keeping.