Privacy Policy

The flanner CLI, MCP server and local web UI run on your machine. Plans, memories, skills, versions, history and freshness results live in a SQLite database and files on your machine, and never leave it except through Flanner Mesh, directly to your own team's devices. No account is needed.

By default, the local tool sends nothing. Two things can be turned on. flanner init asks about each one separately, and each answer defaults to no.

• A version check. Once a day, flanner asks pypi.org for its public list of versions. This request goes to the Python Package Index, not to us, and carries what any download request does: your IP address and a user agent. Nothing about you or your work. flanner updates off stops it.
• Crash reports. When flanner crashes, it can send us a report through Sentry. A report contains the error type; where in flanner it happened (module, function and line, with file paths relative to the package); the flanner version, operating system, Python version and how flanner was installed; and which part of flanner crashed and the command name.

A crash report never contains the error message, local variables, source code, command arguments, full file paths, your user name or machine name, or any identifier for you or your device. Our Sentry project does not store IP addresses. Reports are kept for 90 days. flanner crash-reports show prints exactly what is sent, and flanner crash-reports off stops sending and deletes any report not yet sent. Setting DO_NOT_TRACK=1 turns crash reports off whatever you answered.

Checking a found secret. flanner curb sweep reads files on your machine and sends nothing. If you add --validate and answer yes when asked, the client on your machine sends each secret it found to that secret's own issuer, to ask whether it still works. It asks on every run, and the default answer is no. The secret goes straight from your machine to the issuer. It is never sent to us, and we do not receive the answer. The issuer handles the request under its own privacy policy.

Signing keys on GitHub. If you set up commit attribution with --github, the client runs GitHub's gh tool under your own GitHub sign-in. It adds each public key to your GitHub account as a signing key, titled with the agent's name. That goes from your machine to GitHub. We do not receive your GitHub sign-in.

If you never sign up for Flanner Mesh, we hold no data about you, apart from crash reports if you turned them on, which identify no one.

Signing up for Flanner Mesh creates records. All of them:

• Your email address. It is how you sign in and the only way we can reach you.
• Your team. Its name, who belongs to it, each member's role, and which workspaces they may read.
• Device records. A label, a platform, and the public half of the key each machine generated. The private half never leaves the machine and we could not ask for it.
• An audit trail of administrative actions: members invited or removed, devices enrolled or revoked, entitlements issued.
• Billing records. A customer id and subscription state from our payment provider, a record of each charge and refund, and how many seats you owe. For cards saved through Paystack, the reference it gives us for charging that card. Never the card number.
• A checkout in progress. The plan you chose and the email you gave, before your account exists. If you pay but do not finish signing up, we keep them for 7 days to remind you, then cancel.
• Promo codes you redeemed, and when their benefit ends.
• For messages between teammates: each member's display name and handle, whether messaging is switched on for your organization, and how long messages are kept. Never the content of a message.
• For Flanner Curb's team features, if your organization uses them and you enrol a device:
  • Agent policy: the rules your organization published, every version, while the organization exists. An audit collector's address is kept with the rules, and its token is kept encrypted.
  • Policy state per device: the policy versions it received, applied, holds pending or refused; whether its delegation is on; whether its settings have drifted. Deleted when the device is removed.
  • Device reports: device id, a sequence number, the time, each agent's name and version, the policy state, counts of agent launches by severity, and counts of secrets by exposure class. No paths, usernames, hostnames, repository names or credential names. We keep the newest report and 30 days of history, and delete them when the device is removed.
  • Alerts: your alert destination, kept encrypted. Each relayed alert holds an event id, type, agent, severity, a per-device keyed digest, a category instead of a location, the time and the device's label. We keep it until delivered, 7 days at most, and keep a delivered id for 7 days.
  Audit export goes from your device straight to your own collector. We do not receive it.
• Commit signing keys. If you set up attribution, the client makes a signing key for each coding agent on your device. The private half stays in your operating system's credential store and is never sent anywhere. On a device signed in to Flanner Mesh, the client registers the public half with us: the public key, its fingerprint, the agent, the device, any key it replaces, and proof that the device holds the key. We keep these in your organization's registry, with each key's status (active, retired or revoked) and when it changed. Every device in your organization can fetch the registry to check commits. We keep it while the organization exists. Removing a device revokes its keys, and a revocation is kept.

The content of your plans. Not the text, not the titles, not the file names. Plans sync directly between your own devices; they do not pass through us on the way.

Messages. Not the content of messages, who they are sent to, or when. Messages go from device to device, and each device deletes them after the period your organization chose.

Credentials Curb finds. We never receive a credential's value, its name or its location.

Card details. Our payment provider handles payment. We never receive a card number.

Passwords. There are none. You sign in with a mailed link, and machines authenticate with a key they hold.

Devices using Flanner Mesh find each other through a discovery service run by n0, the company that makes iroh, the networking library flanner uses. While a device is serving, syncing or sending a message, it publishes its current network addresses there, signed with its own key, so a teammate's device can look it up by device id. The local tool on its own never does this.

Two devices then normally connect directly. When a firewall prevents that, traffic falls back to a relay: one of the public relays n0 runs, or a relay we run, where we provide one.

Neither the discovery service nor a relay can read what devices send. The connection is encrypted between the two devices, and a relay has no key to it. What they do see is which device ids are talking, the devices' IP addresses, when, and roughly how much. Our relay does not log content, because there is no content to log. n0 runs its discovery service and relays under its own policies.

We use a small number of processors, and only these:

• Paystack — payments and subscription state. Stripe — the same, for accounts that subscribed through it.
• Our email provider — delivering sign-in links and invitations.
• Vercel Analytics — aggregate page counts on this marketing site. It sets no cookie and does not build a profile of you.
• Sentry (Functional Software, Inc.) — crash reports from the local tool, only if you turn them on. Stored in the EU.
• Web3Forms — if you contact us through a form on this site, your email address is relayed to our inbox through their service. That is the only thing those forms do.

Separately, devices using Flanner Mesh contact n0 directly, for discovery and its public relays, as section 4 describes. n0 sees device ids, IP addresses and connection timing, never the content of plans or messages.

We do not sell personal data, and we do not use it to train models.

Account, team and device records are kept while the account exists. Delete the account and they are removed within 30 days, apart from billing records we are required to retain for tax and accounting.

Sign-in links expire after 30 minutes and are spent on first use. Audit records are kept for as long as the account exists, because their purpose is to let an admin see what happened.

You can ask for a copy of what we hold, ask us to correct it, or ask us to delete it. Write to support@flanner.io and we will respond within 30 days.

Deletion is genuinely simple here, because the list in section 2 is short. There is no archive of your work to hunt through.

Crash reports carry no identifier, so we cannot find the ones that came from you. Turning them off deletes any your machine has not yet sent, and those already sent are deleted after 90 days.

A device key is the credential, and we only ever hold public keys. A breach of our systems would expose email addresses, team structure and public keys. It would not let anyone read your plans, and it would not let anyone impersonate one of your devices.

If you believe you have found a vulnerability, please see the reporting section of the Acceptable Use Policy.

The service is for professional use and is not directed at children under 16. We do not knowingly collect their data.

Changes are published here with a new date at the top. Material changes are emailed to account holders before taking effect.

Flanner is the data controller. Reach us at support@flanner.io.