Skip to content
Fredrin
Documentation

Teams & security

Security and data handling

Fredrin runs on your machine and against your git remote. This page says what that means concretely, and where the boundaries are.

Your code

Fredrin does not upload your repository. Workers run on your machine, in a worktree on your disk, against a git remote you control.

What Fredrin's servers hold is board state: tickets, plans, statuses, activity. Not your source.

The exception is deliberate and opt-in: a remote agent runs Workers on another machine, which necessarily has a checkout on it. That is the trade you make when you choose to run work elsewhere.

Conversation content

Off by default, per project. See privacy for the full treatment: what counts as content, what counts as metadata, and the remote-agent carve-out.

Secrets are redacted from agent output on the way out, both at capture and again at server ingest, independently of whether that content is being persisted at all.

Credentials

Your AI subscription is not held by Fredrin at all under the default bring-your-own posture. The coding CLI uses its own on-machine login and Fredrin injects nothing.

API keys you paste are encrypted at rest and injected into a Worker's spawn environment only.

Connector credentials are encrypted, scoped to the project or workspace that owns them, and never returned to the client. An agent gets query results, never the key.

GitHub access is through a GitHub App with short-lived per-operation tokens, scoped to the repositories you selected, rather than a long-lived personal access token.

Fredrin API keys are SHA-256 hashed at rest, compared in constant time, scoped to one workspace, and bound to the issuing member's role.

Authorization

Every service entry point checks project access, and endpoints that take a resource id resolve that resource's project rather than trusting the caller's claim. A borrowed id is refused rather than honoured.

API keys carry a second, orthogonal boundary at the route edge: a key bound to one project cannot reach another even if the human behind it could.

The desktop app

The application UI is desktop-only, gated at the edge. Public surfaces (marketing, the API, legal pages, invites) are an explicit allowlist; anything not on it requires the desktop shell.

That gate is a product decision, not a security boundary. Server-side authorization is identical either way, and nothing depends on the client being trusted.

Reporting a vulnerability

Get in touch, and see the security page for the wider posture.

Next steps