Privacy policy

Who we are

PeerBand (peerband.com) is run by Kirill Shvidler, an independent developer, who is the controller of the personal data described here. Questions and requests go through the PeerBand issue tracker on GitHub. Don’t post personal details there: open an issue saying you have a privacy request, and you’ll get a private way to continue. Security problems should be reported privately with GitHub’s “Report a vulnerability” form on the peerband-cli repository.

What we collect and why

Your account

You sign in with Clerk, which handles your Google sign-in. We receive your account ID and, when Clerk has verified it, your email address. We use them to tell which machines, clients and webhooks are yours, and to show your email to people you share a machine with.

Machines and sign-in

For each paired machine we store its name, ID, creation time, a hash of its credential, whether it is revoked, and the owner’s account and email. Pairing grants are stored as hashes with an expiry. Browser sign-in (peerband login) stores hashes of the sign-in codes, the CLI name and version, the machine name, the platform, a coarse network (the first three parts of an IPv4 address, or the first 48 bits of an IPv6 address), the request status and times, and the account that approved it. The CLI keeps its machine credential on your computer, in credentials.json, readable only by your user account.

Connected clients

When you connect an MCP client with OAuth, we store the grant: your account, the client’s ID and name, the scopes you approved, and when it was created or revoked. OAuth state and token mappings are kept in an encrypted store. Personal MCP tokens are stored as hashes.

Requests to your agents

When a client calls a tool, PeerBand routes the request to your machine and the answer back. Messages to agents and agent output pass through the service’s memory while a request is handled; they are not written to our database. The connector on your machine keeps receipts (request and agent IDs, times, delivery state and error codes, never the message text) so it can answer get_request_status. Status events carry metadata only: an agent’s status, label and workspace, never its output.

Sharing

When you share a machine, we store invite links as hashes, who created and accepted them, the guest’s account and email, and their access level. The owner can see a log of what each guest read or sent (tool, agent, outcome and time, never the content).

Notes and webhooks

Notes sent with peerband notify are delivered to the owner’s dashboard and webhooks. For webhooks we store the name, format, filters, an encrypted copy of the URL and signing secret, and delivery records (status, HTTP code, timing, attempts). A webhook payload contains event metadata and note text, and is kept only until it is delivered or out of retries. MCP Events subscriptions store the callback URL and secret encrypted.

Analytics and diagnostics

We use PostHog, in its EU cloud, to understand how the site and service are used and to find errors:

• Website: anonymous page views, page leaves and clicks, and a few named events (an install command was copied, the dashboard or a device approval page was viewed, a device was approved or denied). It runs cookieless: no cookies or storage identifiers are set, element text is masked, query strings on the device and dashboard pages are removed, and Do Not Track is respected. Session recording is off, and website visitors are not linked to accounts.
• Performance and errors: click positions and scroll depth for heatmaps, rage and dead clicks, Core Web Vitals, and browser or rendering errors, with sign-in codes and device-page query strings removed.
• Backend: operational logs with tokens, grants and codes redacted; each HTTP request by method, route pattern, status and duration; unexpected errors with a redacted message; and aggregate metrics without user or machine identifiers.
• MCP tool calls: the tool name, duration, error type, argument names (not values), response size and the client’s name and version, linked to your account ID so usage can be counted per account.

Agent output, messages to agents, tool argument values and credentials are never sent to PostHog.

Legal bases

Where data protection law such as the UK or EU GDPR applies, we rely on:

• Performing our agreement with you for your account, machines, clients, sharing, notes, webhooks and relaying requests: without them the service can’t work.
• Legitimate interests for security, abuse prevention, diagnostics and privacy-friendly analytics, which we keep cookieless and free of message content.

How long we keep it

• Account, machine, client grant, sharing and webhook records: while they are active. Revoked records may be kept as long as your account exists, so access stays auditable.
• Browser sign-in records: deleted a day after the code expires.
• Guest activity: 30 days.
• Webhook delivery records: 7 days. Payloads are dropped once delivered or out of retries (about 27 hours at most).
• Analytics and logs in PostHog: according to PostHog’s retention for our project.
• Receipts on your machine: kept by the connector on your computer, under your control.

Who processes it

• Clerk: sign-in and account identity.
• Amazon Web Services (Lightsail): hosting for the website, relay and database.
• Cloudflare: DNS, and network traffic if its proxy is enabled.
• PostHog (EU cloud): analytics, logs and error tracking.
• Google: when you choose Google sign-in, through Clerk.

Webhook destinations you configure, such as Slack or Discord, receive the events you choose under their own terms. Some providers may process data outside your country; where that happens we rely on their standard safeguards, such as standard contractual clauses. We don’t sell personal data or use it for advertising.

Your choices and rights

• Disconnect a client, remove a guest, delete a webhook or revoke a machine from the dashboard at any time.
• Make a machine read-only, or limit which agents it exposes, in connector.json.
• Stop the connector from the PeerBand Relay tab in Herdr. peerband logout deletes the local credential (revoke the machine in the dashboard as well).
• Block analytics with Do Not Track or a content blocker.

Depending on where you live, you may have the right to access, correct, delete or export your data, and to object to or restrict processing. To use them, or to delete your account, contact us as described above. You can also complain to your data protection authority, such as the UK Information Commissioner’s Office.

Don’t put passwords, keys or personal data in messages to agents or in notes: they pass through the service, and agent output can contain whatever your agents print.

Children and changes

PeerBand is a developer tool and isn’t meant for children under 16. If we change this policy, we’ll update the date above and, for significant changes, say so on the site.