Connecting Agents with Cryptography
I think we’re heading toward a world where everyone has an agent working with a lot of private information: calendars, messages, company documents, customer data, and code. Much of that work will happen in the cloud, where your agent can keep going while you’re doing something else.
I’m curious how those agents will start forming groups or swarms. Your agent might run on your laptop, mine in a cloud service, and another inside a company’s network. How do they discover that they’re working on the same problem? And how much should they have to share before they know it’s worth talking?
There are a handful of techniques for letting people compute something together without sharing the underlying information. These ideas have been part of Ethereum and cryptography research for years, and I think agents give us some interesting reasons to use them.
One technique is secure multiparty computation (MPC). A common approach splits private inputs into random-looking pieces and distributes them among participants. They follow a protocol to calculate an answer without any one participant having enough pieces to reconstruct the others’ inputs.
Another is fully homomorphic encryption (FHE), which lets a cloud service calculate directly on encrypted inputs without reading them or the answer. That takes much more time and compute than an ordinary calculation, so I’d start with simple checks.
You could also use a trusted execution environment (TEE), where protected hardware runs the calculation while keeping the data from the cloud operator. That requires trusting the hardware and its manufacturer. I’m especially interested in what we can do with the cryptographic approaches, where the inputs can stay private even from the hardware doing the work.
Why would agents want to cooperate?
Here are a few things I’d want my agent to help me with.
Say my girlfriend and I want to have dinner with a few friends, but nobody gets around to starting the group chat. We could each tell our agents who we'd like to see and let them check for mutual interest and a free evening. We'd get a suggestion without sharing the rest of our calendars or everyone else we'd like to see.
If a colleague and I wanted to know whether we were paid roughly the same for similar work, our agents could check whether our annual base salaries were within $10,000 of each other. We'd both get a yes or no without exchanging exact salaries. That might be enough to start a conversation about pay.
Suppose I upgrade a library and my app's AI responses start cutting off halfway through, with ERR_STREAM_CLOSED in the logs. Another developer's agent might already have a fix. Through a shared directory, our agents could find each other and privately check for a matching library, version, and error code. If we both agreed, they could introduce us without sharing our logs or repositories.
Dinner bot My girlfriend and I want to see our friends more often. Check whether anyone on our dinner list also wants to get together, and find an evening we're all free.
- Checking mutual interest
- Comparing free calendar times
Two friends on your list also want to get dinner with you both. All four of you are free Saturday evening. Should I start a group chat to make a plan?
Pay bot My colleague and I both agreed to compare our annual base salaries. Can you check if they're within $10,000 of each other, without revealing the exact amounts?
- Confirming both approvals
- Comparing encrypted salaries
Yes, your annual base salaries are within $10,000 of each other. The comparison revealed only that answer, not either salary. Should I ask your colleague if they'd like to talk about pay?
Code bot Since the library upgrade, responses keep cutting off with ERR_STREAM_CLOSED. Can you find someone who's solved this? Keep my code and logs private.
- Searching for other developers
- Privately matching versions and errors
I found a developer with the same ERR_STREAM_CLOSED error on the same library version. Their agent says they have a fix and are open to an introduction. Your code and logs haven't been shared. Should I connect you?
In each case, the agents could answer a narrow question before we decide whether to share more. The salary comparison is a simple way to see how that could work.
How the private calculation works
For the walkthrough, suppose you earn $150,000 a year and your colleague earns $155,000. You agree to compare annual base pay in the same currency and ask whether the difference is at most $10,000:
def salaries_are_close(your_salary, their_salary):
return abs(your_salary - their_salary) <= 10_000
print(salaries_are_close(150_000, 155_000)) # TrueOrdinary Python exposes both salaries to the computer running it. With MPC, the agents instead calculate the gap and compare it to the threshold using shares of the inputs, revealing only the yes or no.
With FHE, a compiler translates the subtraction, absolute value, and comparison into operations on encrypted numbers. The server knows the question and the $10,000 threshold, but the $5,000 gap and the final answer stay encrypted throughout.
The two techniques can also work together. In this design, the participants use MPC to create a shared public key for encrypting their salaries, while each keeps a share of the secret key. The cloud receives encrypted salaries and evaluation keys for doing the calculation, but no key that can decrypt them. Both agents must cooperate to decrypt the answer.
Before decrypting the result, both agents need to check that the server answered the question they approved: are the salaries within $10,000? The server could return a cryptographic proof tying the encrypted result to that calculation. Each agent would verify it before helping decrypt the result. That prevents the server from slipping in a different calculation, such as returning one person’s exact salary.
Whichever method you use, the answer reveals something. Knowing your own $150,000 salary, a yes tells you the other salary is between $140,000 and $160,000. Repeated questions could narrow that range, so both people need to authorize the comparison and the software needs to limit follow-up queries.
I enjoyed how 0xPARC put these ideas together in Programmable Cryptography: Four Easy Pieces. I’d recommend it if you want to get into the math behind MPC and FHE.
Who pays for shared computation?
Vitalik’s essay on crypto and AI points out how expensive cryptographic computation can be. Running these checks costs something, so it makes sense for agents to pay a service to do them. If a service could offer a small encrypted comparison for a tenth of a cent, an agent could pay through MPP each time it wanted to check a possible collaboration.
Those payments could add up quickly. A million agents each paying for one check every ten minutes would already generate roughly 1,700 payments per second. That’s the kind of demand that makes a fast, low-cost stablecoin network like Tempo useful. Agents in different clouds could pay through the same network, within budgets set by their owners, without their providers first building billing integrations.
If that grew to millions of payments per second, techniques like state channels would become interesting: agents could exchange payment updates offchain and settle the total later. That would start to look like what we built with Web3Torrent, where peers paid each other tiny amounts for each piece of a file. Here, they might pay for each private calculation or useful answer.
I’m excited to see what happens when agents can find collaborators as easily as they find information today. They could form a group around a problem, share only what’s needed, and pay each other to help solve it.