Plans and help

Security and privacy

How Duscode protects your code, keys and machine. It runs locally, keeps keys in a vault, asks before acting, blocks dangerous commands and is never destructive with git.

Duscode runs where your code lives. With your own key, it talks to the AI provider you choose directly, and nothing passes through Duscode's servers. On Duscode credits, each request passes through Duscode Cloud to the provider and back; we keep what each call cost, not what it said. Exactly what goes where, privacy mode, and how to delete your data: Data and privacy. Provider data policies: the security page on duscode.com.

On your machine

Local only. The server listens on 127.0.0.1. It refuses requests from other websites and from host names other than localhost.
Keys stay local. Keys added in Settings are sealed in the encrypted vault, and the browser sees only their last four characters. ~/.duscode/.env is readable only by you. Dus can't list, use or overwrite provider keys. A key goes only to its own provider, never into a project or a repository.
Privacy mode. Allow any provider with a key, only the ones you choose, or local models only; enforced for every model call. See Data and privacy.
Your files stay inside the project. Dus can read and write only inside the project (or the session's worktree). Symlinks are followed to check they don't lead outside. Writes are atomic.
No stale edits. Dus must read a file before editing it. An edit is refused if the file changed while you were reviewing it.

What Dus may do

Commands run in an OS sandbox. Where your system has one, a command can write only the session's folder, can't see your home folder or credentials, and reaches only package registries unless you approve more. See Command sandbox.
Secrets in a vault. Tokens, SSH keys and database URLs are encrypted on your machine, with the key in your OS keychain when there is one. Dus uses them by name and never sees the values; they're masked in every output. See Secrets vault.
You choose what asks. The permission mode (Ask, Auto, Plan, or Full Auto inside the sandbox) decides; irreversible actions (pushes, deploys, migrations), secrets and merging a worker ask in every mode. Allow rules live in your home folder, never in a project, so a repository can't grant itself trust.
Every task can be undone from a snapshot, and every operation is in the session's audit log with what allowed it.
A fixed blocklist applies in every mode: sudo, recursive deletes of / or your home folder, disk formatting, shutdown and reboot, piping downloads into a shell, and force pushes.
Commands never see your keys. Key variables are removed from their environment, and key values are redacted from their output.
A project's config can't redirect your keys. Provider addresses and key variables are read from your user config only.
Never destructive with git. No force pushes, resets or stashes. Sessions refuse to finish if work would be lost, and their branches are kept.
Careful on the web. Page fetches refuse private and local network addresses, identify themselves as Duscode, and are capped in size and time. Opening a site other than localhost in the headless browser asks first.
Memory refuses secrets that look like keys, tokens or passwords.
A secrets vault. Deploy keys, tokens and database URLs are stored encrypted, with the key in your OS keychain. Dus uses a secret by name in the one command that needs it and never sees the value, and every value is masked in output, logs, the journal and saved sessions. Manage them in Settings → Vault.
An OS sandbox for commands on Linux and WSL (bubblewrap). Commands can write only inside the session's folder, never see your credentials, and reach only an allowed list of hosts. Project details shows whether the sandbox is on.

Things to keep in mind

Checks run without asking. The verification gate runs the project's own scripts after a task. Open only projects you trust, as you would before running their tests yourself.
Prompt injection. A web page or a file can contain text written to steer an AI. Dus treats web content and worker reports as information, not instructions, and the approvals above still apply. Review approval cards with care, especially in Auto mode.
Your provider's policy applies to whatever Dus sends it. See Your data and keys.
Native Windows has no sandbox yet. There, commands run with approvals only, and Full Auto can't be chosen. Run Duscode in WSL to get the sandbox. The sandbox's known limits apply everywhere.

Your account on Duscode Cloud

Your account (cloud.duscode.com) holds your plan, billing and team, not your code.

Sign-in by emailed link, no password to leak. Sessions and links are stored only as one-way hashes, and expire.
Customers are kept apart. One account can't see or change another's account, team or invites. Attack tests try exactly that (another team's members and invites, forged or signed-out sessions, admin pages without admin rights) and must fail on every change before it ships.
Payments are handled by Stripe; Duscode never sees your card.

No system is impossible to break into, and we don't claim otherwise. We test the attacks we know about, fix what we find, and tell you plainly if something affects you. For businesses: our Data Processing Agreement, Privacy Policy and Acceptable Use Policy (drafts, pending legal review).

Reporting a security issue

Email support@duscode.com with "Security" in the subject. Please give us a chance to fix the issue before you share it publicly.