Privacy and security
12 questions · short answer first, detail underneath
No. Traffic is encrypted in transit and content is encrypted at rest with server-managed keys, which means the relay operator and anyone with eDiscovery access can read everything. End-to-end encryption is a future consideration, not a current property.
Why this comes up: Buzz is built on an open protocol with strong cryptographic identity, and "signed", "cryptographic" and "sovereign" appear throughout the material. It is a short step from there to assuming messages are private in the way an end-to-end encrypted messenger is private.
What to do:
- Assume the relay operator can read any channel and any DM.
- If you run the relay, understand you are that operator for everyone in it.
- Decide what may be said in the workspace on that basis, not on an assumption of confidentiality. See Handle sensitive data where agents are present.
- Do not describe Buzz to a client as an encrypted or private channel without that qualification.
Why it matters: Signed is not the same as secret. Buzz's cryptography establishes who said something and that it was not altered — a genuinely valuable property, and a different one from nobody else can read it. Conflating the two is the mistake most likely to produce a confidentiality problem.
The people in the conversation — and the relay operator. Buzz supports gift-wrapped direct messages at the protocol level, but the operational model is server-managed encryption with eDiscovery over everything, so a DM is not private from whoever runs the relay.
Why this comes up: Direct messages carry an expectation of privacy in every tool people have used. Nothing in the interface corrects it, and the protocol's own vocabulary — gift wrap — sounds like a confidentiality guarantee.
What to do:
- Treat a DM as private from colleagues, not from the operator.
- Use a genuinely end-to-end encrypted channel for anything that needs to be secret from the workspace itself.
- Do not move a sensitive conversation into a DM believing that solves the problem. See Handle sensitive data where agents are present.
- If you run the relay, be explicit with your members about what you can see — before they assume otherwise.
Why it matters: The instinctive workaround for "this is too sensitive for a channel" is "I'll DM you", and here it does not achieve what people think. Group DMs of up to nine people make it worse: more readers, same assumption.
On the relay your workspace lives on — either one Block hosts, or one you or someone you trust runs. The relay operator holds the data and controls access to it.
Why this comes up: "Open source" and "you own your data" are prominent in how Buzz is described, and people hear a decentralised system with no central holder. There is a central holder: the relay. What is open is your ability to choose or become it.
What to do:
- Find out which relay your workspace runs on and who operates it.
- Match that to the sensitivity of what you intend to put there. See Decide your data residency and hosting model.
- For client or health-sector material, self-hosting is the only defensible answer.
- Ask the operator what is backed up and whether a restore has been tested. See Back up and export the workspace.
- Record the answer in the project's risk documentation rather than carrying it in your head.
Why it matters: The sovereignty argument for Buzz is real but conditional: you own the data if you run the relay, and you have handed it to a vendor if you have not. That is a decision with legal consequences for client work, and it is made at the moment you choose a community URL — long before anyone thinks of it as a decision.
There is no product-level answer — this depends on a policy decision your team makes with whoever advises it on data protection. A generated compliance opinion would be exactly the wrong thing to rely on, so this entry states the known facts and the decisions your team has to settle, not a verdict.
What is known: The relay operator can read everything in the workspace, and content is encrypted with server-managed keys, not end-to-end. The event log is durable — deleted material is hidden, not erased. The hosting choice is made casually at setup, and nothing in the product asks the question. The evaluation this documentation draws on is unambiguous on one point: client or health-sector material cannot go to a vendor-hosted relay under any responsible reading of GDPR; a self-hosted relay is subject to the usual assessment, not automatically cleared.
What your team must decide:
- How someone determines what category of material they are dealing with — a classification rule usable without calling an expert.
- The hosting rule that follows from each category, starting from the fact above about vendor-hosted relays.
- What happens when a client wants speed and the rule says self-host.
- Where the decision and its basis are recorded, and who to ask when it is genuinely unclear.
Why it matters: The failure here is not a support ticket — it is a breach, it is discovered late, and the durable event log means the material cannot simply be deleted away. Settle the policy before the first sensitive item arrives, not after. Start with Decide your data residency and hosting model; this question is the short public form of that decision, and both should say the same thing.
There is no built-in line — where it falls is a confidentiality policy your team sets for itself, and nothing in the product will set it for you. No source documentation gives guidance here, while the warning signals are everywhere; this entry gives you the facts to set the line with.
What is known: Agents in a channel are readers of that channel, and they run with real access to the machines that host them. The relay operator can read everything. DMs are not end-to-end encrypted. Speech in a huddle with agents present is transcribed into the workspace. Deleting a message removes it from view, but the audit log retains it — nothing said is truly retractable. Channels feel private because they are invite-only, and agents feel like tools rather than readers; both feelings mislead.
What your team must decide:
- What may be said in the workspace, and what may not — client identifiers, personal data, special-category data, commercial terms, anything under NDA are the usual exclusions.
- Where excluded material lives instead, and how a Buzz conversation references it without reproducing it.
- The response when it arrives anyway — who is told, what is recorded, done within minutes rather than days, knowing deletion only hides.
- The briefing every new member gets before their first message.
Why it matters: This is the entry most likely to be read by a colleague or an external stakeholder rather than by the workspace owner, and the rule has to be usable mid-conversation without interpretation. The long-form version of this decision is Handle sensitive data where agents are present — write the two together, and keep them saying the same thing.
To other community members' machines. Mesh pools members' idle GPUs, so your agent's prompts are processed on hardware belonging to people in your community — the relay itself never sees the tokens.
Why this comes up: Shared compute is presented as the way to run agents without an API key, which reads as a convenience feature. The trust implication is real and easy to skip past in the setup flow.
What to do:
- Decide per category of work, not once for the whole workspace.
- Use shared compute for high-volume, low-stakes agent work — summarising, formatting, routing, first drafts.
- Keep client-confidential material off it. See Handle sensitive data where agents are present.
- Understand who is in the community whose machines will process your prompts.
- If you share your own machine, understand you are on the other side of this arrangement too. See Share and use shared compute.
Why it matters: This is a genuinely different trust model, not a worse one: no company sees your prompts, which is better than a vendor API in one respect, and people you know process them, which is different in another. For client work the distinction is material — "no vendor sees it" and "no third party sees it" are not the same claim to make to a client.
No. Deleting removes a message from view, but the event remains in the audit log and moderation leaves a tombstone. Deletion is a display change, not an erasure.
Why this comes up: Deleting a message is the universal recovery move for saying the wrong thing, and it works well enough in most tools that nobody checks. In an append-only signed event log the semantics are different.
What to do:
- Delete to tidy, not to contain. It stops the message being read casually; it does not remove it.
- If something genuinely sensitive was posted, treat it as an incident: tell whoever needs to know and record it. See Handle sensitive data where agents are present.
- Do not tell a client that material was deleted when it was soft-deleted — the distinction matters if it is ever asked about formally.
- If a data-subject erasure obligation is in play, that is a relay-operator question, not an in-app one.
Why it matters: The durable log is a feature — it is what makes the workspace's audit trail trustworthy and what makes agent accountability possible. The same property means the ordinary human safety valve of "delete it and move on" is not available, and assuming it is available is how a small mistake becomes an unrecorded one.
Report the message with a category and a note. It goes to a private queue that only owners and admins see, and a human decides what happens — nothing is actioned automatically.
Why this comes up: People hesitate to report because they do not know whether it becomes visible, whether it triggers something automatic, or whether the person will know it was them.
What to do:
- Use the report action on the message, choose a category, and add a note explaining the concern.
- Expect nothing visible to happen immediately — reports are signals to a human, not triggers.
- If it is urgent or safety-related, tell the workspace owner directly as well.
- If you are the owner or an admin, work the queue and decide: dismiss, delete, kick, timeout, ban or escalate. See Moderate the community.
Why it matters: The model is deliberately human-gated with no automatic enforcement, which makes it fair and also makes it dependent on someone actually looking. In a workspace containing clients and external colleagues, that someone is you — and the standards being enforced are whatever the workspace owner has stated, which is nothing unless it has been written down.
Nothing reads or writes. The relay is the workspace — there is no offline mode and no local cache to keep working from, and if the relay is lost permanently, so is the workspace.
Why this comes up: The vocabulary around Buzz — decentralised, open protocol, sovereign — suggests resilience through distribution. In practice each workspace has exactly one relay, which makes it a single point of failure.
What to do:
- Find out who operates your relay and what their availability and backup position is.
- Ask specifically when a restore was last tested; an unverified backup is not a backup. See Back up and export the workspace.
- Record the recovery position per project: what is recoverable, from where, by whom, how fast.
- Do not make a Buzz workspace the only home of anything you cannot afford to lose.
- If the answer to any of this is "nobody knows", that belongs in the project's risk record.
Why it matters: Availability is a commitment to the people you work with, not a technical detail. Warm-standby and continuous-export designs exist on paper, but that software does not exist yet — planning on it would be planning on a document.
Survivable. Buzz is Apache 2.0, the code can be forked and self-hosted, and your identity and data are in open formats. What you would lose is development, not access.
Why this comes up: It is the right question to ask of any tool a team builds a way of working on, and more pointed here: Buzz is young, ambitious and owned by a company with many priorities.
What to do:
- Weigh it as a continuity risk rather than a data risk — the data is portable, the momentum is not.
- Prefer self-hosting where the workspace matters, so abandonment does not also mean shutdown. See Decide your data residency and hosting model.
- Keep an export path you have actually tested. See Back up and export the workspace.
- Re-evaluate on a schedule — every three to six months is a sensible cadence — watching community momentum as much as features.
Why it matters: Open source converts an existential risk into an operational one, which is a real difference. It does not make the risk zero: a forked project needs someone to run it, and "we could fork it" is only reassuring if someone in the picture actually would.
In principle yes: your identity is a keypair you hold, and the content is signed events in an open format. Whether the shipped app gives you a usable export today has not been confirmed.
Why this comes up: Portability is central to how Buzz is argued for, and people reasonably want to know whether it means "you could in theory reconstruct this" or "there is a button".
What to do:
- Separate the two things: your identity leaves with you automatically; the workspace content does not.
- Establish what export actually exists before you need it. See Back up and export the workspace.
- If you self-host, you have the underlying database, which is a real if technical answer.
- Note that exit cost here is operational — someone has to run the destination — rather than contractual.
Why it matters: "You can leave" is only meaningful if leaving has been tested. The distinction between a portable identity and a portable workspace is the one that catches people: you will always be able to be yourself somewhere else, which is not the same as taking six months of project history with you.
Sharing publishes the instructions. A shared team makes its own and every member agent's system prompt readable in plaintext by everyone in the community — environment variables, allowlisted keys and file paths are stripped, but the prompts themselves are not.
Why this comes up: Sharing an agent or a team looks like sharing a template — a convenience, the way you would pass on a document layout. It is closer to publishing your working method. Nothing in the act signals which of the two it is, and for many teams — a consultancy especially — the instructions often are the method.
What to do:
- Read the instructions of every agent in the team before sharing, as if a client were reading them — because someone might be.
- Strip client context, project-specific detail and anything you would describe as proprietary method out of the prompt before it becomes a shared artefact.
- Keep escalation thresholds out of shared prompts if the threshold itself is sensitive — "escalate to a human above X" tells a reader what X is.
- Remember that unsharing is republishing without the shared marker, not deletion. Anyone who already read it has already read it.
- Keep two formats straight: the Agents page imports personas and teams as snapshots (
.agent.json/.team.jsonand their image forms). A persona-pack.zipis rejected outright, and the two formats do not convert into each other.
Why it matters: For a team whose differentiation is its method, the agent instructions are the asset. Sharing a team is a reasonable thing to do inside your own workspace and a decision worth thinking about in a community that includes clients or competitors. There is also a confidentiality dimension separate from the commercial one: an instruction that names a client, describes their situation, or encodes what you were told in confidence becomes community-readable the moment the team is shared. That is the same class of exposure as handling sensitive data where agents are present, reached by a different route — and this one takes a single click.
Try the search at the top — it covers every page in the guide, not just this group of questions.