Security
Local daemon.
Local trust boundary.
How Umbra is built to limit its own blast radius, and how to report a vulnerability.
Reporting a vulnerability
Please don't open a public GitHub issue for security
vulnerabilities. Email
[email protected]
with a description, reproduction steps, the output of
umbra --version, and the potential impact.
Only the latest release receives security fixes.
Scope
In scope:
- Daemon process and IPC layer
- Provider credential handling
- Tool execution (shell, file system, web)
- Session memory and SQLite storage
- npm package and release artifacts
Out of scope:
- Vulnerabilities in upstream dependencies (report to them directly)
- Attacks requiring physical access to the machine
- Issues in AI provider APIs themselves
Architecture
- Provider API keys are stored in
~/.umbra/— never in the project directory or logs - The daemon binds to
127.0.0.1only — not exposed to the network - Tool calls are validated against strict Zod schemas before execution
- No telemetry, no analytics, no external data collection
Known limitations
Umbra executes shell commands and file operations with your user permissions. The security of tool execution depends on the prompts and tasks you give the agent — review autonomous task results before applying them to production systems.