How can multiple AI agents share an encrypted private space without a central trust broker?

Two AI agents — or an agent and a human, or three agents on different infrastructure — need to share state. A shared memory, a coordination channel, a private context none of them wants routed through a third party's server. The obvious answer is "put a trusted broker in the middle to manage access." The actual answer is: you don't need one, if you treat audience membership as math instead of policy.

The wrong model, stated plainly

A central trust broker does two jobs at once: it stores the shared data, and it decides who's allowed to read it. Collapsing those into one party means that party can revoke, alter, or leak the shared context unilaterally — and none of the agents relying on it have an independent way to check, because checking requires going through the same party being checked. For agent-to-agent coordination specifically, this also means the broker becomes a single point of failure for the whole multi-agent system, not just an inconvenience.

What actually has to be true instead
Audience membership — who can decrypt the shared space — has to be a cryptographic set, not a permission a server grants. Two constructions cover the real cases:

Union — any one agent in the set can decrypt independently:

S ← random(32)
∀ agent Kᵢ ∈ A:  Wᵢ = wrapSecretV1(P256_pub(Kᵢ), S)
publish { ciphertext, wraps: [(identityHash(Kᵢ), Wᵢ)] }

Intersection — all agents in the set must cooperate; no partial decryption:

S₁, ..., Sₙ₋₁ ← random(32) each
Sₙ = S ⊕ S₁ ⊕ ... ⊕ Sₙ₋₁
∀ agent Kᵢ ∈ A:  Wᵢ = wrapSecretV1(P256_pub(Kᵢ), Sᵢ)

Neither construction requires a party in the middle to decide anything at read time. The ciphertext can sit on any storage, run by any host, and none of that changes who can open it.

The honest gap

This isn't magic, and the part worth being precise about: wrapSecretV1 needs each agent's public key before anything can be wrapped for them. Deciding "this key really belongs to that agent" is a real, separate problem — key discovery and identity binding — and it's tempting to assume some piece of existing infrastructure already solves it invisibly. Worth checking directly rather than assuming. In more than one real system, the "obvious" discovery surface turns out to publish a different kind of key, for a different purpose, than the one this actually needs — which quietly reintroduces exactly the kind of central dependency this whole approach is trying to remove, just one layer up.

So the precise claim is: once each agent's public key is genuinely known, no central broker is needed to grant, enforce, or mediate read access — that part is real, implemented, and source-verified. Getting to "genuinely known" still needs an explicit answer, not a hand-wave.

Where this is implemented, source-verified
Full mechanism — kernel identity, the union/intersection constructions, and what backward secrecy actually costs when a member leaves:

Cryptographic Set-Chemistry on Audiences →

The closing formal statement — an Island whose audience is a composable set expression, so privacy is a property of derivation, not of whichever party is currently custodian of the bytes:

Encrypted Semantic Island →

![The same thing can mean different things depending on who is looking at it and where they are.

](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/tzvpq5msx03rhyxks03o.jpg)

Run this Demo to see .me in action:
Robots That Understand Context