security & privacy
Powerful, with boundaries
An agent that can edit files, run commands, browse and control apps can also make mistakes or be misled by content it reads. Orvlet's boundaries are designed to keep you in the loop.
Safeguards built in
Approvals in plain English
Requests show the exact command, URL or diff — never a policy code. Notifications name the waiting task. Optional Touch ID can guard high-risk choices, and an optional approval reviewer model may suggest or auto-approve low-risk requests; risky categories always come to you.
Full access is never inherited
A task reaches Full access only when you choose it in that task. New tasks never inherit it, the mode shortcut never cycles into it, and files that may contain secrets ask before they are read in every mode.
Command sandbox
Enforced by macOS: read-only or project-only filesystem access, network on or off, with a domain allowlist. Folders outside the project ask before a file tool touches them.
Credentials stay in the OS store
Provider keys are held
by the operating system's credential service; configuration stores only opaque
references. Encryption fails closed when OS-backed storage is unavailable — never a
key derived from your username or machine name. Secrets are stripped from child
processes, and a repository's .env cannot redirect endpoints or set
proxies, commands or trust roots.
Untrusted content is labeled
Web pages, model output, file contents and guest messages are treated as untrusted. Remote Markdown images are click-to-load, the embedded browser runs with default-deny permissions, and project config files cannot widen permissions or enable tools in an untrusted folder.
No account. No telemetry. Nothing contacted at startup.
Photograph — Ahmed Atef via Unsplash
Network policy
No account, telemetry, analytics, crash upload, subscription or quota lookup, cloud plugin catalog, vendor download or automatic update — at startup or ever. Model requests go only to providers you enable and carry no device, installation or user identifiers. Downloads (models, plugin sources, MCP servers) happen only when you ask. The only update check is a button you press, against a signed feed, and installing is always your step.
Opt-in features that talk outward — messaging channels, link previews, LAN engine sharing, live task sharing, remote control — are off by default and say so where you turn them on. Optional extras include a privacy filter that replaces secrets before a request reaches a cloud provider, and encrypted storage of transcripts at rest. This website follows the same rules: no cookies, no analytics, no third-party assets.
Where your data lives
Projects, tasks, settings and approvals stay under ~/.orvlet (or a data
folder you choose). Removing a credential never deletes projects, history or
unrelated keys. Keep approvals on for projects you do not fully trust, use the
sandbox, review diffs, and keep backups.
Reporting a vulnerability
Please do not report security problems in a public issue or discussion. Report them privately to the maintainer through GitHub — Report a vulnerability on the repository's Security tab when available, or ask for a private channel without including details. Include the Orvlet version or commit, OS version, affected area and steps to reproduce. Never include real API keys or private project content.
In scope: approvals bypassed, Full access without your choice, sandbox escapes, credentials leaving the OS store, unexpected network requests, and prompt-injection paths that act without an approval. A model producing wrong output inside permissions you granted is a known risk, not by itself a vulnerability. Fixes land on the main development line; there are no maintained release branches while Orvlet is a preview.