Security
genduo runs commands on your own machine, so it is built to ask before acting, to keep your work on your Mac, and to say plainly what it does not protect against.
Where your data lives
On this Mac
- Sessions, memory, uploads, documents and checkpoints are written under ~/.genduo.
- Keys you add in the desktop app are stored here too (~/.genduo/byok, owner-only permissions) and are never uploaded.
- The desktop app holds no model-provider key of its own.
Through genduo.ai
- Sign-in, model calls and billing.
- Publishing a share link, and the pages other people open from it.
- Keys you add in the web app — a browser has nowhere else to keep them.
Model traffic leaves your Mac. There is no on-device inference and no end-to-end encryption.
Approvals before actions
Three presets decide how often the agent stops to ask. They gate tools, not the filesystem.
Default
Asks before sensitive shell commands — deletions, force-pushes, privilege escalation, curl and wget, destructive docker — and before any write that leaves the workspace.
Read-only first
Asks before every write, network call or MCP call. Writes that leave the workspace are refused outright, with no dialog to click through.
Full auto
Skips the ordinary confirmations, including the shell's own prompts. It still asks for plan approval, still refuses out-of-workspace writes, and never turns off the operating-system sandbox.
A plain ls or cat runs without a prompt; only the classes above do. Read-only asks before a write — approving it lets the write run. The preset is a gate, not a filesystem mode.
Where it refuses to write
- Writes into any .git directory, or to a .env or .env.* file, are refused outright — with or without the workspace sandbox, and with no setting that turns it off. Symlinks are resolved first, so a link pointing at .env cannot smuggle the write through.
- Reading those files is unrestricted. This guard is about writes.
- It stops mistakes, not adversaries: a hard link to .env under a harmless name is indistinguishable at this layer.
Shell sandbox
- On macOS every shell command runs under Apple's Seatbelt. Writes outside the workspace — plus the temp directories and /dev/null — are denied by the kernel, and the denial is inherited by the processes a command starts.
- Enforcement is reported as partial, and that word is literal: the profile confines filesystem writes only. Reads, network access and process signals are not confined.
- It fails closed. If the sandbox cannot be applied, the command is refused rather than run unconfined; in Plan mode shell access is blocked entirely.
- macOS only. On Linux and Windows the workspace boundary is a path check, not kernel-enforced.
- The workspace root is a guardrail against mistakes, not a security boundary — a command that changes directory to / can still write anywhere the profile allows.
Credentials
What the shell can see
Commands run with a scrubbed environment: variables starting with MINIMAX, CSC or APPLE, or ending in KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL, PAT or KEY_ID, are withheld from the subprocess. An explicit opt-in, GENJI_BASH_KEEP_ENV, lets named ones back through.
Your own model key
A key you add in the desktop app is written to ~/.genduo/byok with owner-only permissions and never leaves the machine. A key added in the web app is stored on our servers — a browser has nowhere else to put it. On the cloud runtime the channel that reads keys out of server environment variables is disabled entirely.
Outbound network
- Fetches the agent makes on your behalf reject private and loopback addresses, follow redirects one hop at a time and re-check every hop.
- MCP servers go through the same check before every request and before every redirect.
- The address check runs on both runtimes. The DNS-resolution half does not run on Cloudflare Workers, which have no resolver — so DNS-rebinding protection is not something we claim there.
Accounts and API keys
- An API key cannot manage API keys: creating, changing or deleting one returns 403 when the request is authenticated with a key, on both runtimes. Key management needs a signed-in browser session.
- A read-only key can only issue GET and HEAD requests.
- Per-account data is namespaced by account id, and importing a session that another account has already imported is refused rather than overwritten.
Rendering what you upload
- An uploaded SVG is displayed as an image from a blob URL and is never inserted into the page's DOM.
- Uploaded HTML is sanitized before it renders: <style> and <script> tags and every style attribute are stripped.
- File responses are sent with nosniff, and a served SVG additionally carries a policy of default-src 'none'.
What we do not claim
Everything above is deliberately narrow. These are the limits, stated as limits.
- No third-party audit. There is no SOC 2, no ISO 27001 and no penetration-test report behind this page.
- No end-to-end encryption. Model calls leave your Mac; what you send to a model reaches our servers and the model provider.
- The macOS sandbox confines filesystem writes only. It is not network isolation and it is not a virtual machine.
- Kernel-enforced confinement is macOS-only today.
- The write guard stops mistakes, not a determined adversary.
- The sandbox uses sandbox-exec, an Apple API that is deprecated. If Apple removes it, commands are refused rather than run unconfined.
- A share link is public. Anyone holding the URL can open it.