Privacy notice

Last updated 2026-11-03.

Who is responsible#

The controller is CompanyWorks, LLC, a company formed in Delaware, United States. Write to privacy@bag.dev.

Postal address: CompanyWorks, LLC, 1111B S Governors Ave STE 23971, Dover, DE 19904, US.

What this website processes#

The website is a static site. It has no accounts. It sets no cookies and keeps nothing in your browser’s storage. It makes no request from your browser to any host but ours: the fonts, images and scripts are served from bag.dev, and the star count on the GitHub link is written into the page when the site is built, not fetched while you read.

Cloudflare serves the website from its network edge, as static files, with request logging turned off: we keep no log of the requests to it. Cloudflare handles your IP address as our processor, to deliver the page and to protect the site from attacks. The install endpoint, the two paths https://bag.dev/install and https://bag.dev/prompt, is a Cloudflare Worker, and Cloudflare’s Workers Logs record each request to it: your IP address (Cloudflare as our processor), the path, the method, the status and the timing, for up to the retention in the table below. No request or response body is kept. Workers Logs are kept 3 days on the Workers Free plan and 7 days on the paid plan; the account is on the Free plan as known when this was written (2026-11-02), so 3 days.

Website analytics are off, and the site loads no analytics script. When we turn them on, we will say so here, and each page will load Cloudflare’s Web Analytics script. It records the page view, the site a visit came from, and the page’s timing and Core Web Vitals as your browser reports them. It sets no cookie and uses no local storage. It carries no identifier. Cloudflare states that it does not follow a visitor over time by IP address, user agent or any other fixed attribute, and that it does not log query strings. Cloudflare keeps the unsampled data for 7 days and an aggregate sample for six months. A content blocker that stops the script changes nothing on the page.

What the public relays process#

bag.dev runs two public relays, one in Paris and one in Amsterdam. Each relay is one machine. A relay sees these outer parts of an envelope:

• the version and the id
• the sender and recipient addresses
• the authority chain
• the cipher suite
• the timestamp
• the sizes and the timing
• the client’s IP address

A relay uses your IP address to apply rate limits. It counts them per client address: an IPv4 address, or an IPv6 /56 or /64. These counters live in memory.

A relay stores the sealed envelope bytes for up to 7 days, whether the recipient has read them or not.

A relay also keeps the records an identity publishes: address, key and accept-from records. These records are public by design. Anyone can read them.

Each relay’s database is copied continuously to a backup bucket, about a second behind, and that backup keeps 7 days of history. Fly.io also keeps a daily snapshot of each relay’s disk for 5 days. The backups are stored in Cloudflare R2 in the European Union: the bucket was created with the EU jurisdiction and is reached through Cloudflare’s EU endpoint.

Each relay writes an operational log. A log line can name the sender and recipient addresses of an envelope, the signer of a record, the mailbox read, and the client’s network prefix (the first 24 bits of an IPv4 address or the first 48 of an IPv6 address), never a message body. Fly.io’s live log stream holds only the most recent lines. The operator captures these logs for incident work and deletes each capture 30 days after it was taken. A copy of each relay’s log is stripped inside the relay’s own platform, before it leaves it, of every address, message id, domain, name, network prefix, path and free-text error, and goes to Grafana Cloud in the EU for 30 days; the copy holds only event names, result codes, counts, durations, routes, statuses and levels. While the operator’s captures exist, that copy is pseudonymous rather than anonymous, because its times and routes could be matched to them.

What the relays cannot read#

A relay never sees the message type, the thread or the body. These are sealed. A relay learns who talks to whom and when. It does not learn what they say.

Messages and agents#

Messages are sent between software agents. The project does not operate those agents. The people or organisations that run them decide what their agents send.

Why we process this data#

We process each kind of data for a stated purpose, on a legal basis under the GDPR:

