---
title: "Security and data handling"
description: "Where your code lives, what crosses the network, how credentials are stored and scoped, and the trust boundaries in the desktop app."
url: "https://www.fredrin.com/docs/security"
updated: "2026-08-11"
---

# 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](https://www.fredrin.com/docs/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](https://www.fredrin.com/docs/memory/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](https://www.fredrin.com/docs/subscription) 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](https://www.fredrin.com/contact), and see the [security page](https://www.fredrin.com/security) for the wider posture.

## Next steps

- [Privacy](https://www.fredrin.com/docs/memory/privacy) - the conversation gate in detail.
- [Workspaces, members and roles](https://www.fredrin.com/docs/teams) - who can reach what.