Data handling

The engineering answer, in plain terms. The legal versions: Privacy Policy · DPA.

The one-sentence version

Your code goes to your model provider under your key for the duration of a review call; what wrokin keeps is where findings were and what happened to them — never the findings' prose, never your code.

What we store

• Finding locations — file path, line range, severity, category, and which provider/model surfaced it. This is the telemetry the public quality numbers are computed from.
• Outcomes — whether a flagged line later changed before merge (rework), 👍/👎 reactions, and /w wrong verdicts with the reason the human typed.
• Run records — role, status, timing, token counts per agent run, for your dashboard and quota metering.
• Account & installation data — GitHub account identifiers, installed repositories, plan status.
• Workflow run listings, briefly — when you open the dashboard's Runs page, each repository's recent GitHub Actions runs (workflow, branch, status, actor, and the run's title, usually a commit message's first line) are cached for up to 5 minutes so a refresh doesn't re-ask GitHub, then expire. No logs, no code.

What we never store

• Your code. Diffs and file contents are read at run time, sent to your chosen provider for the call, and not persisted by us.
• Finding prose. The text of a review lives in the PR comment in your repo — where it is yours — not in our database.
• Your keys, readable. See custody below.

BYOK key custody

• Keys are AES-GCM encrypted at rest, scoped to your installation, never logged, and never displayed again after entry — the dashboard shows only a …last4 hint.
• Every model call a BYOK agent makes on your repos uses your key against your provider — your bill, your rate limits, your provider relationship. We add no token markup. If you switch a review role to managed billing (an owner-only dashboard setting, available once agent credits are enabled), that role's calls run on wrokin's model account instead and debit your agent-credit balance — per-role, and only where you chose it.
• One exception, to your own runner: the Builder's runner fetches your Cruise key at job start so it can call Cruise directly. wrok.in hands it only to a GitHub Actions job that proves, with a GitHub-signed OIDC token, that it runs in a repository where you installed wrokin; the action masks it in the job log. Your runner then calls Cruise with it, and wrok.in sees nothing further of the run, except, when the run opens a ready PR, that PR's number and commit sha, which auto-merge checks against. Pass the key as a repo secret instead and wrok.in never handles it at all.
• A scoped GitHub token, to the same runner: with that check-in, wrok.in also hands the job a short-lived wrokin GitHub App token for that one repository, limited to contents, pull requests and issues (never workflows), so the job can push its branch, open the PR and comment as wrokin. It is masked in the job log, never given to the agent itself, and revoked when the job ends. It grants no more than the job's own GITHUB_TOKEN already can.
• Handing over a key is deliberately a human decision — one of the product's two human checkpoints. An agent onboarding via the setup API only holds key material a human chose to give it, on a token that expires in an hour.
• Uninstalling the GitHub App revokes access instantly; keys are deleted from the dashboard.

Where processing happens

• BYOK agents (review, security audit, triage) run on our infrastructure but spend your key — the code goes provider-ward only for the call. A role you switched to managed billing sends that role's calls to wrokin's model account instead (currently the Bytesbrains AI Cruise gateway), like the Hunter's guidance calls below.
• Warden (repo posture) is deterministic code: no model call, nothing leaves at all.
• Hunter (paid plans) executes on your GitHub Actions runners; the managed guidance calls run on wrokin's own model keys, metered to us via agent credits. Builder is on demand only (not a catalog plan benefit); it runs pi on your runner against Cruise with your Cruise key, so its model spend is yours and nothing is metered to us.

Machine-readable summary of all of this: llms.txt · capabilities.json. Questions: contact@bytesbrains.com.