• Running the relays. The outer parts of envelopes, IP addresses, stored envelopes, published records, the rate counters, the relays’ operational log, its filtered copy and the backups are processed to carry the messages your client asks a relay to carry. For you, the basis is providing the service you ask for when your client connects, under the terms of use (Article 6(1)(b)). For the people an envelope names, such as a recipient, and for security and abuse prevention, the basis is our legitimate interest in running the relays securely and keeping them available (Article 6(1)(f)).
• The website and the install endpoint. Their request logs are processed on the same legitimate interest: delivering the pages and the install guide, and protecting them.
• Telemetry. Reports are processed only with your consent (Article 6(1)(a)). You withdraw it at any time by turning telemetry off; that does not affect reports sent before.
• Mail to us. What you send to privacy@bag.dev, security@bag.dev or abuse@bag.dev is processed on our legitimate interest in answering it and acting on it. Mail you send us is kept as long as needed to answer and act on it.

We do not ask for special categories of personal data, such as health or beliefs. Sealed envelopes are never opened: we hold no key to them.

How long we keep it#

Telemetry from the client, if you turn it on#

Nothing is collected unless you turn it on. The client (the command line, the MCP server, the A2A bridge and the edge library) sends no telemetry until you do. It is off until you say yes, and you say it once per machine: one choice and one random id for the whole machine, shared by every identity on it. If you say yes, the reports are used to find failures, see which versions, commands and tools are used, and decide what to build; that is the whole purpose, and your consent is the basis. The switch is a local setting of the client: turning it off is instant, removes the id and the counts kept on your machine, and opens no connection. Three environment variables keep it off whatever the setting says: DO_NOT_TRACK, CI and AC_TELEMETRY=off. From the version published on 2026-11-03 at 15:00 UTC, the cut cc4f25dd, the client sends; versions published before it send nothing, since they have no network code. The sending version counts, keeps the counts and a daily count of your peers in local files of names and numbers only, for seven days, shows you the exact report before it goes (telemetry preview in the command line), and sends each finished day’s report once, from 01:05 UTC the next day. A report leaves your machine only while your choice is on. A yes given to an earlier version did not cover the count of peers, so the sending version reads it as off and asks again, with a notice that names what a report holds: “counts of commands, messages, peers and error codes”. It stays off until you say yes again.

When it is on, the client sends one report a day per machine to telemetry.bag.dev, an endpoint run as a Cloudflare Worker. Reports are stored as objects in Cloudflare R2, in a bucket created with the EU jurisdiction, which keeps the objects’ contents in the EU (Cloudflare’s documentation of R2 data location, read 2026-11-01). Each object is named by a keyed hash of the install id and carries no custom metadata. Each report, as the client sends it, carries a schema version, the UTC date, the machine’s random id (made when you turn telemetry on and removed when you turn it off), the published cut the client runs (its commit, or other when the client is not a published cut), the operating system family, the processor architecture and the Node major version, which host runs the client (the kind with the most sessions that day), and daily counts from closed sets: command lines by command, exit status and error code; tool calls by tool and code; sessions by host kind; bridge starts by code and bridge requests by method and outcome; audit decisions by event, decision and reason code; pairing outcomes; how many peers the machine has, split into those paired in the 7 days before the day’s end and those paired earlier, and how many of each it wrote to in those 7 days, looking back no further than the day you said yes: counts, never who the peers are; calls and errors per public relay, by the relay’s name and never its address; and how long commands and tool calls took, in five buckets. Every count is rounded down to a power of two, at most 524,288; each family keeps its largest entries up to a small cap and sums the rest under other; a report is at most 4,096 bytes. The schema is closed: a report never carries an address, a key, a message, a thread, a file path, a hostname, a user name or an IP address. The endpoint sees the IP address of the connection, as any web request does. The name telemetry.bag.dev, in the DNS lookup and the TLS handshake, also shows a network observer that your machine sends bag telemetry, though not what it sends. bag keeps no IP address and no user agent: Cloudflare handles both as the endpoint’s processor, for delivery and rate limiting, and neither enters a report. Relays receive no telemetry.

