Privacy Policy

This website (orga.bot) and the Orgabot project are operated by Senternet LLC, which is the entity responsible for the data described below and the one your cookie choice is given to. It is a marketing site and it does not require an account.

The access request form. The request alpha access page asks for your name, email, and optionally your company and what you would use Orgabot for. Nothing you type there is submitted to this site or stored by it: the page composes a message and hands it to your own email application, so we receive it only if you choose to send it, and then it is ordinary email used only to reply to you.

Analytics. This site uses Google Analytics 4 to understand which pages are useful. When it runs, it sets cookies in your browser and sends Google your page views, approximate location derived from your IP address, and basic device and referrer information. We use it only in aggregate and we do not sell your data. You can read how Google handles this data in the Google Privacy Policy. This site also uses Ahrefs Web Analytics, which is cookieless and collects no identifiers, for page-level traffic counts.

Your cookie choice. Google Analytics is gated behind a consent notice, and which notice you see depends on where your browser says it is:

• EEA and the UK. Google Analytics does not run and sets no cookies until you choose Allow all. That is an opt-in, so doing nothing keeps it off.
• California and the US Pacific states. Google Analytics runs and the notice offers an opt-out. Choosing Reject stops collection, disables the tracker, and clears the cookies it already set.
• Everywhere else. Google Analytics runs and no notice is shown, which is why most visitors never see one.

Your browser’s reported time zone is what decides which of those applies. That check happens entirely on your device: nothing about you is sent anywhere to classify you, and if the time zone cannot be determined, analytics stays off and no notice is shown. Your choice is stored in this browser’s local storage (orgabot.cookieConsent and orgabot.consentRegion), never in a cookie of its own, and clearing site data forgets it.

You can change your mind at any time: reopen the cookie notice. Browser-level cookie controls, and Google’s own opt-out add-on, stop this collection too.

The Orgabot software

Everything above is about this website. The Orgabot software itself is a separate matter. Orgabot is local-first: you can run the complete local profile without an Orgabot account or hosted tenant. Optional hosted and hybrid deployments now exist, so what leaves your machine depends on the deployment topology you deliberately select.

Local-only mode. Your repositories are cloned into git worktrees on your machine, your project’s own verification runs there, and mission state, audit events and the operational database live under your Orgabot home. Orgabot sends us no copy of that local state. Services you connect, including model providers and GitHub, still receive the requests you direct to them under their own terms.

Hosted or hybrid mode. An isolated hosted tenant can place its operational store, artifacts, secrets, or control plane in the cloud account named by its deployment. Orgabot exposes the resolved provider, custody, data movement and readiness of each capability before it runs. Nothing is moved merely because a hosted adapter exists. Retention and deletion then include both the local Orgabot home and the selected cloud providers; deleting only one does not delete the other.

Credentials and connector grants. A credential you give Orgabot for a service is stored in your selected protected store where one is available: macOS Keychain, Linux Secret Service, Windows DPAPI, or an explicitly configured cloud secret manager. It never enters this project’s repository or the deployment topology file. Credentials are resolved by handle only when needed and are redacted from logs. A connector grant scopes which role may use which credential for which service; the grant itself contains no secret.

Published GitHub App. In local bring-your-own mode, your App key stays in your protected credential store. An isolated hosted deployment may instead use the published orgabot-connect App. Its shared private key stays in a separate broker trust project. The broker checks the tenant’s durable installation claim, performs only the bounded GitHub request, revokes the short-lived token, and returns neither key nor token to the tenant or worker. The callback and request path necessarily processes installation, repository and permission metadata needed to route and authorize that GitHub operation.

One connector works differently and it is worth saying so. A Google service-account key you point Orgabot at with orgabot firebase connect --credentials is not moved anywhere: it stays the file you already had, at the path you chose, with whatever permissions it already had. Orgabot records only that path and reads the key from it when it polls. If you want that key protected, protect the file.

What that does and does not buy. We would rather be precise here than reassuring. Keychain storage is real encryption at rest, and it is a real boundary against a worker only when Orgabot runs as a signed application, where the keychain item is tied to a code-signing identity. In the current alpha, which runs from source, Orgabot and the worker are both unsigned processes under your user account, so the keychain is not a boundary between them: what stands in for one is a policy layer that inspects worker commands and refuses ones that name the credential store, recording the attempt against the mission’s organization where it can. That check matches on the text of a command, so it stops the ordinary case and not a determined one, and the record is best-effort rather than guaranteed. Treat a credential you hand to an alpha running on your machine as something that machine can reach.

Third parties you choose. Orgabot works by directing tools you already use. The calls Orgabot itself makes go to the services you connected it to: your AI model provider (whatever your worker runs on, which receives the code and context of the task you asked for, under that provider’s own terms), your source host such as GitHub, and any other connector you explicitly grant. Each of those relationships is between you and that provider; we are not a party to it and receive no copy.

Being exact about the limit: a worker is a process running as you on your machine, so Orgabot constrains where it connects, not where that process can. A tool you install, an MCP server you add, or a script in the repository being edited can reach the network on its own, exactly as it could if you ran it yourself. Constraining that needs sandboxing Orgabot does not yet do, and this policy will say so when it does.

One destination that is not a connector. If you turn on live GitHub state, Orgabot runs an ngrok tunnel so GitHub can reach a webhook receiver on your machine. Your repository’s pull request, push, issue, check and workflow events therefore pass through ngrok’s servers, which terminate TLS, before they reach you. That includes repository names, pull request and issue titles and bodies, and commit metadata. ngrok is a separate company with its own terms, and it is in the path even though you did not grant it as a connector, which is exactly why it is named here. Only that one webhook receiver is tunneled; your dashboard is not. The dashboard starts the tunnel for you once GitHub ingestion is configured; ORGABOT_AUTO_GITHUB_CONNECT=off turns that off, and Orgabot works without it.

What we do receive. Nothing automatically. Orgabot sends us no telemetry, no usage statistics and no crash reports. If you write to us, or paste something into Discord, we have what you sent and nothing else.

This applies to the current first beta, including its local-only and optional hosted deployment modes. A new provider or custody boundary must be reflected here when it changes what data a deployment sends.

Any contact you initiate (for example, by email) is used only to respond to you.

Questions about this policy, or a request about your data, can be sent to privacy@orga.bot. Anything else reaches us at hello@orga.bot.