End-to-end encrypted coding agent tasks: what the server can and cannot read

Updated 2026-10-18

Your working checkout stays on the runner. Selected uploads – READMEs, docs, plan snapshots, transcripts, attachments and no-Git review diffs – can contain source code or secrets. Full recording is the default; policy can select Text or Off. The coordination text around it, meaning task descriptions, plans, agent conversations and attachments, can be encrypted in the browser or on the runner under a passphrase Denly never receives.

Denly is a control plane for coding agents (Claude Code, Codex, Cursor, Grok Build, Antigravity) that run on your own machines using your vendor subscription or API key. It manages tasks, plans and reviews across projects; Git-backed tasks can open pull requests, while no-Git projects end with a review of local changes. What follows is exactly which of that data Denly's servers can read.

The two boundaries

Data	Encryption off	Workspace E2E on
Working checkout	Cloned, edited, built and tested locally. Selected content, including READMEs, docs, transcripts and no-Git review diffs, can be uploaded.
Task title and description	Stored readable, so the service can deliver it	Ciphertext
Plans and agent conversations	Stored readable	Ciphertext
Attachments	Stored readable	Ciphertext
Recurring schedule title and body, and project documents	Stored readable	Encrypted by the current dashboard; see runner/server limitations below
Stage, timing, cost figures, PR links, repository slugs	Readable either way. The service routes and bills on these.

How the key works

The browser and the runner each derive one content key from a workspace passphrase and a per-organization salt with PBKDF2-HMAC-SHA256 at 600,000 iterations, then AES-256-GCM each field into an identical JSON envelope: {"v":1,"iv":"<12-byte nonce>","ct":"<ciphertext and tag>"}. The passphrase never leaves the machine. Only the salt, which is not secret, and the envelope are uploaded.

Because both halves produce byte-compatible envelopes, a task written in the browser is readable by the runner and a plan written by the runner is readable in the browser, with the server holding no content key. This describes successful encrypted writes; see the audited failure paths below.

Turn it on

Enable end-to-end encryption for the workspace and set the passphrase. It is entered in the browser and stays there.
Give each runner the same passphrase in its environment.
Restart the runners so they pick it up, and create one task to confirm it round-trips.

Runner environment

DENLY_E2E_PASSPHRASE=your-workspace-passphrase

Known runner and server failure paths (audit: 2026-10-18).Runner key or enrollment lookup failures can fall back to plaintext for events and document/README uploads. The server does not consistently reject protected plaintext from older clients. The current browser encrypts schedule titles/bodies and blocks locked-key project-document saves; these protections do not prove the runner/server guarantees. Fixes require separate review and release verification. Skills intentionally remain plaintext for server-side validation.

Passphrase loss is permanent.Denly holds no key and no recovery copy, so nobody at Denly can restore encrypted history for you. Store the passphrase where you store your other workspace secrets.

What it does not cover

Two parties stay outside the boundary, because the work needs them:

Your Git host receives the code the runner pushes, under your agreement with them.
Your AI provider receives the context its own CLI sends, under your agreement with them.

Encryption also does not change what the runner uploads when you ask it to diagnose itself: that is a redacted, curated summary of the local log, never the raw file and never repository contents.

Taking your data out

Settings → Account → Your data downloads everything Denly holds about your account as JSON. Separately, Record agent output on the Defaults screen decides how much of a run is kept at all: Full records messages and the tools it ran, Text keeps the messages and drops the tool results, and Off records nothing beyond the task's own events. It can be set per project.