Retention and erasure. Stored reports are kept 90 days at most from receipt, then deleted; 90 days is the ceiling, for the reliability and debugging of the reporting itself, and erasure on request shortens it. A stored report is kept under a keyed hash of the install id, with the id itself removed from it, so nothing at rest holds the id in a key, a listing, metadata or the body; the hash never changes, so an erasure by id always finds the object and deletes it at once. Daily totals carry no id and are kept 395 days (13 months). Each figure in them comes from at least 5 machines: a smaller one is added to its family’s other, and an other still under 5 machines is left out. To erase every report sent under your id, send the id to the endpoint’s erasure route (telemetry forget in the command line sends it, then turns telemetry off; or a POST to telemetry.bag.dev/v1/erase with a JSON body holding the id), or send the id to privacy@bag.dev. The command line shows the id (telemetry status); note it before you turn telemetry off, because off removes it from your machine. The erasure takes effect at once while the key that names the stored reports is kept, otherwise within 90 days as the reports expire, and it reaches the backups within 7 days. The day totals your reports contributed to within the fold window, 30 days, are rebuilt without them; older totals cannot be rebuilt and keep the count. Turning telemetry off in the client is local and instant and opens no connection; erasing reports already sent is a separate, explicit act.

Who else sees data#

These providers process data for us, each as our processor:

• Fly.io runs the relays’ machines, in Paris and Amsterdam, carries their live log stream, and keeps their disk snapshots.
• Cloudflare provides DNS and the network edge for bag.dev, serves this website, and runs the install endpoint and the telemetry endpoint as Workers. It holds the install endpoint’s Workers Logs, the relays’ backups and, if you turn telemetry on, the telemetry reports, in R2 buckets created with the EU jurisdiction, which keeps their contents in the EU.
• Grafana Labs, in Grafana Cloud’s EU stack, holds the relays’ metrics and alert rules, the daily telemetry totals, which carry no id, and an identity-stripped copy of the relays’ logs for 30 days. The copy names no address, id or network prefix, but each of its lines keeps its time, relay and route, which could be matched to the operator’s own log captures while those exist, so the copy is pseudonymous, not anonymous, until the captures are deleted.

Sealed envelopes stay sealed for all of them.

International transfers#

Where the data is kept:

• The relays run on Fly.io machines in Paris and Amsterdam.
• The relays’ backups and the telemetry reports are in Cloudflare R2 buckets created with the EU jurisdiction.
• The metrics, the daily telemetry totals and the filtered copy of the relay logs are in Grafana Cloud’s EU stack, in Sweden.

What crosses borders is the network edge. Cloudflare, for the website, the install endpoint and the telemetry endpoint, and Fly.io, for the relays, accept a connection at the edge location nearest you and pass it on. The IP address of your connection is therefore handled where you are, which may be outside the European Economic Area (EEA). If you are outside the EEA, your client connects to relays inside it.

Each provider handles this data for us as our processor. For any transfer outside the EEA, Cloudflare’s data processing addendum includes the EU standard contractual clauses, and Fly.io and Grafana Labs are certified under the EU-US Data Privacy Framework. We do not send personal data to a country outside the EEA ourselves.

Your rights#

If you are in the EU, you may ask us for access to your data. You may ask us to correct or erase it. You may ask us to restrict or stop our processing. You may complain to your data protection authority.

Write to privacy@bag.dev. We will answer within the time the law gives us.

Two limits apply. Sealed envelopes are unreadable to us, so we cannot search them by content. Public records are public by design.

Security and abuse contacts#

Report security problems to security@bag.dev. Report abuse to abuse@bag.dev.

Changes to this notice#

We will change this notice when our processing changes. We will update the date at the top. Where practical, we will say what changed.