Three Machines, No Surveillance

What we cannot see

Saga is local-first. Your projects, your context graph, your conversations, your bundles, your memos, your generated images and audio and video — all of it lives on your machine. There is no server-side copy on our infrastructure. I, as the person running Saga, cannot read what you do inside Saga, because I do not have the data.

This is the same architectural property that defines Signal for messaging. The vendor cannot see content because the vendor does not have content. The trade is symmetric in both directions: I cannot retroactively monitor you, and I cannot retroactively recover your work if you lose it. Local-first cuts both ways. I think the trade is the right one.

The same property that makes me unable to read your private working notes is what makes the architecture credible for the domestic-violence survivor planning an exit, the journalist working on a leak, the researcher analyzing a controversial dataset, the dissident anywhere. It is not a feature I can separate from the people who would use a hostile feature against them.

What we do see, and where the line is

There is a real distinction between watching what users do inside Saga (which we do not do) and watching the act of subscribing and authenticating (which every payment-handling product does, including Saga). The line matters, and I want to draw it explicitly.

Three signals operate at the auth and billing layer:

1. Rate-limited account creation per IP

A single IP creating many Saga accounts in a short window is a fraud signature, not normal behavior. Account creation is rate-limited per source IP to protect against mass-account farming, trial-cycling, and automated abuse.

2. Mass-signup burst detection

Above per-IP limits, signup bursts that exceed normal baselines (across IPs, geographies, payment methods) are flagged. This catches distributed account-farming that splits across many IPs to evade per-IP caps.

3. Rapid geo-rotation on a single credential

A single Saga account authenticating from many widely-separated geographies within a short window is a credential-sharing or credential-compromise signature. The account may be temporarily locked pending re-verification.

None of these signals touches what is inside Saga — your projects, your conversations, your bundles, anything you generated. They operate on metadata that the subscription system inherently has: when accounts are created, when accounts authenticate, where the auth request originated from. This is the same surface Stripe Radar, Auth0, and every other payment-or-auth provider watches. It is fraud detection, not surveillance, and the distinction is load-bearing.

The three-machine rule

A single Saga subscription — $25/month, one tier, no add-ons — permits up to three machines authenticated against the same account.

Three is the upper bound of legitimate solo-developer multi-machine use I have observed in practice. Saga's own development workflow runs on three machines: a Linux authorship rig where the code lives, a macOS verification rig, a Windows verification rig. The cap was sized to that pattern, not pulled out of the air.

It is generous enough that the normal "laptop + desktop + headless VM" envelope is covered without anyone needing to think about it. It is constrained enough that a small team sharing one credential to avoid paying for team usage hits the cap quickly.

To exceed three machines on a single account, you can de-authorize one of the existing three from inside Saga (the device list is yours to manage; the local data on the revoked machine stays as a static archive — revoking the device does not destroy your work). If you genuinely need more, the team subscription is coming.

When something goes wrong

Every tool that gets used by enough people eventually gets used by someone for something the rest of us would not endorse. Signal has weathered this cycle. Tor has. Bitwarden has. Encrypted messaging in general has. The architectural property that protects the people who need protection is the same property that makes content scanning impossible. There is no version of this trade-off where the architecture can be selectively turned off for "the bad ones."

What I can do, when abuse is reported through news, courts, victim complaints, or security disclosures:

Revoke the subscription. The offending account's live service stops working — model gateway routing, software updates, sync features. The user's local data persists because local-first; I am severing the commercial relationship, not destroying what they built. Honest about what is mine to take back and what is not.
Respond to lawful process. A subpoena gets account-existence and billing records. It does not get user content because user content is not on Saga's infrastructure. I respond with what I have.
Publish a transparency report.Aggregate counts of revocation actions and law-enforcement requests, once there are any to report.

What I will not do, including under media pressure:

Add content scanning, behavioral monitoring, or backdoor capability to the application. The architectural property is the trust signal; adding scanning would invalidate the entire posture and protect no one who was not already going to be caught by other means.
Geofence users based on location or political affiliation. Saga is paid software; the only access controls are "valid subscription" and "no TOS violation."
Claim capabilities Saga does not have. If I cannot retroactively monitor you, I will not pretend in a press release that I can.

What the architecture does not prevent

I would rather name the residual risks than pretend the architecture is complete:

Coordination via Saga as an artifact-passing layer. Two users sharing bundles, memos, or generated content with each other — over email, USB, git, Signal — are using Saga as a content production tool and coordinating elsewhere. Saga does not see that coordination. It cannot prevent it. Friction working in our favor: Saga is single-player by default. There is no built-in team coordination, no shared workspace sync, no real-time collaboration. A bad-actor network wanting a coordination tool is better served by Signal, Discord, Matrix, or custom infrastructure. Saga is not the path of least resistance for that case.

Generated content used elsewhere for harm. A user generating text, images, audio, or video with Saga and publishing or weaponizing it elsewhere — Saga produced the artifact, Saga does not see what happens to it. This is the same property as a paint program. The painter is responsible for the painting. The underlying model providers' content guardrails (which Saga does not modify or weaken) apply at generation time; legal frameworks apply after.

Misuse of API keys you bring. Saga uses bring-your-own-key for cloud model access. If you supply a key obtained fraudulently or used in violation of the provider's terms, that is between you and the provider. Saga forwards the request as you instructed; it does not authenticate against the provider on your behalf.

Why write this before needing it

Every privacy-architected product eventually has the conversation where a reporter calls and asks "how do you respond to this abuse case?" If the answer is written under pressure, it sounds like spin. If the answer is written before pressure, with the residual threats named honestly and the commitments stated specifically, it sounds like what it is — a thought-through posture that the architecture is actually constrained to keep.

The formal version of this stance lives at docs/trust-and-safety.md in the Saga repository. It includes the maintenance protocol (when to update it, when not to), the cross-references to Privacy Policy and Terms of Service, and the list of what is constitutionally committed vs. what is still being built out. Both documents are public, version-controlled, and editable through the normal pull-request process.